Блог за IT Бизнес

При теоретичните анализи на даден проблем е допустимо да се допусне, че една система може да се намира в състояние, което най-общо може да бъде определяно като „крайно”. На практика това е идеален случай и една реална система се намират в състояние на относителна неопределеност през целия цикъл на своето съществуване.
С особена сила това важи за мултимедийните обекти, поради тяхната специфика. Това налага използването на един различен подход при тяхното систематизиране, редактиране и използване.
Тема на настоящият доклад са мултимедийните бази данни (Multimedia Database – MDB) и различните аспекти при тяхното практическо приложение.

Определение: Мултимедийни бази данни (Multimedia Database – MDB) ще наричамe бази от данни, които съдържат в себе си мултимедийна информация, както и съпътстващи методи, имащи отношение към нейната обработка.

В общият случай за целта се използват BLOB (Binary Large OBject ) полета, а при някои специфични решения CLOB (Character Large Object) и променливи от типа дълъг символен низ (LongString).

При всички познати към настоящият момент СУБД BLOB полетата се използват за съхраняване неструктuрирани данни (аудио и видео информация, OLE-обекти и др.). При използване на подобен подход информацията не се съхраняват непосредствено в работната таблица. Записите съдържат само идентификатори на полето, а самото тяло се намира в отделна странница, като достъпът се осъществява посредством специализирани функции. Това позволява да бъдат въвеждани данни с произволен размер.

Съществуват четири основни метода, имащи отношение към обработката на такъв тип полета:

• LoadFromFile;
• LoadFromStream;
• SaveToFile;
• SaveToStream;

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

Важно е да обърнем внимание, че при промяна съдържанието на BLOB полето, използваният индекс се премахва, като по този начин се избягва възможността да бъде повторно използван.

При някои СУБД (като например InterBase SMP 2009) съществува набор от функции, които позволяват BLOB полета, намиращи се на отдалечен сървър да бъдат достъпни за потребителски приложения. Това е от изключително значение, когато става дума за MDB, поради голямата по обем информация, която се обменя между клиента и сървъра за данни.

Независимо, че в случай на нужда съдържанието на BLOB полето може да бъде архивирано вътре в самата база данни това не би довело до намаляване на мрежовият трафик, тъй като сървърът и крайните приложения обменят информация в некомпресиран вид.

За да се ускори обменът е нужно да се прибегне до различен подход, а именно – филтриране от страна на клиента. За целта могат да бъдат използвани външни за СУБД функции, които извършват архивиране и дезархивиране на съдържанието на полето. По този начин между клиентската и сървърната част ще се предават предварително компресирани данни, което би довело до снижаване на трафика. Използване на междинен слой, от друга страна, позволява промените да се извършват централизирано, като при това чувствително се опростява използваният програмен код и се намалява вероятността от грешки.

Възможно е да бъдат използвани и вътрешни за базите данни процедури, но е важно да се знае дали СУБД не изисква задължително да бъде указан под вида на входните параметри (например subtype 1 – текстова информация).

Ако по някаква причина е допуснат пропуск системата автоматично ще присвои на BLOB SUB_TYPE нулева стойност и  реално данните няма да претърпят никакви изменения.

Друга особеност на MDB е възможността всяко едно BLOB поле да съдържа различна по характер информация. В този случай полето може да бъде разглеждано като съставен обект със всички произтичащи от това последствия. На практика крайният потребител би разполагал с достъп до обектно-релационна система, с променлива размерност на основните полета. Едно от основните свойства на подобен тип системи е тяхната неопределеност. На тази специфична особенност ще се спрем малко по-късно, когато разглеждаме въпросите, свързани със сигурността.

При изграждане на мултимедийни бази данни са възможни два основни подхода:

При първият клиентът осъществява непосредствен контакт със СУБД, като за целта използва SQL, но това поражда значителни проблеми свързани с преноса и съвместимостта, но най-вече поради липсата на ясно дефинирани правила при работата с индекси. Друг аспект е, че при мултимедийните бази от данни се работи с неструктурирана информация. В случаят става дума за чисто теоретичен въпрос доколко подходът, при който се ползва само и единствено SQL отговаря в пълна степен на разглежданията на Тюринг, касаещи приложението на структурирани, програмни езици.

При вторият подход (който е и основен за нашите разглеждания) се използва трислойно приложение, като целта е да се подобри паралелността при работа с БД.

Един от основните проблеми при работа с бази данни, се изразява в намаляване на възможността няколко ползватели да внасят изменения в общата база, при транзакции, които са активни за продължителен период от време. Причината е, че записа, в който са внасят корекции се блокира, до окончателното потвърждаване на направените промени. Този проблем е още по-сериозен, когато се налага да бъде блокирана странница.

В случая на използване на трислойни приложения всички направени промени се извършват в кеша, т.е. в локално копие. Направените изменения не се записват в основната база докато не се предизвика събитие. Тъй като транзакцията е активна на сървъра само по време на копиране на информацията от кеша, което отнема части от секундата, паралелизма при работа с обща база данни рязко се подобрява.
Да предположим, че се налага да разработваме мултимедийни приложения, чието предназначение предоставят on line информация за големи  групи клиенти. Нормално е потенциалните ползватели (особено ако става дума за корпоративни такива) да са направили избор на сървърната платформа, така че ще се наложи приложението да се интегрира с Oracle, Microsoft SQL, DB2, Interbase или някаква друга система за работа с бази от данни.  В този случай е добре цялата логика на приложението да бъде пренесена в клиентската част. Това позволява кода да бъде реализиран основно от страна на клиента, без да се интересуваме какъв конкретен тип СУБД ще бъде използван. Съединяването с конкретната база данни се поема изцяло от сървъра. Силата на подобен подход си проличава най-добре когато потребителят на системата реши да промени избраната платформа.

Едно стандартно трислойно приложение се състои от следните основни компоненти:

• Слой на базата данни – Служи за съхраняване на данните. Обезпечава съхранението, цялостта и непротиворечивостта на информационните масиви. Данните могат да бъдат както локални таблици (dBase, Paradox, FoxPro, текстови файлове и др.) така и сървърни бази от данни (Oracle, DB2, Sybase, MS SQL и др).

• Слой на бизнес логиката (сървър за приложения) – Програма, обезпечаваща услугите, ползвани от крайния клиент. В този слой се реализират правилата и алгоритмите, служещи за моделиране на реално съществуващ обект (бизнес правила).

• Презентационнен слой (тънък клиент) – Служи за предоставяне на крайния клиент на генерираната в слоя на бизнес логиката информация в подходящ за ползване вид. Тук съществуват два различни подхода. При единият този слой се реализира във вид на традиционен изпълним файл (клиентско приложение), а при втория се използва web-броузър. Всеки един от двата подхода има както предимства така и недостатъци, а изборът се определя от спецификата на поставената задача.

Както се вижда от гореизложеното, цялата логика, имаща отношение към работата с БД е концентрирана в средният слой (сървърът за приложения). Това на практика позволява измененията в алгоритмите и методите на обработка да се реализират без да се налага да се преработва клиентската или сървърни части. Това е от изключително значение при работа с MDB поради спецификата на извършваните транзакции.

Една от характерните особености при работата с трислойна архитектура при мултимедийните бази от данни е използването на т.н. опростени заявки (Simple Query String – SQS). Този подход се налага за да се избегнат голяма част от проблемите при използване на SQL, описани подробно от  Eдгар Код (Edgar Codd) и Кристофър Дейт (Christopher Date).

Опростените заявки не са език за програмиране, а по-скоро набор от средства, позволяващи на крайния потребител да извършва операции с данните, без да бъде в състояние да провежда SQL атака. Опростените заявки както и мултимедийните таблици (Multimedia Table) са елемент на средния слой. Поради огромният обем информация, имаща отношение към тези два елемента те не са предмет на настоящият доклад.

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