Повна версія

Головна arrow Інформатика arrow Бази даних: проектування

  • Увеличить шрифт
  • Уменьшить шрифт


<<   ЗМІСТ   >>

Моделювання мультимовної структури

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

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

а значить, найменування товарів та їх опису повинні бути представлені в будь-якому з варіантів мови.

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

image276

Мал. 4.66. Приклад багатомовності на основі мовних атрибутів


Важливо відзначити одну особливість використання типів даних при необхідності представлення даних в національних алфавітах. Як очевидно з прикладу, для атрибута "Найменування товару (ко)" зазначений тип даних "Кулісні", на відміну від інших аналогічних атрибутів. Пояснюється це тим, що арабські та азійські групи мов подаються не звичними символами латиниці або кирилиці, а зображеннями, що позначають комбінації символів або ієрогліфи. Для зберігання таких даних звичайний символьний тип даних нс годиться, оскільки орієнтований на кодову таблицю символів з 256 елементів, що включають латиницю або кирилицю. Для зберігання строкових даних по іншим мовним групам необхідно значно більше кількість пам'яті і наявних 256 елементів кодової таблиці недостатньо. Тому для подібних уявлень тексту використовуються двобайтові елементи і для них представляються окремі типи даних, що позначаються "п ...". Тому для корейського, китайського або японського мови використовується такий тин даних, а максимальна розмірність рядка визначається в два рази більше, ніж це потрібно для латиниці і кирилиці.

Подання багатомовності в даному виді, очевидно, не дуже гарне рішення, оскільки для кожної мови необхідно створювати окремий атрибут. У разі необхідності додати ще одну мову, потрібно буде проводити реструктуризацію бази даних у вигляді додавання атрибута, а також переробляти програмну логіку, яка залежить від набору атрибутів. Це досить складна і дорога процедура. Тому використання цього варіанту, крім випадків гарантованості зазначених мов, недоцільно.

Іншим варіантом вирішення завдання багатомовності даних є створення відповідної структури бази даних, яка буде враховувати наявні мовні алфавіти і за допомогою структуризації даних визначати правильність подання відомостей. Первинно, для забезпечення роботи з мовами, необхідно мати сутність "Мови" (рис. 4.67), яка дозволить користувачеві отримувати дані на потрібному йому мовою і розділити всі тестові дані з цих мов. Також дана сутність дасть можливість додавати нові мови, що не реструктуріруя бази даних.

image277

Мал. 4.67. Приклад суті "Мови"


Дана сутність також може бути створена на основі нормалізації суті "Товари", де доцільно вказати атрибут "Мова". Процес нормалізації в цьому випадку призведе до створення сутності-зв'язки між товарами і мовою (рис. 4.68).

image278

Мал. 4.68. Нормалізація мультимовного уявлення товару


Такий варіант організації мультіязичіості для конкретного об'єкта цілком можна застосувати і дозволяє сяяти проблему реалізації представлення даних на різних мовах. При його формуванні атрибут "Найменування товару" повинен бути переміщений в сутність-зв'язку, забезпечивши, тим самим, єдиність примірника по суті "Товари" і всі можливі варіанти мовного уявлення.

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

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

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

image279

Мал. 4.69. Приклад суті з символьними елементами


Розмірність атрибута "Символьний код рядка" визначається розробником відповідно до тих можливими значеннями, які там потрібно буде зберігати.

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

В результаті проведення такої нормалізації, з огляду на універсальність всіх використовуваних сутностей, розробник отримує модель, яку можна пов'язати з функціональними сутностями або класифікаторами, забезпечивши мовну підтримку найменувань (рис. 4.70). Важливо відзначити, що по суті-зв'язці використовується не один символьний атрибут, який зберігає мовні значення, а два. Це необхідно, як раніше пояснювалося, для можливості зберігання коротких даних у вигляді одного рядка і великих текстових даних многострочного характеру. При цьому типи даних, з урахуванням необхідності зберігання рядків па мовах азіатської та інших груп, можуть бути визначені у значенні "МУАКСНАІ" і "ИСЬОВ".

image280

Мал. 4.70. Мовне уявлення символьного ідентифікатора


Оскільки сутність "Мовні форми" є зв'язкою, що забезпечує мовне уявлення символьних даних, то її використовувати в якості сполучного елемента недоцільно. Залишається тільки одна сутність, яка може бути пов'язана з функціональними сутностями і яку раніше визначили як ідентифікаційної складової, - це сутність "Строковий ідентифікатор".

При визначенні зв'язку між сутностями "Товари" і "Строковий ідентифікатор" потрібно з'ясувати, яким чином буде забезпечуватися іменування товарів. Якщо передбачається, що кожен товар своїм найменуванням унікальний, то зв'язок між цими сутностями буде один - до - одному (1: 1), але цей зв'язок нормалізувалася недоцільно, оскільки сутність "Строковий ідентифікатор" не може бути видалена з огляду на її зв'язку з іншим сутностями, де потрібно мовна підтримка (рис. 4.71).

image281

Мал. 4.71. Зв'язування мовного уявлення з функціональної сутністю


У разі якщо в каталозі товарів можуть з'явитися однакові найменування, наприклад, коли каталог містить списки товарів, не тільки продаються в даний момент, але і продаються раніше за іншою ціною, тоді зв'язок між сутностями буде один - до - багатьох (1: Д ^) , в напрямку до суті "Товари", що і відображено в представленій моделі (див. рис. 4.71).

І останнім штрихом універсалізації мовної обробки є наявність строкових і текстових відомостей, не пов'язаних з мовними умовами (рис. 4.72). Зазвичай це робиться для з'єднання мовних відомостей з символьними даними, що подаються без урахування мовного алфавіту, тобто завжди на одному обраною мовою. Цих атрибутів по суті "Строковий ідентифікатор" може не бути, але тоді рядкові та текстові дані, не пов'язані з мовним алфавітом, потрібно буде дублювати спільно з символьними даними, закріпленими за певною мовою.

image282

Мал. 4.72. Використання немовних елементів


Використання мовних форм дає можливість розробнику бази даних вибудувати таку модель і, згодом, фізичну базу даних, яка буде враховувати особливості подання інформації на мовах, необхідних замовнику, без використання додаткових доробок.

 
<<   ЗМІСТ   >>