• Статья

Концепция глобальной бизнес-аналитики: принципы разработки хранилища данных для поддержки корпоративных приложений бизнес-аналитики

Чарльз Фихтер (Charles Fichter),
корпорация Microsoft

Декабрь 2009 г.

Краткое содержание.

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

Предполагается, что читатель обладает базовыми знаниями о многомерных хранилищах данных, таблицах фактов, столбцы которых называются измерениями, таблицах измерений, столбцы которых называются атрибутами, и о схемах типа «звезда» и «снежинка». Эта информация имеется на многих ресурсах; при необходимости краткий обзор можно найти по ссылке: http://www.simple-talk.com/sql/learn-sql-server/sql-server-data-warehouse-cribsheet.В статье также рассказывается об успешных стратегиях проектов по реализации хранилищ данных, углубленно рассматриваются приемы эффективного проектирования, позволяющие достичь высокой производительности.

Введение

В поиске решений корпоративной бизнес-аналитики архитекторы часто обращают внимание на комплекты программного обеспечения, позволяющие формировать полезную для руководителей отчетность, которая содержит углубленный анализ эффективности работы. Корпорация Microsoft и ее многочисленные партнеры – независимые поставщики ПО – много сделали для того, чтобы облегчить создание информационных панелей бизнес-аналитики, о которых мечтает любой руководитель: с актуальными результатами реализации бизнес-стратегий и возможностью углубиться в конкретную область. Однако слишком часто мы забываем о том, что на поддержку архитектуры и ИТ, скрытых за эффектным пользовательским интерфейсом, затрачивается 90 % усилий. Ведь необ­ходимо получить данные, эффективно очистить и агрегировать их. Кроме того, требуется спроектировать подходящие управляемые и высокопроизводительные многомерные хранилища данных, которые позволяют выполнять динамические запросы и репликацию в удаленные местоположения. Еще нужны киоски данных для мобильных сотрудников, отвечающих за принятие решений, способные справиться с неуклонно возрастающим объемом многомерных данных.

Изолированные данные предприятия и доступ к ним

Корпоративные архитекторы, которые склонны агрегировать хранилища данных приложений со значащими многомерными моделями оперативного анализа данных (Multidimensional Online Analytical Processing, MOLAP), часто сталкиваются с множеством внутренних препятствий при доступе к исходным данным. Эти препятствия не столько носят технический характер, сколько относятся к деловым, юридическим аспектам, аспектам аудита и безопасности. Кроме того, возможны слишком жесткие ограничения по издержкам и затруднения политического характера, поскольку бизнес-данные могут подпадать под сферы влияния разных руководителей и подразделений. Затруднения могут быть вызваны технологическими ограничениями, в частности, несовместимыми или проприетарными решениями, унаследованными форматами файлов и нереляционной структурой данных или ее отсутствием. Однако по мере совершенствования технологий программных инструментов от поставщиков (особенно в Microsoft SQL Server 2008 и в Microsoft SQL Server Integration Services [SSIS]) и сервис-ориентированной архитектуры (service oriented-architecture, SOA) (например, использование WS* и других открытых стандартов) острота этой проблемы снижается.

Тем не менее при реализации многих проектов в сфере бизнес-аналитики возникают затруднения и (или) проекты в конечном итоге терпят неудачу из-за того, что команда разработчиков не вполне точно понимает, какие именно данные необходимы, как успешно получить доступ к ним и сделать их пригодными к использованию. Удобство использования – это ключевой вопрос. Как объединить десять столбцов с именами вида «xtssalescongproc» в центральную таблицу фактов с читаемыми именами столбцов, чтобы конечные пользователи могли самостоятельно работать с бизнес-аналитикой?

Ниже приведены общие советы, как избежать ошибок при предоставлении доступа к изолированным данным:

  1. Заручитесь серьезной поддержкой со стороны руководства на ранних этапах. Успех проекта зависит от того, насколько велики ваши исполнительские полномочия по отношению к корпоративным хранилищам данных. Запрос доступа составляет менее 1 % от общих усилий. Возможно, многие подразделения понесут существенные временные и финансовые затраты. Вероятно, вы окажете негативное воздействие на их работу с клиентами, поскольку вам потребуется проанализировать данные подразделения, получить доступ к ним и выполнить их агрегирование. И вот еще что важно: имеют ли сотрудники подразделения правильное представление о собственных данных? Сколько времени им требуется, чтобы проанализировать и оценить хотя бы те данные и объемы, которые они вам предоставляют? Не стоит недооценивать важность поддержки со стороны руководства и вероятную потерю времени и ресурсов в связи с вашими требованиями, которую могут понести другие высокоуровневые хранилища данных и сотрудники, которые ими управляют.
  2. Кто-нибудь располагает реальными знаниями о данных?Этот вопрос кажется очевидным, однако мы выполнили множество подобных проектов и не перестаем удивляться тому, что корпоративные клиенты зачастую очень мало знают о собственных данных. Многие амбициозные проекты по внедрению бизнес-аналитики быстро заканчивались после того, как выяснялось, что разработчикам потребуется сначала провести полный анализ всех хранилищ данных предприятия, а на это во многих случаях может уйти несколько месяцев. Если архитекторы, не знакомые с источником данных, просто оценят таблицы визуально, то это может поставить их в тупик, поскольку имена столбцов не обязательно описывают содержащиеся в них данные. Часто приложения и хранилища данных практически не обслуживаются и не улучшаются годами, а знания о том, как спроектировано хранилище данных, давно утеряны. Можете ли вы взглянуть на базу данных, в которой свыше 500 таблиц, и понять существующие отношения без подробного анализа всех приложений, использующих это хранилище? Возможно, это выпол­нимо при условии, что вы располагаете усовершенствованными программными инструментами и достаточным количеством времени. Согласно поговорке, дьявол кроется в мелочах. Качество сформированных измерений и атрибутов будет зависеть от того, насколько хорошо вы понимаете источники исходных данных, лежащие в основе агрегирования.
  3. Понимание локальных приоритетов и консолидация.Наиболее высокие требования к отчетности бизнес-аналитики часто имеют локальную или региональ­ную природу (например, необходимы в конкретной стране или сфере коммерции), поэтому возникает вопрос: действительно ли требуется огромное агрегированное хранилище данных, причем незамедлительно? Либо можно пойти по намного более эффективному пути: создать распределенное хранилище и сформировать стратегию бизнес-аналитики, где основное внимание будет уделено локальным или региональным требованиям и требованиям предприятия? Этот вопрос более подробно освещается в следующем разделе. В результате применения децентра­лизованного подхода можно значительно сократить издержки и нагрузку на сеть и увеличить производительность.

Поэтапный подход к созданию хранилища данных

Многие проекты по развертыванию решений бизнес-аналитики и созданию хранилищ данных начинаются с амбициозных планов – спроектировать и разработать лучшее в мире агрегированное многомерное хранилище данных, поддерживающее репликацию подмножеств многомерных данных в удаленные местоположения (другими словами, поддерживающее киоски данных). Но всегда ли необходим подобный подход и можно ли его реализовать? Почти во всех проектах по развертыванию решений бизнес-аналитики и созданию хранилищ данных недооценивается объем времени и ресурсов, необходимых для того, чтобы спроектировать агрегирование, очистку, построение и (или) репликацию данных в независимые MOLAP-хранилища для поддержки требований всего предприятия.

Уровень готовности предприятий к внедрению решений бизнес-аналитики и требуемая квалификация его сотрудников могут существенно различаться. Разбивая общую задачу на мелкие промежуточные версии, созданные с применением гибких технологий, команды разработчиков приобретут опыт и знания и поймут, как достичь более крупных долгосрочных целей. Помните о правиле 80/20: почти всегда для реализации 80 % необходимой функциональности требуется 20 % усилий. Рассмотрите возможность использования упрощенного поэтапного подхода, как показано на рисунке 1.

Рисунок 1. Глобальные этапы развертывания бизнес-аналитики и создания хранилища данных (щелкните рисунок, чтобы  увеличить изображение)

Этап 1

Если потребность в бизнес-аналитике возникает время от времени, оставьте как можно больше исходных данных на своих местах и постройте многомерные представления с помощью стратегии распределенного кэширования, чтобы быстро внедрить несколько бизнес-решений. Можно ли эффективно выполнять запросы к существующим хранилищам данных приложений, даже если они базируются на разных платформах, с помощью расширенных инструментов от сторонних поставщиков? Ответить на этот важный вопрос нужно уже на ранних этапах. С помощью подобного подхода возможно решать задачи бизнес-аналитики вида «Показать, что сейчас происходит на предприятии». Эта стратегия подходит, если используются несовместимые технологии от поставщиков либо если хранилища данных, расположенные в различных подразделениях, строго разграничены. Это намного эффективнее (если оценивать с точки зрения затрат разработчиков в человеко-часах) и позволяет ускорить развертывание необходимых решений в подразделениях компании.

Данная стратегия иногда ведет к увеличению времени ожидания для пользователей. Однако с помощью таких инструментов, как службы SSIS, можно создавать пакеты для получения, агрегирования и очистки больших объемов данных (даже из хранилищ, не использующих технологии Microsoft), создавать многомерные отношения в кэше памяти и представлять их приложениям по запросу посредством Microsoft SQL Server Analysis Services (SSAS). В прошлом подобный подход имел смысл только для сравнительно небольших объемов данных. Однако благодаря улучшениям, выполняемым поставщиками баз данных, он постепенно реализуется на практике.

Этап 2

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

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

Этап 3

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

Определение тенденций за прошлые периоды и интеллектуальный анализ данных можно выполнять на местах (чтение, использование или агрегирование данных из репозиториев, созданных на этапе 2 [или даже на этапе 1]). Однако при реализации необработанной отчетности и информационной панели с поддержкой детальной информации, которая обеспечивала бы доступ к очень большому объему данных всего предприятия, вероятно, самым эффективным вариантом является централизованное хранилище данных. Однако многие успешные проекты по реализации бизнес-аналитики, скорее всего, будут пред­ставлять собой нечто среднее между этапом 2 и этапом 3.

Проектирование эффективного, производительного,
удобного в сопровождении многомерного хранилища данных

По мере развития технологий хранения данных статическая стратегия репликации больших объемов данных только для чтения, используемых для создания отчетности, превратилась в значительно более динамичную среду, где пользователям предоставляются широкие возможности. Так, им доступно построение собственных динамических запросов, самостоятельная работа с отчетностью (с помощью таких инструментов, как PowerPivot (ранее назывался Gemini) и расширения Office Excel 2010, которое появится в первой половине 2010 года и позволит делать запросы многомерных данных длиной свыше 100 млн строк для кэшированного сведения данных в режиме реального времени), и даже возможность записи данных напрямую в многомерные хранилища.

Мощность инструментов, доступных во время проектирования, в значительной мере влияет на качество моделей, помогает справиться со сложностью отношений путем их визуализации, отображает потенциально узкие места, проблемы в структуре запросов и неэффективную семантику интеллектуального анализа данных. Конструктор SSAS в Business Intelligence Design Studio (BIDS) предоставляет архитектору комплексный набор инструментов для проектирования и оптимизации многомерных хранилищ данных и запросов, выполняемых в подобных хранилищах (см. рисунок 2).

Рисунок 2. Конструктор SSAS: многомерное моделирование в среде BIDS
(щелкните рисунок, чтобы увеличить изображение)

Ниже перечислено несколько ключевых принципов, о которых стоит помнить при проектировании многомерных моделей хранилища данных, чтобы впоследствии обеспечить максимальную производительность (более подробные статьи, посвященные этой теме и расширенному проектированию SSAS, можно найти по адресу https://technet.microsoft.com/en-us/magazine/2008.04.dwperformance.aspxи http://www.ssas-info.com/analysis-services-papers/1216-sql-server-2008-white-paper-analysis-services-performance-guide):

  1. Подавляющее большинство данных MOLAP будет создаваться в таблицах фактов. Уменьшайте количество измерений в таблицах фактов, поскольку обработка запросов наиболее эффективна для таблиц с ограниченным числом столбцов. Увеличивайте глубину атрибутов в соответствующих таблицах измерений. Преимущества от разбиения таблиц измерений на подтаблицы в тех случаях, когда это возможно (схема «снежинка») стали предметом жаркой дискуссии, хотя этот подход в целом обеспечивает большую гибкость, если рассматривать модели горизонтального масштабирования, использование индексов и технологий, таких как секционирование, позволяющих увеличить производительность.
  2. Реализуйте суррогатные ключи для обслуживания связей по ключу между таблицами фактов и таблицами измерений вместо того, чтобы создавать ограничения внешнего ключа, которые зачастую являются составными ключами, охватывающими несколько столбцов. Суррогатный ключ – это столбец целочисленных идентификаторов, служащий искусственным первичным ключом таблицы измерений. Подобный подход позволяет снизить потребность в хранении и уменьшить нагрузку на хранилище и издержки на обработку данных при индексировании.
  3. Хранилища данных в OLTP-системах, как правило, являются высоко­нормализованными, но для многомерных хранилищ это не столь важно. Использование ненормализованных данных в хранилищах очень большого объема имеет определенные преимущества, а именно позволяет снизить число присоединений, которые необходимо указывать в запросах. Кроме этого, такие СУБД, как SQL Server 2008, используют высокооптимизированную фильтрацию по битовым картам (иначе «фильтры Блума»), когда избыточные и ненужные данные устраняются из обработки запросов для соединений типа «звезда».
  4. Прототип, прототип, прототип. Проектирования на физическом уровне может быть достаточно для первоначальных потребностей статической отчетности. Однако по мере того как пользователи привыкают к новым доступным данным и приобретают опыт, потребуется реализовать серьезную поддержку динамических запросов. При работе с динамическими запросами могут создаваться бурно растущие наборы данных (в зависимости от структуры моделирования данных прошлых периодов в рамках существующих измерений). Большинство СУБД поддерживают секционирование для тестирования и моделирования. Уделите достаточно времени пониманию общего влияния на ИТ-среду (включая индексы и обслуживание), если рассматриваете возможность реализации динамических запросов. Внедрение решений для самостоятельной бизнес-аналитики, например PowerPivot, вместо открытой поддержки динамических запросов может существенно снизить требования к серверу за счет того, что большие блоки многомерных данных будут поставляться клиентам напрямую, чтобы облегчить работу пользователей с детализацией данных.
  5. Реализуйте кластеризованный индекс для часто используемых суррогатных ключей в таблицах фактов, а также некластеризованные индексы – для каждого из остальных суррогатных ключей. Реализация динамических запросов может существенно изменить стратегию индексирования (см. пункт 4). Однако для общих широко используемых шаблонов подобная стратегия доказала свою эффек­тивность.
  6. Используйте параллелизм секционированных таблиц. В связи с разрастанием таблиц фактов с течением времени, большинство архитекторов хранилищ данных реализуют стратегию секционирования (распределение таблицы фактов по нес­кольким физическим запоминающим устройствам). В большинстве случаев секционирование выполняется по столбцам данных, но может осуществляться также и на основе диапазонов, определяемых в зависимости от характера использования (поддерживается в SQL Server 2008). В SQL Server 2008 реализована новая функция параллелизма секционированных таблиц (PTP), которая значительно улучшает выполнение запросов к секционированным таблицам путем их распараллеливания с использованием доступных многоядерных процессоров. Более подробная информация по функции параллелизма секционированных таблиц и других нововведений SQL Server 2008, касающихся хранилищ данных, приведена по адресу https://technet.microsoft.com/en-us/library/cc278097.aspx.
  7. Реализуйте стратегию сжатия данных. Со временем размер хранилища данных может стать огромным. Затраты на сжатие данных зачастую компенсируются уменьшением объема избыточных данных. Как следствие, время обработки данных сокращается, появляются преимущества от обслуживания хранилища данных меньшего объема. Тем не менее общая стратегия заключается в сжатии наименее используемых данных. Сжатие можно осуществлять на уровне разделов, страниц, строк и пр. Для создания наиболее эффективного шаблона потребуется расширен­ное прототипирование (см. пункт 4).

Консолидация, агрегирование и наполнение хранилищ данных

К счастью, когда будет определено, к каким данным требуется доступ, и спроектирована топология хранилища данных, задачи агрегирования и наполнения упростятся – благодаря усовершенствованным программным инструментам от поставщиков. При помощи таких инструментов, как службы SSIS в среде Business Intelligence Design Studio (поставляется с выпуском SQL Server Enterprise Edition), архитектор может создать «пакет», занимающийся выборкой, очисткой, публикацией данных, а также управлением ими. Службы SSIS поставляются с компонентами для подключения к данным, которые позволяют архитектору проектировать пакеты для доступа ко всем крупным СУБД (включая Oracle, IBM, Teradata и др.). Кроме того, эти службы содержат комплексный набор процедур для обработки данных, представленных в виде удобных визуальных инструментов, позволяющих легко выполнять операции перетаскивания в визуальной модели потоков данных (см. рисунок 3).

Рисунок 3. Представление потока данных служб SSIS в среде BIDS
(щелкните рисунок, чтобы увеличить изображение)

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

Службы SSIS можно сравнить с большинством традиционных инструментов для извле­чения, преобразования и загрузки данных (ETL), но эти службы имеют намного более широкий набор функциональных возможностей для дополнения динамической MOLAP-среды хранилища данных, реализованной в SQL Server 2008 и службах Analysis Services. Например, сложные пакеты служб SSIS можно добавлять в хранилище данных и динамически вызывать хранимыми процедурами, чтобы выполнять операции в зависимости от условных данных, передаваемых из механизма служб Analysis Services. Множество партнеров Microsoft – независимых поставщиков ПО – разработали сложные стратегии исполнения пакета служб SSIS, которые вызываются рабочими процессами Windows Workflow Foundation (WF). Благодаря этому появляется возможность управлять сценариями агрегирования данных, которые в значительной степени зависят от состояния или выполняются длительное время.

Более подробный обзор служб SSIS приведен по адресу https://download.microsoft.com/download/a/c/d/acd8e043-d69b-4f09-bc9e-4168b65aaa71/ssis2008Intro.doc.

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

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

Залог успеха – использование эффективной репликации моментальных, доступных только для чтения снимков предопределенных агрегированных подмножеств. Это означает, что необходимо тщательно проанализировать потребности каждого независимого местоположения и использовать расширенные возможности СУБД, в частности масштабного сжатия данных и разреженных столбцов. «Разреженный» – это новый атрибут столбца, доступный в SQL Server 2008, при использовании которого пустые значения (null) не имеют физического размера. Поскольку хранилища данных, как правило, заполнены огромным количеством пустых значений (к примеру, ежедневно приобретаются не все пары обуви во всех магазинах всех регионов), то сжатие физического размера подобных полей или его сведение к нулю крайне важно. Многие традиционные продукты для реализации хранилищ данных не располагают подобной возможностью. Помимо этого, SQL Server 2008 имеет множество преимуществ с точки зрения производительности при репликации больших объемов многомерных данных.

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

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

Как быть с продвинутыми пользователями, которым требуется бизнес-аналитика на мобильных устройствах при отсутствии подключения к Интернету? Платформа Microsoft позволяет предоставить доступ к мощной бизнес-аналитике даже в случае автономной работы – с помощью выпусков SQL Server CE или Express Edition, установленных на стороне клиента. Корпорация Microsoft сотрудничает с десятками международных независимых поставщиков ПО, разработавших наборы приложений, которые используют крупные многомерные кубы данных в офлайновом режиме на клиенте. Вы можете разработать стратегию репликации базы данных на стороне клиента, когда репликация будет осуществляться после установки соединения с мобильным пользователем. А разработчики приложений могут реализовать службы Microsoft Synchronization Services для ADO.NET и управлять репликацией данных, необходимой для конкретного потока операций внутри приложения. Более подробная информация находится по адресу https://msdn.microsoft.com/en-us/sync/default.aspx.

Заключение

Для развертывания решений бизнес-аналитики на предприятии потребуются, прежде всего, существенные вложения. Они необходимы для того, чтобы получить достаточно полное представление о данных предприятия, находящихся в пределах доступа. Такие модели многомерных хранилищ данных, как шаблоны проектирования хранилищ данных (MOLAP и др.), доказали свою эффективность при работе с запросами к данным чрезвычайно большого объема, которые с большой вероятностью включают данные прошлых периодов. Более подробная информация относительно реализации хранилищ данных и бизнес-аналитики при помощи SQL Server 2008 находится по адресу https://www.microsoft.com/sqlserver/2008/en/us/white-papers.aspx. Кроме того, чтобы ознако­миться с реальными примерами горизонтального масштабирования, изучите передовые практики от команды SQL CAT, расположенные по адресу http://sqlcat.com/.

Об авторе

Чарльз Фихтер

(cfichter@microsoft.com) – ведущий архитектор решений в группе Developer Evangelism, Global ISV корпорации Microsoft. Г-н Фихтер занимается разработкой архитекторы программного обеспечения и баз данных уже 20 лет. Он специа­лизируется на бизнес-аналитике, решениях Microsoft SQL Server и Microsoft BizTalk Server, а также на проектировании баз данных и .NET-приложений среднего уровня и уровня данных. Последние четыре с половиной года г-н Фихтер помогает международным независимым поставщикам ПО в формировании стратегий проекти­рования приложений. Среди других недавних публикаций г-на Фихтера:

Дополнительная информация по теме: