Hibernate ORM (1. део)

Аутор: Дејан Чугаљ

Један патент, који је пријављен још 1884. године, оставио је јединствен печат и начин пројектовања IT апликација садашњим и будућим нараштајима. Херман Холерит (Herman Holerith) патентирао је начин аутоматске обраде података пописа америчког становништва, што је била претеча савременог управљања базама података. То је био патент за који у то време нико није могао ни наслутити да ће тек, скоро седамдесет пет година касније, доживети прави процват – појавом првих рачунара. Модерне базе података су се популаризовале доласком модела исплативих рачунара шездесетих година 20. века, који су се првенствено користили за складиштење података великих компанија и пројеката. У самом почетку развоја база података примењивани су системи засновани на датотекама.

Седамдесетих година 20. века базе података добијају комерцијалну вредност појавом првих система за управљање базама података. Сложене структуре података великих компанија и пројеката су нам дале мрежни и хијерархијски модел као прве системе управљања базама података. Увидевши недостатке постојећих модела база података као што су: тромост при извршавању одређених захтева, велика сложеност приликом измена логичких целина у организацијама – научним радом објављеним 1970. године Едгар Франк „Тед” Код (Edgar Frank „Ted” Codd) ( http://goo.gl/l2EqFp ) решења је засновао на математичким темељима, теоријом скупова и предикатском логиком.

Као основна идеја и замисао научног рада Е. Ф. Кода је омогућавање техничко необразованим корисницима смештање, претраживање и манипулацију великим количинама података. Наиме, Код је замислио систем у коме корисници приступају подацима у базама података коришћењем команди сличним речима енглеског језика, док су сами подаци смештени у табелама.

Наравно да горе споменуте „команде” нису дошле саме по себи, већ је компанија IBM почела да развија систем за управљање базама података, који су назвали „System R”. Истраживачка група која је радила на овом пројекту је осмислила SQUEL (енг. Structured Query English Language) који је касније скраћен у SQL (енг. Structured Query Language). Овај језик се показао довољно моћним и практичним, тако да је 1978/1979. године почела и његова прва комерцијална примена како у књиговодственим организацијама, тако и у аеронаутичким компанијама.

Након ових примена језик из IBM-а прелази у ANSI (енг. American National Standards Institution) 1986. године, која га прихвата као језик за рад са релационим базама података. Полазећи од постојећих имплементација дефинисан је IBM стандардом (X3.135, http://goo.gl/J3S6qQ ) којим се и одређује какав би SQL требало да буде. Године 1987. га такође прихвата и Међунардна организација за стандарде – ISO (енг. International Standards Organization).

Експанзија развоја апликативног софтвера деведесетих година 20. века указала је потребу за једноставним начином повезивања и комуницирања са базама података. Некомпатибилност, нескалабилност и неинтероперабилност су довеле до тога да су ту привилегију комуницирања са базама података имали до тада само најискуснији програмери, и то уз огроман уложен труд и време. Како стандардизација на свим пољима доприноси продуктивности, тако је и у информационим технологијама стандардизација SQL језика довела до појаве једног од првих API-ја (енг. Aplication Programming Interface), под називом ODBC (енг. Open DataBase Connectivity), који је развио Мајкрософт у сарадњи са „Симба технологијом” (енг. Simba Technologies) 1992. године.

Овај програмерски интерфејс је први пут омогућио да програмери-клијенти имају могућност употребе основних операција над подацима унутар база података из самих апликација тако што се постављају упити над базама података користећи се сада већ стандардизованим SQL језиком. Мада је ово омогућило лакши, бржи, поузданији приступ подацима у базама података – остали су неки од проблема који су се појављивали и пре увођења ODBC-а, а то су компатибилност између различитих система, трајност података, неподударност парадигми итд.

Тежећи ка бољем објашњењу проблема неподударности парадигми, најбоље је да прво укратко објаснимо основне разлике објектне и релационе парадигме, и на који начин свака од њих руководи и управља подацима.

Једна од основних идеја увођења и коришћења база података је управо у трајности података (енг. persistence), и ефикасном приступу истим. Другим речима, подаци једноставно морају да надживе било коју апликацију која их је створила. Многе сложене апликације, као што су информациони системи, били би потпуно бескорисни уколико подаци не би остали трајни након „истека рока трајања апликације”, или уколико се апликација замени новом верзијом. Сами подаци у апликацијама нису трајни, већ привремени (енг. transient). Потреба за очувањем података на основу којих свака апликација функционише, захтева и одређен систем који управља истим – и то су, у највећем броју случајева данашњих решења, релациони модели, тј. релационе базе података.

Друга страна „медаље”, која је засјала, је увођење OOP (енг. Object Oriented Programming) модела програмирања, који је скоро заменио структурне језике, али је исто тако довела програмере-клијенте у положај да скоро трећина написаног кода се управо односи на приступ, управљање и ажурирања података у базама преко SQL-а и DBC-а. Ови проблеми су постали у толикој мери изражени да би се могло рећи да, ако се сагледају ови статистички подаци продуктивности, OOP парадигма губи сваки смисао.

Смисао је, такође, изгубљен и у самој идеји OOP програмирања, тј. да се сви подаци којима се манипулише у апликацијама представљају преко објеката. Пошто се као систем за управљање подацима користи релациони модел, који само прима примитивне типове података, управо то представља највећу неподударност парадигми.

Релациона парадигма је заснована на математичким принципима, теорији скупова и предикатној логици. Релације имају моћне операторе сродне природном језику, док се манипулација подацима заснива на релационој алгебри. Тежњом ка што бољим перформансама и правилнијем уписом података, табеле се обично нормализују; програмерским жаргоном речено – врши се декомпозиција. Укратко, ако је нешто засновано на математичкој основи, готово са сигурношћу можемо тврдити да ће он као такав остати исти, у било ком „временском оквиру”, и то је један од разлога зашто су се релациони модели одржали у овом експоненцијалном развитку информационих технологија. Такође, можемо из овог закључити да је ово једна од парадигми која, барем за сада остаје, и доказано одлично обавља посао који јој је намењен.

У OOP програмирању све своди на објекте. Објекти имају своје стање, понашање и својства. То је идеја која се искристалисала и дефинисала пут којим се одвија планирање, имплементација и израда једне апликације. Према објектној парадигми, два објекта су иста ако и само ако су им референце на објекат исте, тј. два објекта су једнака ако имају иста стања поља којима су описани. Пример из стварног света би отприлике био да, рецимо, имамо овцу и њеног клона. Са становишта ДНК анализе, то су идентични објекти, међутим то су две различите инстанце једног објекта (нпр. немају исто понашање). OOP као за свој главни циљ дефинише једноставност руковања подацима у самој апликацији.

Релациони модели су засновани на математичким односима и широко су прихваћени. Уз сав могућ напредак информационих технологија, оне ће суштински радити исто. Упоређивањем ових парадигми лако се може увидети да су разлике огромне и да се разилазе по самим основама, али то је тренутно најбољи модел који имамо, и треба да коегзистира са осталим моделима, па тако и са OOP парадигмом.

Како се проблем продубљује, релациони модел је добар у апликацијама које нису превелике ни сувише компликоване. Ако се ово узме у обзир, то доводи до проблема непродуктивности, трошења времена и комерцијалне неисплативости развијања апликација програмера-клијената у већим пројектним захтевима. Осим тога, одбојност ка новим техологијама још је више изражена ако се односе на већ устаљена и добро имплементирана решења, која за собом носе и стручњаке које су их савладали (овде се мисли на релациони модел, који се толико „одомаћио” да је постао „слепа” водиља које се држе постојећи администратори база података и „оштро” одбијају да се суоче са неким, можда „супериорнијим”, моделима и решењима, која се по самој својој природи намећу).

Тренутно, решење које се нуди је ОРМ (енг. Object Relation Mapping), који OOP програмере и администраторе база података с једне, и OOP парадигму и релациону парадигму с друге стране, спаја у својству међуслоја, те задовољава и „ублажава јаз” неподударајућих парадигми.

Наставиће се.