Совет №24
Разрабатываем измерения в многонациональном хранилище данных
Материал опубликован с разрешения компании
Автор оригинала: Ральф Кимбалл (все
статьи)
Перевод на русский язык: Константин Лисянский
Оригинальный документ располагается здесь.
Если вы занимаетесь многонациональным хранилищем данных, вы можете
столкнуться с проблемой представления содержания хранилища данных
на ряде различных языков. Какие части хранилища нуждаются в переводе?
Где хранить версии на разных языках? Как вы обращаетесь с открытостью,
когда нужно добавлять версии на новых языках?
При построении истинно многонационального хранилища данных встречается
много проблем проектирования. Я попытался осветить их в книге Data
Webhouse Toolkit, так что в этом совете мы сконцентрируемся только
на том, как представить конечным пользователем результаты "с
возможностью переключения языков" и не будем обсуждать:
валюты
разделительные знаки
часовые пояса
разбор имён и адресов
представления телефонных номеров
Нашей целью будет свободное переключение между представлениями
в расширяющемся множестве языков, как для непредвиденных запросов,
так и для стандартных отчётов. Мы также хотим выполнять операцию
drill across в распределённом многонациональном хранилище данных,
построенном на согласованных измерениях.
Очевидно, что основное наше внимание должно быть сосредоточено
на наших измерениях. Измерения являются репозиториями практически
всей текстовой информации наших хранилищ данных. Измерения хранят
подписи, иерархии, и описания наших данных. Измерения управляют
содержимым интерфейсов пользователя и предоставляют содержимое заголовков
строк и столбцов всех наших отчётов.
Прямолинейный подход заключается в предоставлении полных переведённых
копий каждого измерения на каждый поддерживаемый язык. Другими словами,
если у нас есть измерение ПРОДУКТ, изначально описанное на английском
языке, а мы хотим иметь немецкую и французскую версии, мы копируем
английское измерение строка за строкой и столбец в столбец, сохраняя
ключи и цифровые индикаторы, переводя при этом все текстовые атрибуты.
Но мы должны быть внимательными. Чтобы сохранить интерфейс пользователя
и окончательные результаты английской версии, как немецкая, так
и французская версия измерения ПРОДУКТ должны буду сохранить те
же самые
отношения 1-к-1 и многие-к-1, а также
логику группировки как для не предопределенных отчётов, так
и для построения агрегатов.
Явно понимаемые отношения 1-к-1 и многие-к-1 должны быть определённо
усилены моделью сущность-связь в области перегрузки. Это легко осуществить.
Но затем возникает тонкая проблема при переводе, которая заключается
в том, чтобы не перевести два разных английских названия атрибута
одним и тем же словом на немецком или французском языках. Например,
если английские слова 'scarlet' и 'crimson' переведены на немецкий
одним и тем же словом 'rot', некоторые суммарные данные в отчётах
будут отличаться в английской и немецкой версиях. Поэтому нам нужен
дополнительный шаг ETL, который будет проверять, что мы не перевели
два разных английских слова одинаково.
Большим преимуществом такого дизайна является масштабируемость,
так как мы всегда можем добавить новый иностранный язык без изменения
структуры таблиц и повторной загрузки базы данных.
Мы можем позволить французским или немецким пользователям осуществлять
операцию drill across к далеко заброшенному распределённому хранилищу
данных, если мы РЕПЛИЦИРУЕМ переведённые версии измерений во все
удалённые витрины данных. Помните о том, что когда мы осуществляем
операцию drill across к распределённым витринам данных, мы выполняем
основные запросы удалённо. Именно поэтому переведённые измерения
должны располагаться в каждой целевой базе данных.
Когда французский или немецкий пользователь запускает запрос drill
across, каждая удалённая витрина данных должна использовать правильные
переведённые измерения. Они будут достаточно легко обработаны первоначальным
французским/немецким приложением, которое формулирует запрос. Заметьте,
что каждая удалённая база данных должна поддерживать "измерения
с горячей заменой", которые позволяют выполнять это переключение
измерений от запроса к запросу по мере поступления запросов на разных
языках. В реляционной среде это достаточно просто, но может быть
нелегко в среде OLAP.
Хотя мы многое сделали с помощью этого дизайна, включая масштабируемый
подход к внедрению распределённого многоязычного хранилища данных,
у нас всё ещё есть неразрешённые проблемы, которые являются откровенно
серьёзными:
мы не можем легко сохранять порядок сортировки в разных языковых
версиях одного отчёта. Естественно, мы не можем отсортировать
переведённые атрибуты в том же порядке, что и на основном языке.
Если требуется сохранить порядок сортировки, то нам понадобится
гибридное измерение, как с основным языком, так и со вторым, чтобы
запрос SQL производил сортировку на основном языке, но результаты
показывал на втором языке как не отсортированные строки. Это громоздко
и приводит к измерениям вдвое большего размера, но, возможно будет
работать.
если основной язык - английский, мы, возможно, обнаружим, что
почти во всех остальных языках длина переведённого текста будет
больше, чем длина текста на английском. Не спрашивайте меня, почему.
Но это представляет проблемы при форматировании пользовательских
интерфейсов и отчётов.
наконец, если наш набор языков выходит за рамки английского
и основных европейских языков, то даже расширенного набора восьмибитных
символов кодировки ASCII будет недостаточно. Все участвующие витрины
данных должны будут поддерживать 16-битную кодировку UNICODE.
Помните, что наш дизайн требует, чтобы переведённые измерения
находились на целевых машинах.
Дизайн распределённого многоязычного хранилища данных является
завораживающей и важной задачей. Я бы хотел услышать об интересных
подходах и неподатливых проблемах. Пишите мне.
Всего наилучшего,
Ральф
Ralph Kimball (ralph@ralphkimball.com)
Если вы нашли в сети интересные ссылки на ресурсы по технологиям
хранилищ данных, OLAP, CRM или data mining, и хотите поделиться
ими с другими, присылайте их.
Я с удовольствием размещу их на этом сайте.
RSS