|
Сивостен :: Бази данни: Обектният подход (статия) - Компютри, Бази данни
 | |
За да говорим за обектни бази данни, или обектно ориентирани бази данни, в зависимост кое от названията използваме, първо може би се налага да изясним що е то обект. В термините на компютърните науки обектът е променлива от даден клас. Класът от своя страна е тип, дефиниран от потребителя, състоящ се от данни (променливи) и функции (методи). Бидейки доста объркваща за неспециалиста, пък и за хората, които за първи път се сблъскват с обектния стил на програмиране, тази дефиниция не ни върши особена работа. Затова нека кажем така – за компютрите обектът е това, което за биологията е Пешо. Пешо е обект от клас човек. Класът човек има някои характеристики – цвят на очите, цвят на кожата, окосмяване по лицето и т.н. Homo sapiens има и методи, например да се почесва по врата с ръка, докато чете подобно на настоящето изложение. Или иначе казано – класовете и обектите са най-близката до реалния свят репрезентация на данните в компютърните науки. Поне до този момент.
Какво е обектна база данни? Когато тази философия – на класовете и обектите - бъде интегрирана в система за управление на бази от данни, получаваме обектна такава. Обектните бази данни са продължение на езика, допълващи го с възможности за постоянно съхранение на данни, подчиняващо се на принципа ACID - атомарност (atomicity), цялостност (consistency), изолирано изпълнение (isolation), устойчивост и надежност (durability) ( за повече информация). Могат да бъдат изграждани както върху съществуващи данни, така и на чисто.
В първия случай имаме обектна база данни, която съдържа информацията за обектите, както и някои от данните, които ги няма при създаването и, както и „карти” на съществуващите данни и как се отнасят те към обектния модел. При този случай получаваме модел на информацията, съответстващ с този, използван в езика, на който е написано приложението, работещо с нея. Но нямаме толкова висока производителност. При втория – когато е проектирана като обектна, имаме запазване на данните в модела, в който се използва и получаваме именно тази ефективност, която прави обектните бази данни използваеми и използвани в индустрията.
Звучи логично бази от данни, базирани на тази абстракция, да са предпочитани, дори най-използвани. Но за съжаление, редица причини ги правят по-скоро специфични за даден проект, отколкото масови за индустрията. Причини, които ще споменем по-късно. Но нека се занимаем с историята на обектните бази данни. Началото им се корени още в първата половина на осемдесетте години на миналия век, когато Уон Ким започва изследователския си проект ORION. Този проект дава началото на вече несъществуващата ITASCA и Versant.
Няколко години по-късно във Франция се ражда първият продукт, който реално влиза в експлоатация – Graphael. Използван в полето на ядрената енергетика в началото, по-късно той бива напълно пренаписан и се превръща в Matisse, осмата версия, която е кръстоска между обектното и релационното начало в базите данни, обслужвайки нуждите и на двата типа потребители, поддържайки както SQL, така и XML, и обекти. Всъщност именно този тип интегриране на двата свята в един продукт като че ли е бъдещето, имайки предвид, че пазарът на системи за управление на обектни бази данни бележи значителен спад през последните осем години.
Деветдесетте години на миналия век бележат най-големия ръст в този клон на индустрията. Появяват се обектния език за заявки, както и небезизвестният SQL 99, които надграждат и двата подхода в базите данни. Публикува се манифеста на Малкълм Аткинсън, появява се цяла серия от продукти, докато пазарът достига пика си през 2000-та година и започва да се свива все повече и повече за сметка на хибридните реализации. Все пак се оказва, че цялото усилие не е било напразно и въпреки невъзможността да бъде победен релационният модел на базите данни, обектно ориентираните такива повлияват на индустрията в доста голяма степен и остават използвани, макар и в своята малка ниша.
Но къде всъщност се използват обектните бази данни? В ежедневния живот, дори на един специалист, рядко се споменават, далеч по-рядко от релационните им събратя. Но въпреки това бизнесът е открил мястото им. Не една и две големи международни компании са интегрирали технологията, макар и за специфични нужди. Например Британските авиолинии използва Versant, в търсене на максимален приход от мрежата си от полети. Siemens пък от своя страна използва GemStone в системата за реалновремево управление на мрежови и системни инфраструктури CONDIS, с която се сблъскваме всеки път, като се качим на влак в Швейцария, говорим по телефона в Аржентина или... просто се разхождаме из Лондонското сити. Примерите минават през медицината, за да достигнат чак до въоръжените сили на САЩ. Изобщо мит е, че обектните бази данни са едва ли не теоретична занимавка и е факт, че за определени дейности са незаменими.
Всъщност още един мит е, че обектните бази данни са по-бавни от релационните. Това е и вярно, и невярно. От една страна, трудно е да се каже точно колко са „бързи” обектните бази данни, имайки предвид значителните разлики между две различни базирани например на различна архитектура на ядрото, как е реализиран конкурентният достъп до данните, мрежовият модел или заявките. Всички тези фактори, когато отговарят на конкретната нужда могат да доведат до случай, в който обектната реализация е до десет хиляди пъти по-бърза от релационната. При втората, обаче, далеч нямаме толкова големи отклонения между две различни реализации – всъщност между два производителя разликата би била от порядъка на десети от процента.
Това всъщност отговаря и на въпроса кога се използват този тип бази данни – когато се търси висока производителност. Кога се намира тази производителност? Когато базата данни работи с комплексна по своя характер информация. Тя често се характеризира с липса на натурален уникален идентификатор на даден обект. Например ако говорим за хора, можем да използваме ЕГН като такъв, но всички сме чували за случаи за хора без ЕГН. Освен това в релационния модел използването на голямо количество релации от типа много към много затруднява работата, а при комплексните данни това не е рядко срещан случай. Освен това обектните бази данни запазват информацията по абсолютно същия начин, по който тя се намира в програмния код, което значително улеснява създаването на програми за достъп до данните. Естествено, това води до намаляване на разходите и в случай че други от условията са изпълнени и получаваме задоволителна производителност, се оказва, че използването на обектни бази данни е добра идея.
Именно тези неща правят обектните бази данни строго специфични за даден проект. Необходимостта да разбираш разликите в архитектурата на различни реализации и нуждата да подбереш точната такава за конкретната програма, която ще я използва, изключва възможността за масовост. В случая, когато има нужда от сигурно запазване на данни за дълъг период от време, но не е ясно точно как, защо ще бъдат достъпвани – по-добрият вариант е релационният. Но пък има задачи, с които традиционният модел не може да се справи - достатъчно комплексни модели, които няма как ефективно да бъдат вкарани и използвани в релационни бази данни, така че, независимо от факта, че бъдещето им изглежда несигурно и има уклон към използването на хибриден модел, обектните бази данни ще намират своето приложение и в бъдеще. |
 Добави коментар 
Ако сте регистрирани във форума можете да коментирате и тук
|
|
• 
Български • 
English [beta] • 
• 
• 
Екип • 
Партньори • 
Ресурси • 
Статистики • 
За контакт
Добави в любими • Предложи статия • Конкурси • За рекламодатели
Търсене
покажи/скрий карето 
