Кіріспе
Концептуалдық және техникалық қиындықтар жиынтығы
Объекті-реляциялық үйлесімсіздік – реляциялық деректер сақтағыштарындағы деректер мен доменге бағытталған объект модельдері арасында туындайтын қиындықтар жиынтығы. Реляциялық деректерді басқару жүйелері (RDBMS) – арнайы деректер базасында деректерді сақтаудың стандартты әдісі, ал объектіге бағытталған (ОО) бағдарламалау – бағдарламалау тілдерінде бизнесге бағытталған жобалаудың әдепкі әдісі. Мәселе реляциялық деректер базаларында немесе ОО бағдарламалауда емес, екі логикалық модельдің арасындағы тұжырымдамалық сәйкестікті орнатуда жатыр. Екі логикалық модель де деректер базасы серверлерін, бағдарламалау тілдерін, жобалау үлгілерін немесе басқа технологияларды пайдалану арқылы әртүрлі жолдармен іске асырылуы мүмкін. Қиындықтар қолданба деңгейінен кәсіпорын деңгейіне дейін, сақталған реляциялық деректер доменге бағытталған объект модельдерінде қолданылғанда және керісінше туындайды. Объектіге бағытталған деректер сақтағыштары бұл мәселені басқа іске асыру қиындықтарымен алмастыра алады. Импеданс үйлесімсіздігі термині электр техникасындағы импеданс сәйкестігінен алынған.
Сәйкессіздіктер
ОО математикалық тұрғыдан – бір-біріне сілтеме жасайтын бағытталған графтар. Реляциялық – реляциялық алгебрамен кестелердегі түплдер. Түплдер – типтелген өрістері бар "қатарға" топтастырылған деректер өрістері. Сілтемелер өзара қайтымды (INNER JOIN шетелдік кілттерді кері бағытта жалғау үшін симметриялы), бағытталмаған графтарды құрайды.
Капсулалау
Нысанды капсулалау ішкі құрылымды жасырады. Нысан қасиеттеріне тек жүзеге асырылған интерфейстер арқылы ғана қол жеткізуге болады. Дегенмен, көптеген ORM дерекқоры бағандарымен жұмыс істеу үшін қасиеттерді тікелей ашыққа шығарады. Метапрограммалауды қолданатын ORM-дар капсулалау принципін бұзудың алдын алады.
Қолжетімділік
"Жеке" мен "жария" ұғымдары қарым-қатынаста қажеттілікке байланысты. Объектілі-бағдарламалауда (ОО) бұл толығымен класс негізінде анықталады. Мұндай салыстырмалылық пен классификациялар мен қасиеттердің абсолюттігінің арасындағы қайшылық туындайды.
Интерфейс, класс, мұралау және полиморфизм
Объектілер ішкі құрылымын ашу үшін интерфейстерді жүзеге асыруы керек. Реляциялық деректер базалары түрлі көзқарастар мен шектеулерді көрсету үшін көріністерді пайдаланады. Оларда кластар, мұрагерлік және полиморфизм сияқты объектіге бағытталған ұғымдар жоқ.
Қатынастық ұғымдарға сәйкестендіру
ORM дұрыс жұмыс істеуі үшін, сыртқы кілт/негізгі кілт қатынастары арқылы байланысқан кестелер объектіге бағытталған талдаудағы байланыстарға бейімделуі керек.
Деректер түрінің айырмашылығы
Қатынастық модельде сілтемелер арқылы (мысалы, көрсеткіштер) тыйым салынса, объектіге бағытталған модельде сілтемелер қабылданады. Скалярлық типтер екеуінде де өзгеше, бұл оларды шамалап бейнелеуге кедергі келтіреді. SQL максималды ұзындығы бар жолдарды (ұзындығы болмаған жағдайда жылдамырақ) және әр түрлі тілдерге бейімделуді (collation) қолдайды. Объектіге бағытталған модельде тілдерге бейімделу тек сұрыптау алгоритмдерімен және жад көлемімен ғана шектеледі. SQL әдетте салыстыру кезінде соңғы бос орындарды назарға алмайды, бірақ объектіге бағытталған кітапханалар оларды ескереді. Объектіге бағытталған модельде қарапайым типтерге шектеулер қою арқылы жаңа типтер жасалмайды.
Құрылымдық және тұтастығы бойынша айырмашылықтар
Объектілер басқа объектілерден тұруы немесе мамандануы мүмкін. Реляциялық модельдегі деректер ішкі жиын түрінде ұйымдастырылмайды, ал қатынастар (бірдей атаулары бар жазбалар жиыны) объектіге бағытталған бағдарламалауға (ОО) үйлеспейді. Реляциялық модель скалярлық типтерге, атрибуттарға, қатынас айнымалыларына және/немесе жалпыға ортақ түрде декларативтік шектеулер қолданады. Объектіге бағытталған бағдарламалау объектінің ішкі құрылымын қорғау үшін өтекіл жағдайларды (exceptions) пайдаланады.
Манипуляциялық айырмашылықтар
Реляциялық деректерді өңдеу үшін стандартталған операторларды пайдаланады, ал Объекті-бағытталған бағдарламалау әр сынып үшін, әр жағдайға қатысты императивті қолданады. Объекті-бағытталған бағдарламалаудың декларативтік қолдауы тізімдер мен хэш-кестелер үшін ғана, реляциялық деректердегі жиынтықтардан өзгеше.
Транзакциялық айырмашылықтар
Реляциялық бірлік – кез келген объектіге бағытталған кластың әдістерінен асып түсетін транзакция. Транзакциялар кез келген деректерді өңдеудің комбинацияларын қамтиды, ал объектіге бағытталған бағдарламалауда тек қарапайым өрістерге жеке тағайындамалар бар. Объектіге бағытталған бағдарламалауда оқшаулану және тұрақтылық жоқ, сондықтан атомарлық және дәйектілік тек қарапайым деректермен ғана қамтамасыз етіледі.
Импеданс сәйкессіздіктерін шешу
Шешімдер логикалық жүйелердің өзгешеліктерін қабылдаудан басталады. Бұл қарама-қайшылықты азайтуға немесе толықтыруға мүмкіндік береді.
Баламалы архитектуралар
NoSQL. Нұқсан объектілі-бағдарланған және ДБЖ арасында емес. Объектілік-реляциялық келеспессіздік тек ОО және RDBMS арасында ғана кездеседі. NoSQL немесе XML дерекқоры сияқты баламалар осы мәселенің алдын алады. Функционалдық реляциялық бейнелеу. Функционалдық бағдарламалау – объектілі-бағдарланған бағдарламалауға танымал балама. Функционалдық бағдарламалау тілдеріндегі түсініктер реляциялық сұраныстармен изоморфты болып келеді. Кейбір функционалдық бағдарламалау тілдері функционалдық реляциялық бейнелеуді жүзеге асырады. Түсініктер мен сұраныстардың тікелей сәйкес келуі объектілік-реляциялық бейнелеудің көптеген проблемаларын болдырмайды.
ОО-да барынша азайту
Орынсыздықты болдырмау үшін объектілік деректер базалары (OODBMS) бар, бірақ олар реляциялық деректер базаларына қарағанда аз сәттілікке жетеді. Объектілі-бағытталған әдіс схемалар үшін нашар негіз болып табылады. Болашақтағы объектілі-бағытталған деректер базасын зерттеулер транзакциялық жадқа қатысты. Тағы бір шешім домендік және фреймворк логикасын біріктіреді. Бұл жағдайда, объектілі-бағытталған әдіс реляциялық аспектілерді статикалық емес, орындалу барысында картаға түсіреді. Фреймворктерде tuple класы (қатар немесе нысан деп те аталады) және қатынас класы (ә.і. деректер жиынтығы) болады.
Өтемақы
ОО деңгейлерін араластыру қиындық тудырады. Көбінесе, негіздемелік қолдау модельдеу деңгейінде деректерді өңдеу және көрсету үлгілерін автоматтандыру арқылы бұл мәселені шешеді. Көшіру (рефлексия) және кодты генерациялау қолданылады. Көшіру кодты дерек ретінде қарастырады, автоматты дерек тасымалдау, көрсету және тұтастығын қамтамасыз етуге мүмкіндік береді. Генерациялау схемаларды сыныптарға және қосымша құралдарға айналдырады. Екеуінде де деңгейлер арасында аномалиялар кездеседі, мысалы, генерацияланған сыныптар домендік қасиеттерге (мысалы, Атау, Мекенжай, Телефон) және негіздемелік қасиеттерге (мысалы, IsModified) ие болады.
Пайда болуы
Объектілік реляциялық келеспессіздіктер жалпы нысанға бағытталған бағдарламалауда кездесуі мүмкін, бірақ қиындық тудыратын ерекше сала – объектілік-реляциялық карталаушылар (ОРМ). ОРМ көбінесе конфигурация, түсіндірмелер және шектеулі доменге арналған тілдер арқылы сипатталғандықтан, келеспессіздікті шешу үшін толыққанды бағдарламалау тілінің мүмкіндіктеріне ие болмайды.
Нағыз RDBMS моделі
Кристофер Дж. Дэйт нағыз реляциялық СҚДБ мәселені шешеді, себебі домендер мен кластар бірдей. Реляциялық және Объектіге бағытталған арасында сәйкестік жасау – қате. Реляциялық түйіндер объектілерді бейнелемейді, олар объектілермен байланысты. Объектіге бағытталғанның рөлі тек қана өрістерді басқарумен шектеледі.
Шектеулер мен заңсыз операциялар
Домендік объектілер мен пайдаланушы интерфейстерінің кедергілері үйлеспейді. Тиімді UI-лар заңсыз транзакцияларды (дерекқор шектеулерін бұзу) болдырмауға тиіс, бұл операторларға және бағдарламашы емес мамандарға деректерді басқаруға көмектеседі. Бұл үшін дерекқор атрибуттары туралы атау мен түрден артық білім қажет, ол реляциялық схемалардағы логиканы дубликациялайды. Фреймворктар реферанциялық тұтастық шектеулері мен басқа схема ақпаратын қолданып, жағдай бойынша код жазудан аулақ болып, стандартталған тәсілді қамтамасыз етеді.
SQL-ке тән кедергілер мен оларды шешу жолдары
SQL-де домендік типтердің болмауы OO модельдеуге кедергі келтіреді. Ол, DBMS мен қосымша арасында (OO болсын, болмасын) мәліметтердің жоғалуына себеп болады. Дегенмен, көптеген адамдар NoSQL және басқа да өндірушіге тән сұраныс тілдерін пайдаланудан қашады. DBMS-тер сондай-ақ Бизнес-жүйе 12 және Оқулық D-ні де назарға алмайды. Oracle және Microsoft SQL Server сияқты кең таралған DBMS-тер бұл мәселені шешеді. OO коды (Java және .NET тілдерінде) оларды кеңейтеді және SQL-де, DBMS-ге енгізілгендей оңай шақырылуы мүмкін. Бірнеше схемада кітапханалық процедураларды қайта пайдалану – қолдау көрсетілетін қазіргі заманғы тәсіл. OO артқы жағында (backend) орналасқан, себебі SQL-де бүгінгі бағдарламашыларға қажетті заманауи кітапханалар мен құрылымдар болмайды, ISO SQL 99 комитеті процедуралық мүмкіндіктерді қосуға ниеттенсе де. SQL-ді өзгертудің орнына оларды тікелей пайдалану орынды. Бұл "қосымша бағдарламалау" мен "деректер қорын басқару" арасындағы жауапкершілік шекарасын бұрмалайды, өйткені шектеулер мен триггерлерді іске асыру үшін енді DBA және OO дағдылары қажет. Бұл пікірге қарсылық тудыруы мүмкін. RDBMS-тер модельдеу үшін арналмаған. SQL мәліметтерді модельдеу үшін қолданылғанда ғана мәліметтердің жоғалуына себеп болады. SQL сұрау салуға, сұрыптауға, сүзгілеуге және үлкен деректерді сақтауға арналған. Артқы жақтағы (backend) OO нашар архитектураны ынталандырады, себебі бизнес логика деректер деңгейінде орналасуы тиіс емес.
Mainstream DBMSes like Oracle and Microsoft SQL Server solve this. OO code (Java and NET respectively) extend them and are invokeable in SQL as fluently as if built into the DBMS. Reusing library routines across multiple schemas is a supported modern paradigm. OO is in the backend because SQL will never get modern libraries and structures for today's programmers, despite the ISO SQL 99 committee wanting to add procedural. It is reasonable to use them directly rather than changing SQL. This blurs the division of responsibility between "application programming" and "database administration" because implementing constraints and triggers now requires both DBA and OO skills. This contention may be moot. RDBMSes are not for modelling. SQL is only lossy when abused for modelling. SQL is for querying, sorting, filtering, and storing big data. OO in the backend encourages bad architecture as business logic should not be in the data tier.
Деректердің заңды көшірмесінің орналасуы
Реляциялық жүйе деректер базасының сенімді екенін, ал объектілі бағдарламаның объектілері уақытша көшірмелер (деректер базасы бір уақытта өзгертілсе, толық емес болуы мүмкін) дейді. Объектілі бағдарлама объектілердің сенімді екенін, ал деректер базасының жүйесі тек сақтау үшін қолданылады дейді.
Жауапкершілікті бөлу
Жаңа мүмкіндіктер кодты да, схеманы да өзгертеді. Схема ДБА-ның жауапкершілігінде. ДБА-лар сенімділіктен жауапты, сондықтан бағдарламашылардың қажетсіз өзгерістерін қабылдамайды. Кезеңдік дерекқорлар көмектеседі, бірақ рұқсат беруді ғана шығару уақытына ықпалдастырады. ДБА-лар өзгерістерді кодта, ақаулардың салдары азырақ болатын жерде сақтауды қалайды. Көбірек ынтымақтастық осы мәселені шешеді. Схеманы өзгерту туралы шешімдер бизнес-мұқтаждықтарға негізделуі керек. Жаңа деректер немесе өнімділіктің артуы екеуі де схеманы өзгертеді.