Моделирование мультиязычной структуры

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

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

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

Рис. 4.66. Пример мультиязычности на основе языковых атрибутов.

Важно отметить одну особенность использования типов данных при необходимости представления данных в национальных алфавитах. Как очевидно из примера, для атрибута «Наименование товара (ког)» указан тип данных «КУЛИСНАЯ», в отличие от других аналогичных атрибутов. Объясняется это тем, что арабские и азиатские группы языков представляются не привычными символами латиницы или кириллицы, а изображениями, обозначающими комбинации символов или иероглифы. Для хранения таких данных обычный символьный тип данных нс годится, поскольку ориентирован на кодовую таблицу символов из 256 элементов, включающих латиницу или кириллицу. Для хранения строковых данных по другим языковым группам необходимо значительно больше количество памяти и имеющихся 256 элементов кодовой таблицы недостаточно. Поэтому для подобных представлений текста используются двухбайтовые элементы и для них представляются отдельные типы данных, обозначаемые " п…" . Поэтому для корейского, китайского или японского языка используется такой тин данных, а максимальная размерность строки определяется в два раза больше, чем это нужно для латиницы и кириллицы.

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

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

Рис. 4.67. Пример сущности «Языки» .

Данная сущность также может быть создана на основе нормализации сущности «Товары», где целесообразно указать атрибут «Язык». Процесс нормализации в этом случае приведет к созданию сущности-связки между товарами и языком (рис. 4.68).

Рис. 4.68. Нормализация мультиязычного представления товара.

Такой вариант организации мультиязычиости для конкретного объекта вполне применим и позволяет сиять проблему реализации представления данных на различных языках. При его формировании атрибут «Наименование товара» должен быть перемещен в сущность-связку, обеспечив, тем самым, единственность экземпляра в сущности «Товары» и все возможные варианты языкового представления.

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

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

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

Рис. 4.69. Пример сущности с символьными элементами.

Размерность атрибута «Символьный код строки» определяется разработчиком в соответствии с теми возможными значениями, которые там нужно будет хранить.

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

В результате проведения такой нормализации, учитывая универсальность всех используемых сущностей, разработчик получает модель, которую можно связать с функциональными сущностями или классификаторами, обеспечив языковую поддержку наименований (рис. 4.70). Важно отметить, что в сущности-связке используется не один символьный атрибут, хранящий языковые значения, а два. Это необходимо, как ранее объяснялось, для возможности хранения коротких данных в виде одной строки и больших текстовых данных многострочного характера. При этом типы данных, с учетом необходимости хранения строк па языках азиатской и прочих групп, могут быть определены в значении «МУАКСНАИ» и «ЫСЬОВ» .

Рис. 4.70. Языковое представление символьного идентификатора.

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

При определении связи между сущностями «Товары» и «Строковый идентификатор» нужно выяснить, каким образом будет обеспечиваться именование товаров. Если предполагается, что каждый товар своим наименованием уникален, то связь между этими сущностями будет один — к — одному (1:1), но эту связь нормализовывать нецелесообразно, поскольку сущность «Строковый идентификатор» не может быть удалена ввиду ее связи с другим сущностями, где требуется языковая поддержка (рис. 4.71).

Рис. 4.71. Связывание языкового представления с функциональной сущностью.

В случае если в каталоге товаров могут появиться одинаковые наименования, например, когда каталог содержит списки товаров, не только продаваемых в данный момент, но и продаваемых ранее по другой цене, тогда связь между сущностями будет один — ко — многим (1:Д^), в направлении к сущности «Товары», что и отражено в представленной модели (см. рис. 4.71).

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

Рис. 4.72. Использование неязыковых элементов.

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