Еди­ная точ­ка до­сту­па к дан­ным пред­при­я­тия

Лю­бая кор­по­ра­ция вла­де­ет се­год­ня огром­ны­ми мас­си­ва­ми раз­но­об­раз­ных дан­ных раз­лич­ной струк­ту­ры, ра­бо­та с которыми неэф­фек­тив­на при от­сут­ствии еди­ной точ­ки до­сту­па. Ре­шить эту за­да­чу мож­но при по­мо­щи ло­ги­че­ской вит­ри­ны.

Otkrytye sistemy. SUBD. - - СОДЕРЖАНИЕ - Сер­гей Горш­ков

Лю­бая кор­по­ра­ция вла­де­ет се­год­ня огром­ны­ми мас­си­ва­ми раз­но­об­раз­ных дан­ных раз­лич­ной струк­ту­ры, ра­бо­та с которыми неэф­фек­тив­на при от­сут­ствии еди­ной точ­ки до­сту­па. Ре­шить эту за­да­чу мож­но при по­мо­щи ло­ги­че­ской вит­ри­ны.

Клю­че­вые сло­ва: он­то­ло­гии, се­ман­ти­че­ские тех­но­ло­гии, вит­ри­на дан­ных Keywords: Ontologies, semantic technologies, Data Mart

Круп­ные ор­га­ни­за­ции неиз­беж­но стал­ки­ва­ют­ся с про­бле­мой раз­роз­нен­но­сти на­коп­лен­ных дан­ных, что осо­бен­но актуально для ар­хи­вов до­ку­мен­тов, чер­те­жей, элек­трон­ных таб­лиц, из­ме­ре­ний и дру­гих све­де­ний, пред­став­лен­ных в ви­де фай­лов, а не эле­мен­тов дан­ных внут­ри ка­кой-ли­бо ав­то­ма­ти­зи­ро­ван­ной си­сте­мы. Меж­ду тем имен­но в этих хра­ни­ли­щах ча­сто со­сре­до­то­че­ны дан­ные, по­тен­ци­аль­но спо­соб­ные при­не­сти эко­но­ми­че­ский эф­фект: ис­поль­зо­ва­ние луч­ших прак­тик, ис­клю­че­ние ошибок, вы­бор мак­си­маль­но обос­но­ван­ных ре­ше­ний с уче­том всех су­ще­ствен­ных фак­то­ров и пр. Од­на­ко для это­го со­труд­ни­ки ком­па­нии, во-пер­вых, долж­ны знать, что в ком­па­нии име­ет­ся та­кая ин­фор­ма­ция, а во-вто­рых — вла­деть ин­стру­мен­том для ее быст­ро­го и точ­но­го по­ис­ка.

Кри­те­рии по­ис­ка в мас­си­вах раз­роз­нен­ных дан­ных опре­де­ля­ют­ся смыс­лом ис­ко­мых эле­мен­тов — со­дер­жи­мое каж­до­го фай­ла в лю­бом хра­ни­ли­ще ло­ги­че­ски свя­за­но с те­ми или ины­ми ак­ти­ва­ми, контр­аген­та­ми, ра­бот­ни­ка­ми и про­цес­са­ми. Все эти ме­та­дан­ные — све­де­ния о со­дер­жи­мом фай­ла — обыч­но пред­став­ле­ны в скры­той фор­ме: че­ло­век мо­жет по­лу­чить их из со­дер­жи­мо­го фай­ла, его на­зва­ния или по­ло­же­ния в струк­ту­ре па­пок. По­нят­но, что по­иск до­ку­мен­та по ха­рак­те­ри­сти­кам, пред­став­лен­ным в про­из­воль­ной фор­ме или во­об­ще не фор­ма­ли­зо­ван­ным, мо­жет за­нять неогра­ни­чен­ное вре­мя и не при­ве­сти к успе­ху. Не все­гда по­мо­жет и при­выч­ный пол­но­тек­сто­вый по­иск по со­дер­жи­мо­му до­ку­мен­тов — он при­ме­ним толь­ко к тек­сто­вым до­ку­мен­там, а его ре­зуль­та­ты мо­гут быть слиш­ком об­шир­ны и неточ­ны. На­при­мер, по­иск до­го­во­ров с опре­де­лен­ным контр­аген­том по сло­ву «до­го­вор» и на­зва­нию контр­аген­та вы­даст мно­же­ство ре­зуль­та­тов без га­ран­тии то­го, что на пер­вых по­зи­ци­ях ока­жут­ся имен­но те до­ку­мен­ты, ко­то­рые имел в виду ав­тор за­про­са. А ес­ли рас­ши­рить за­да­чу и рас­смот­реть по­иск в ба­зах дан­ных, внут­ри ав­то­ма­ти­зи­ро­ван­ных си­стем на плат­фор­мах, не до­пус­ка­ю­щих пря­мой ра­бо­ты сто­рон­них ком­по­нен­тов, в уда­лен­ных сер­ви­сах? Та­кой спо­соб по­ис­ка мо­жет быть ак­ту­аль­ным для каж­дой ком­па­нии, рас­по­ла­га­ю­щей боль­шим чис­лом си­стем.

Пре­об­ра­зо­ва­ние на­бо­ра раз­роз­нен­ных дан­ных в еди­ный мас­сив воз­мож­но пу­тем ор­га­ни­за­ции до­сту­па к ним че­рез фи­зи­че­ские или ло­ги­че­ские вит­ри­ны дан­ных. Пер­вые, учи­ты­вая огром­ные по­то­ки еже­днев­но ге­не­ри­ру­е­мой ин­фор­ма­ции, мож­но ре­а­ли­зо­вать толь­ко для кон­крет­ных за­дач [1]. Зна­чит, объ­еди­нить всю до­ступ­ную ин­фор­ма­цию в еди­ный связ­ный мас­сив мож­но толь­ко ло­ги­че­ски. Идея та­ко­го объ­еди­не­ния бы­ла вы­ска­за­на дав­но [2] и по­лу­чи­ла не очень удач­ное на­зва­ние «вир­ту­а­ли­за­ция дан­ных».

Ло­ги­че­ская вит­ри­на дан­ных (logical data warehouse, data mart или dashboard) — ар­хи­тек­ту­ра ин­те­гри­ру­ю­щей си­сте­мы, при ко­то­рой все дан­ные не ме­ня­ют сво­е­го фи­зи­че­ско­го ме­сто­по­ло­же­ния в ис­ход­ных си­сте­мах и хра­ни­ли­щах. Вит­ри­на имеет до­ступ к каж­до­му ис­точ­ни­ку, «осве­дом­ле­на» о его струк­ту­ре, спо­соб­на за­пра­ши­вать све­де­ния из си­стем-ис­точ­ни­ков и пре­об­ра­зо­вы­вать их в со­от­вет­ствии с еди­ной струк­ту­рой, ав­то­ма­ти­че­ски объ­еди­нять дан­ные, по­сту­пив­шие из разных ис­точ­ни­ков, и предо­став­лять их поль­зо­ва­те­лю. Поль­зо­ва­тель, в свою оче­редь, мо­жет об­ра­щать­ся к вит­рине с за­про­са­ми, ко­то­рые она ин­тер­пре­ти­ру­ет не как на­бор ис­ко­мых слов, а как ло­ги­че­ское вы­ра­же­ние, как во­прос, на ко­то­рый дол­жен быть дан точ­ный от­вет. Итак:

• вит­ри­на долж­на уметь по за­про­су из­вле

кать лю­бые дан­ные из лю­бых ис­точ­ни­ков; • долж­на уметь ин­дек­си­ро­вать сла­бо струк­ту­ри­ро­ван­ные ис­точ­ни­ки, та­кие как фай­ло­вые хра­ни­ли­ща, со­зда­вая для каж­до­го об­на­ру­жен­но­го в них до­ку­мен­та струк­ту­ри­ро­ван­ное смыс­ло­вое опи­са­ние;

• поль­зо­ва­тель имеет воз­мож­ность «за­да­вать во­про­сы» вит­рине, на ко­то­рые она долж­на да­вать мак­си­маль­но точ­ные, а не при­бли­зи­тель­ные ответы; • поль­зо­ва­тель не дол­жен бес­по­ко­ить­ся о фак­ти­че­ском раз­ме­ще­нии дан­ных и их струк­ту­ре;

• вит­ри­на не обя­за­на хра­нить все дан­ные в од­ном хра­ни­ли­ще.

Фак­ти­че­ски, вит­ри­на для поль­зо­ва­те­ля — это уни­вер­саль­ная точ­ка до­сту­па ко всей кор­по­ра­тив­ной ин­фор­ма­ции, объ­еди­нен­ной в еди­ный вир­ту­аль­ный мас­сив.

Что­бы «по­ни­мать» смысл во­про­сов, вит­ри­на долж­на «го­во­рить» с поль­зо­ва­те­лем

на его язы­ке, сле­до­ва­тель­но, тре­бу­ет­ся фор­ма­ли­зо­ван­ное опи­са­ние пред­мет­ной об­ла­сти. На­при­мер, ес­ли ор­га­ни­за­ция имеет де­ло с тру­бо­про­во­да­ми, при­бо­ра­ми уче­та и их по­ка­за­ни­я­ми, то эти тер­ми­ны долж­ны быть включены в кон­цеп­ту­аль­ную мо­дель, с ко­то­рой ра­бо­та­ет си­сте­ма. Для со­зда­ния и пред­став­ле­ния кон­цеп­ту­аль­ных мо­де­лей при­ме­ня­ют­ся тех­но­ло­гии он­то­ло­ги­че­ско­го мо­де­ли­ро­ва­ния (стан­дарт OWL и др. [3]).

По­сле то­го как мо­дель по­стро­е­на, необ­хо­ди­мо опи­сать пра­ви­ла из­вле­че­ния дан­ных из ис­точ­ни­ков и их пре­об­ра­зо­ва­ния в со­от­вет­ствии с эле­мен­та­ми мо­де­ли. На­при­мер, ес­ли в таб­ли­це од­ной из баз хра­нит­ся пе­ре­чень при­бо­ров уче­та, то в на­строй­ках вит­ри­ны долж­но быть за­да­но пра­ви­ло, ука­зы­ва­ю­щее на то, что каж­дая за­пись этой таб­ли­цы пред­став­ля­ет объ­ект ти­па «При­бор уче­та», об­ла­да­ю­щий опре­де­лен­ны­ми ха­рак­те­ри­сти­ка­ми. Ин­фор­ма­ция об од­них и тех же объ­ек­тах обыч­но рас­се­я­на меж­ду раз­ны­ми ис­точ­ни­ка­ми: в од­ном ме­сте мо­жет хра­нить­ся пе­ре­чень при­бо­ров с точ­ки зре­ния уче­та ма­те­ри­аль­ных цен­но­стей, в дру­гом — в ка­че­стве ис­точ­ни­ков по­ка­за­ний рас­хо­да ре­сур­сов, а в тре­тьем — в ви­де про­ект­ной и экс­плу­а­та­ци­он­ной до­ку­мен­та­ции на тех­но­ло­ги­че­скую ин­фра­струк­ту­ру, ча­стя­ми ко­то­рой они яв­ля­ют­ся. При на­ли­чии пра­вил со­по­став­ле­ния струк­тур вит­ри­на спо­соб­на объ­еди­нить все све­де­ния. На­при­мер, для сущ­но­сти «При­бор уче­та» мо­гут быть опре­де­ле­ны сле­ду­ю­щие пра­ви­ла: пе­ре­чень при­бо­ров тех­ни­че­ско­го уче­та рас­хо­да жид­ко­сти в тру­бо­про­во­дах хра­нит- ся в таб­ли­це control_devices ба­зы дан­ных «Си­сте­мы управ­ле­ния про­из­вод­ствен­ны­ми ак­ти­ва­ми», при­чем ко­лон­ка id со­дер­жит иден­ти­фи­ка­то­ры устройств, number — их се­рий­ные но­ме­ра, а last_check — да­ту по­след­ней по­вер­ки; пе­ре­чень при­бо­ров ком­мер­че­ско­го уче­та но­си­те­ля, от­пус­ка­е­мо­го по­тре­би­те­лям, хра­нит­ся в од­ной из баз на плат­фор­ме «1С» в спра­воч­ни­ке «Спра­воч­ник.при­бо­ру­че­та» с рек­ви­зи­та­ми «Иден­ти­фи­ка­тор», «Се­рий­ный­но­мер» и «Да­та­по­вер­ки». Ко­гда вит­ри­на по­стро­е­на, поль­зо­ва­тель сможет за­да­вать свои во­про­сы (см. ри­су­нок).

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

К по­стро­ен­ной вит­рине под­клю­ча­ют­ся но­вые ис­точ­ни­ки дан­ных, что об­лег­ча­ет ин­те­гра­цию вновь со­зда­ва­е­мых си­стем в об­щее кор­по­ра­тив­ное ин­фор­ма­ци­он­ное про­стран­ство, сни­жа­ет из­держ­ки при пе­ре­хо­де с од­них про­дук­тов на дру­гие — бла­го­да­ря вит­рине вся ин­фор­ма­ция, со­дер­жа­ща­я­ся в вы­во­ди­мых из экс­плу­а­та­ции си­сте­мах, мо­жет по-преж­не­му оста­вать­ся до­ступ­ной поль­зо­ва­те­лям. Вит­ри­на, на­ря­ду с Mdm-ре­ше­ни­ем (ко­то­рое бла­го­да­ря вит­рине мо­жет эво­лю­ци­о­ни­ро­вать из хра­ни­ли­ща эта­лон­ных спра­воч­ни­ков в хра­ни­ли­ще об­щей ин­фор­ма­ци­он­ной мо­де­ли) и кор­по­ра­тив­ной сер­вис­ной ши­ной, об­ра­зу­ет ло­ги­че­ское яд­ро кор­по­ра­тив­ной ин­фра­струк­ту­ры.

Ло­ги­че­ская вит­ри­на дан­ных — слож­ная ав­то­ма­ти­зи­ро­ван­ная си­сте­ма, тре­бу­ю­щая со­зда­ния адап­те­ров для ра­бо­ты с дан­ны­ми из раз­лич­ных си­стем, со­по­став­ле­ния спра­воч­ни­ков (ес­ли в ор­га­ни­за­ции нет MDM), со­зда­ния он­то­ло­ги­че­ской мо­де­ли и опи­са­ния пра­вил пре­об­ра­зо­ва­ния дан­ных и пр. Од­на­ко вит­ри­на поз­во­ля­ет пред­при­я­тию стать хо­зя­и­ном соб­ствен­ных дан­ных, из­влечь поль­зу из огром­ных мас­си­вов на­коп­лен­ных све­де­ний, пре­об­ра­зо­вать их в зна­ния, ис­поль­зу­е­мые для ре­ше­ния ак­ту­аль­ных во­про­сов те­ку­щей де­я­тель­но­сти и стра­те­ги­че­ско­го пла­ни­ро­ва­ния.

По­че­му же прак­ти­че­ское со­зда­ние вит­рин ста­ло ре­аль­ным толь­ко сей­час? Преж­де все­го до­стиг­нут опре­де­лен­ный уро­вень зре­ло­сти тех­но­ло­гий по­стро­е­ния и об­ра­бот­ки он­то­ло­ги­че­ских мо­де­лей, ин­стру­мен­тов хра­не­ния и пре­об­ра­зо­ва­ния дан­ных, об­ла­да­ю­щих боль­шей гиб­ко­стью, чем ре­ля­ци­он­ные СУБД. По­яви­лась па­ра­диг­ма OBDA (ontology based data access): поль­зо­ва­тель фор­му­ли­ру­ет за­про­сы к дан­ным в тер­ми­нах он­то­ло­ги­че­ской мо­де­ли, а спе­ци­аль­ный слой свя­зу­ю­ще­го ПО транс­фор­ми­ру­ет их в за­про­сы к ис­точ­ни­кам дан­ных. В ка­че­стве при­ме­ра мож­но при­ве­сти про­ект ком­па­нии Statoil [4]. Ес­ли ра­нее по­доб­ные тех­но­ло­гии при­ме­ня­лись толь­ко для об­ра­бот­ки ме­та­дан­ных — со­став­ле­ния си­сте­ма­ти­зи­ро­ван­но­го опи­са­ния дан­ных, раз­ме­щен­ных в разных хра­ни­ли­щах с це­лью упро­ще­ния их по­ис­ка, то се­год­ня мож­но го­во­рить и об ор­га­ни­за­ции до­сту­па не­по­сред­ствен­но к са­мим дан­ным.

Тех­но­ло­гии он­то­ло­ги­че­ско­го мо­де­ли­ро­ва­ния и на­бор свя­зан­ных с ни­ми тех­но­ло­ги­че­ских стан­дар­тов, та­ких как язык за­про­сов к гра­фо­вым ба­зам дан­ных SPARQL, ста­ли клю­чом к ре­а­ли­за­ции ло­ги­че­ских вит­рин дан­ных не толь­ко по­то­му, что пред­став­ля­ют в фор­ма­ли­зо­ван­ном ви­де кон­цеп­ту­аль­ные мо­де­ли, но и по­то­му, что поз­во­ля­ют «го­во­рить с поль­зо­ва­те­лем на од­ном язы­ке» и опи­сы­вать разные точ­ки зре­ния на од­ни и те же объ­ек­ты и про­цес­сы. В он­то­ло­ги­че­ской мо­де­ли структура и со­дер­жа­ние дан­ных тех­но­ло­ги­че­ски од­но­род­ны, то есть ра­бо­та с ни­ми осу­ществ­ля­ет­ся при по­мо­щи од­них и тех же ин­стру­мен­тов. До­ба­вить но­вый тип сущ­но­стей, ат­ри­бут или связь — не слож­нее, чем со­здать но­вую за­пись о кон­крет­ном объ­ек­те. Это обес­пе­чи­ва­ет гиб­кость струк­ту­ры ин­фор­ма­ции, недо­сти­жи­мую для ре­ля­ци­он­ных СУБД, и поз­во­ля­ет де­лать за­про­сы к струк­ту­ре ин­фор­ма­ции, че­го не поз­во­ля­ют nosql-хра­ни­ли­ща. Он­то­ло­ги­че­ские мо­де­ли до­пус­ка-

ют от­не­се­ние каж­до­го объ­ек­та бо­лее чем к од­но­му ти­пу, за­да­ние несколь­ких зна­че­ний для ат­ри­бу­тов объ­ек­тов, обес­пе­чи­ва­ют кон­троль ло­ги­че­ской це­лост­но­сти дан­ных при по­мо­щи раз­ви­тых ме­ха­низ­мов ло­ги­че­ско­го вы­во­да (по­стро­е­ния фор­маль­ных до­ка­за­тельств ис­тин­но­сти или лож­но­сти утвер­жде­ний). На­ко­нец, ме­ха­низ­мы ло­ги­че­ских вы­чис­ле­ний поз­во­ля­ют ав­то­ма­ти­че­ски до­пол­нять со­дер­жа­ние ба­зы зна­ний но­вы­ми фак­та­ми на ос­но­ве из­вест­ных пред­по­сы­лок и за­дан­ных поль­зо­ва­те­лем пра­вил по­лу­че­ния вы­во­дов.

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

Рас­смот­рим пример за­да­чи, ко­то­рая ре­ша­ет­ся с ис­поль­зо­ва­ни­ем ло­ги­че­ских вит­рин. Необ­хо­ди­мо свя­зать дан­ные, опи­сы­ва­ю­щие сот­ни ты­сяч объ­ек­тов и про­ис­хо­дя­щие на них со­бы­тия (де­сят­ки ты­сяч еже­днев­но). Ин­фор­ма­ция об объ­ек­тах и о со­бы­ти­ях рас­пре­де­ле­на меж­ду де­сят­ка­ми неза­ви­си­мых или сла­бо­свя­зан­ных ис­точ­ни­ков. До­ступ к ин­фор­ма­ции из од­них ис­точ­ни­ков осу­ществ­ля­ет­ся пу­тем вы­гру­зок, из дру­гих — пу­тем непо­сред­ствен­но­го до­сту­па к их хра­ни­ли­щам, из тре­тьих — че­рез веб-сер­ви­сы. При этом не­ко­то­рые сер­ви­сы не поз­во­ля­ют из­влечь це­ли­ком все со­дер­жи­мое хра­ни­ли­ща, а обес­пе­чи­ва­ют толь­ко воз­мож­ность вы­пол­не­ния мед­лен­ных за­про­сов к кон­крет­ным объ­ек­там.

По­сле по­стро­е­ния об­щей мо­де­ли и опре­де­ле­ния пра­вил со­по­став­ле­ния ее эле­мен­тов со струк­ту­рой дан­ных ис­точ­ни­ков, со­зда­ния адап­те­ров для по­лу­че­ния и пре­об­ра­зо­ва­ния дан­ных стро­ят­ся про­ме­жу­точ­ные хра­ни­ли­ща для све­де­ний, ко­то­рые це­ле­со­об­раз­но из­влечь из ис­точ­ни­ков для по­сто­ян­но­го поль­зо­ва­ния. Для остав­ших­ся ис­точ­ни­ков со­зда­ют­ся мо­ду­ли, обес­пе­чи­ва­ю­щие по­лу­че­ние дан­ных по за­про­су. Са­мая важ­ная часть ре­ше­ния — сер­вис­ный слой, ко­то­рый по­лу­ча­ет за­про­сы в тер­ми­нах он­то­ло­ги­че­ской ин­фор­ма­ци­он­ной мо­де­ли, опре­де­ля­ет ме­ста хра­не­ния ин­фор­ма­ции, необ­хо­ди­мой для фор­ми­ро­ва­ния от­ве­та на за­про­сы, и аг­ре­ги­ру­ет ответы от разных ис­точ­ни­ков. Поль­зо­ва­тель или ком­по­нент

про­грам­мы, вы­пол­ня­ю­щий за­прос к сер­вис­но­му слою, пол­но­стью аб­стра­ги­ро­ван от де­та­лей функ­ци­о­ни­ро­ва­ния это­го слоя и ра­бо­та­ет с еди­ным мас­си­вом ин­фор­ма­ции, пред­став­лен­ным в со­от­вет­ствии с гра­фо­вой струк­ту­рой, то есть в ви­де на­бо­ра сущ­но­стей и из­вест­ных о них фак­тов. При этом для вы­пол­не­ния каж­до­го за­про­са си­сте­ма фак­ти­че­ски об­ра­ща­ет­ся как к соб­ствен­ным про­ме­жу­точ­ным хра­ни­ли­щам, так и к внеш­ним для нее ис­точ­ни­кам и сер­ви­сам. Та­кая ре­а­ли­за­ция рас­ши­ря­ет прин­цип OBDA, ис­ход­но рас­смат­ри­вав­ший в ка­че­стве ис­точ­ни­ков дан­ных толь­ко ре­ля­ци­он­ные СУБД.

В этом при­ме­ре вит­ри­на хра­нит толь­ко пра­ви­ла из­вле­че­ния объ­ек­тов из ис­точ­ни­ков, не хра­ня да­же ин­декс­ных за­пи­сей о са­мих объ­ек­тах, — все по­ис­ко­вые за­про­сы транс­ли­ру­ют­ся в за­про­сы к си­сте­ма­ми­сточ­ни­кам.

Воз­мо­жен и дру­гой ва­ри­ант ре­а­ли­за­ции: вит­ри­на мо­жет хра­нить ссыл­ки на ин­фор­ма­ци­он­ные объ­ек­ты, рас­по­ло­жен­ные в дру­гих ис­точ­ни­ках. При этом си­сте­ма со­дер­жит и се­ман­ти­че­ские опи­са­ния этих объ­ек­тов, что поз­во­ля­ет вы­пол­нять по­иск нуж­но­го объ­ек­та сред­ства­ми са­мой вит­ри­ны. Об­ра­ще­ние к ис­точ­ни­ку про­ис­хо­дит толь­ко для по­лу­че­ния пол­ной ин­фор­ма­ции об объ­ек­те. Та­кой ва­ри­ант имеет смысл в случае, ко­гда объ­ек­ты — это до­ку­мен­ты, чер­те­жи, на­бо­ры ре­зуль­та­тов из­ме­ре­ний и дру­гие сущ­но­сти боль­шо­го объ­е­ма, со­дер­жа­ние ко­то­рых мо­жет быть опи­са­но огра­ни­чен­ным ко­ли­че­ством ха­рак­те­ри­стик.

К функ­ци­о­наль­ным за­да­чам, при ре­ше­нии ко­то­рых наи­бо­лее эф­фек­тив­ны ло­ги­че­ские вит­ри­ны дан­ных, от­но­сят­ся: • до­ступ к ар­хи­вам до­ку­мен­та­ции (про­ект­ной, ра­бо­чей, экс­плу­а­та­ци­он­ной) для быст­ро­го из­вле­че­ния ин­фор­ма­ции по опре­де­лен­но­му объ­ек­ту или уз­лу; • до­ступ к гео­ло­го-гео­фи­зи­че­ским дан­ным: ре­зуль­та­там сей­сми­че­ской съем­ки, сква­жин­ным дан­ным, про­то­ко­лам бу­ре­ния и др.;

• до­ступ к дан­ным сер­ви­сов, воз­вра­ща­ю­щим боль­шой объ­ем ин­фор­ма­ции, ко­то­рую не имеет смыс­ла об­ра­ба­ты­вать це­ли­ком: ре­ест­ры юри­ди­че­ских лиц, ба­зы дан­ных пред­при­я­тий и др.;

• ре­а­ли­за­ция си­стем под­держ­ки при­ня­тия ре­ше­ний, где в каж­дой си­ту­а­ции, раз­во­ра­чи­ва­ю­щей­ся в ре­аль­ном вре­ме­ни, необ­хо­ди­мо по­лу­чать опе­ра­тив­ные дан­ные из ши­ро­ко­го кру­га ис­точ­ни­ков и ин­те­гри­ро­вать их в об­щую кар­ти­ну; • до­ступ к ча­сто об­нов­ля­ю­щей­ся ин­фор­ма­ции в тран­зак­ци­он­ных си­сте­мах, необ­хо­ди­мой для по­стро­е­ния ана­ли­ти­ки по за­про­сам, кон­стру­и­ру­е­мым поль­зо­ва­те­лем.

***

Со­вре­мен­ные он­то­ло­ги­че­ские тех­но­ло­гии, гра­фо­вые ба­зы дан­ных, ма­ши­ны ло­ги­че­ско­го вы­во­да и дру­гие ин­стру­мен­ты да­ют воз­мож­ность в рам­ках ра­зум­ных бюд­же­тов со­зда­вать ло­ги­че­ские вит­ри­ны дан­ных, поз­во­ля­ю­щие пред­при­я­ти­ям кон­со­ли­ди­ро­вать все име­ю­щи­е­ся у них дан­ные. Как сви­де­тель­ству­ет опыт ком­па­нии «Три­ни­да­та», про­ек­ты со­зда­ния ав­то­ма­ти­зи­ро­ван­ных си­стем, по­стро­ен­ных по ар­хи­тек­ту­ре ло­ги­че­ской вит­ри­ны дан­ных, се­год­ня вполне мож­но вы­пол­нить на ос­но­ве ПО с от­кры­тым ис­ход­ным ко­дом, а та­к­же про­дук­тов, вне­сен­ных в ре­естр оте­че­ствен­но­го ПО.

ЛИ­ТЕ­РА­ТУ­РА

1. Вик­тор Бо­ри­сов. Хра­ни­ли­ще для МВД // От­кры­тые си­сте­мы. СУБД. — 2007.— № 5. — С. 68–71. URL: www.osp.ru/os/2007/05/4265018 (да­та об­ра­ще­ния: 21.10.2018). 2. Лео­нид Чер­няк. Что де­лать с ха­о­сом дан­ных? // От­кры­тые си­сте­мы. СУБД. — 2013.— № 9. — С.16–20. URL: https://www. osp.ru/os/2013/09/13038279 (да­та об­ра­ще­ния: 29.10.2018). 3. Горш­ков С.В. Вве­де­ние в он­то­ло­ги­че­ское мо­де­ли­ро­ва­ние. 2015. URL: trinidata. ru/files/semanticintro.pdf (да­та об­ра­ще­ния: 29.10.2018). 4. Kharlamov E. et al. Ontology Based Data Access in Statoil // Web Semantics: Science, Services and Agents on the World Wide Web.— 2017. — Vol. 44. — P. 3–36.

Сер­гей Горш­ков ([email protected]) — ди­рек­тор, ком­па­ния «Три­ни­да­та». Ста­тья под­го­тов­ле­на на ос­но­ве ма­те­ри­а­лов вы­ступ­ле­ния на кон­фе­рен­ции «Тех­но­ло­гии управ­ле­ния дан­ны­ми — 2018».

Пример об­ра­бот­ки за­про­са к вит­рине

Newspapers in Russian

Newspapers from Russia

© PressReader. All rights reserved.