Гайдамакин Н. А. 13 страница

* На практике другой локальной базой может быть и база данных сервера центра­лизованной многопользовательской корпоративной системы.

 

Решение этой задачи основывается на поддержке современ­ными «настольными» СУБД (MS Access, MS FoxPro, dBase и др.) технологии «объектов доступа к данным» — DAO. При этом следует отметить, что под объектом понимается интегра­ция данных и методов их обработки в одно целое (объект), на чем, как известно, основываются объектно-ориентированное программирование и современные объектно-ориентированные операционные среды. Другими словами, СУБД, поддерживаю­щие DAO, получают возможность внедрять и оперировать в локальных базах объектами доступа к данным, физически на­ходящимся в других файлах, возможно на других вычислитель­ных установках и под управлением других СУБД.

Технически технология DAO основана на уже упоминав­шемся протоколе ODBC, который принят за стандарт досту­па не только к данным на SQL-серверах клиент-серверных сис­тем, но и в качестве стандарта доступа к любым данным под управлением реляционных СУБД. Непосредственно для дос­тупа к данным на основе протокола ODBC используются ини­циализируемые на тех установках, где находятся данные, спе­циальные программные компоненты, называемые драйверами ODBC, или инициализируемые ядра тех СУБД, под управлени­ем которых были созданы и эксплуатируются внешние базы данных. Схематично принцип и особенности доступа к вне­шним базам данных на основе объектного связывания иллюст­рируются на рис. 5.6.

Рис. 5.6. Принцип доступа к внешним данным на основе прото­кола ODBC

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

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

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

Для иллюстрации на рис. 5.7 приведен пример схемы БД, организованной на основе техники объектного связывания дан­ных распределенной системы коллективной обработки данных трех подразделений некоторой организации — службы ДОУ, от­дела кадров и бухгалтерии.* На вычислительных установках пе­речисленных подразделений, объединенных в локальную сеть, создаются и эксплуатируются локальные базы данных, струк­турные схемы которых отражают задачи и особенности предмет­ных областей сведений, необходимых для информационного обеспечения деятельности соответствующих подразделений. При этом часть данных, распределенных по таким таблицам, как «Со­трудники», «Подразделения», «Штатные категории» и др., явля­ются общепотребными для всех или для группы подразделений. Логично исключить дублирование ввода, редактирования, кор­ректировки и хранения таких общих данных, возложив эти фун­кции на пользователей тех локальных баз данных, где это наибо­лее естественно и обоснованно сточки зрения функциональных особенностей соответствующих подразделений и сложившихся информационных потоков, а пользователям локальных баз дан­ных других подразделений предоставить доступ к ним. Так, к примеру, таблицы данных по сотрудникам и подразделениям наиболее естественно заполнять данными и хранить в локаль­ной базе кадрового подразделения, обеспечивая доступ к ним пользователей локальных баз службы ДОУ и бухгалтерии. Струк­турную схему локальных баз этих подразделений в этом случае целесообразно построить на основе объектного связывания дан­ных. На рис. 5.7 связанные, т. е. физически находящиеся в дру­гих базах данных, таблицы выделены специальной раскраской и обрамлением. Стрелками на рисунке показаны связи типа «Один-ко-многим» (острие стрелки соответствует стороне «многие»).

* Данный пример является чисто иллюстративным и никаким образом не может претендовать на отражение каких-либо реальных баз данных.

 

Рис. 5.7. Пример схем локальных баз данных со связанными объектами

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

 

Рис. 5.8. Пример схем локальных баз данных со связанными объек­тами

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

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

Аналогичным образом обеспечивается доступ к данным, находящимся в базах дачных наиболее распространенных фор­матов других СУБД, таких, например, как базы данных СУБД FoxPro, dBASE, а так же к табличным данным электрон

При этом доступ может обеспечиваться как непосредствен­но ядром СУБД, так и специальными дополнительными драй­верами ISAM (Indexed Sequential Access Method), входящими, как правило, в состав комплекта СУБД. Такой подход реализу­ет интероперабельность построенных подобным образом рас­пределенных гетерогенных систем, т.е. «разномастность» ти­пов СУБД, поддерживающих локальные базы данных. При этом, однако, объектное связывание ограничивается только непосред­ственно таблицами данных, исключая другие объекты базы данных (запросы, формы, отчеты), реализация и поддержка которых зависят от специфики конкретной СУБД.

Доступ к базам данных других СУБД (см. рис. 5.6) реали­зуется через технику драйверов ODBC, которые инсталлиру­ются и выполняются на тех вычислительных установках, где находятся удаленные данные. «Идеология» в данном случае такова. В составе настольной СУБД, поддерживающей локаль­ную базу данных, можно инсталлировать дополнительный про­граммный компонент, называемый драйвером ODBC.* Инсталлируемый драйвер ODBC «регистрируется» в специальном под­каталоге системного каталога операционной системы.** Так об­разуется рабочая область прямого доступа к источникам данных ODBC.

 

* В операционной системе Windows драйверы ODBC реализуются посредством файлов DDL (библиотеки динамической компоновки).

** В операционной системе Windows данный подкаталог так и называется — ODBC.

 

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

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

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

5.4. Технологии реплицирования данных

Во многих случаях узким местом распределенных систем, построенных на основе технологий «Клиент-сервер» или объек­тного связывания данных, является недостаточно высокая про­изводительность из-за необходимости передачи по сети боль­шого количества данных. Определенную альтернативу постро­ения быстродействующих распределенных систем предоставляют технологии реплицирования данных.

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

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

При этом, однако, возникают две проблемы обеспечения одного из основополагающих принципов построения и функ­ционирования распределенных систем, а именно — непрерыв­ности согласованного состояния данных:

• обеспечение согласованного состояния во всех репли­ках количества и значений общих данных;

• обеспечение согласованного состояния во всех репли­ках структуры данных.

Обеспечение согласованного состояния общих данных, в свою очередь, основывается на реализации одного из двух принципов:

• принципа непрерывного размножения обновлений (любое обновление данных в любой реплике должно быть немедленно размножено);

• принципа отложенных обновлений (обновления реплик могут быть отложены до специальной команды или ситуации).

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

Реализация принципа непрерывного размножения обнов­лений заключается в том, что любая транзакция считается ус­пешно завершенной, если она успешно завершена на всех реп­ликах системы. На практике реализация этого принципа встре­чает существенные затруднения, связанные с тупиками, как и в технологиях синхронизационных захватов систем «Клиент-сервер». Предположим, что на одной вычислительной установке пользователь обновляет данные в своей реплике. На время осу­ществления транзакции (транзакций) соответствующие записи в базе данных этой реплики ядром локальной СУБД заблоки­рованы от изменения другими пользователями. Вместе с тем транзакция может быть зафиксирована и, следовательно, раз­блокированы соответствующие данные только тогда, когда дан­ная транзакция послана и также завершена на других репликах системы. Предположим также, что в другой реплике системы, находящейся на другом компьютере сети, в это же время дру­гой пользователь проводит свои обновления (транзакции) с теми же записями, которые, естественно, в этот момент также забло­кированы от изменений для других пользователей. Так образу­ется тупик. Одна транзакция не может быть зафиксирована в своей реплике, потому что заблокированы соответствующие записи в другой реплике. А разблокировка этих записей в дру­гой реплике также невозможна до тех пор, пока не разблокируются соответствующие записи в первой реплике, т. е. когда за­вершится транзакция в первой реплике. Создается тупиковая ситуация.

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

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

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

Решение второй проблемы согласованности данных, а именно — согласованности структуры данных, осуществля­ется через частичное отступление, как и в системах «Клиент-сервер», от принципа отсутствия центральной установки и основывается на технике «главной» реплики.

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

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

* Так называемая техника глобальных уникальных идентификаторов (GUID).

 

Важным, с точки зрения гибкости и эффективности функ­ционирования распределенных информационных систем, по­строенных на технологиях реплицирования, является возмож­ность создания так называемых частичных реплик и включения в реплики как реплицнруемых, так и нереплицируемых объектов. Частичной репликой называется база данных, содер­жащая ограниченное подмножество записей полной реплики. Распространенным способом создания частичных реплик яв­ляется использование фильтров, устанавливаемых для конкрет­ных таблиц полной (главной) реплики. Частичные реплики по­зволяют решить некоторые проблемы, связанные с разграниче­нием доступа к данным и повышают производительность обработки данных. Так, к примеру, в реплику базы данных для определенного подразделения целесообразно реплицировать только те записи таблицы «Сотрудники», которые относятся к данному подразделению, исключив тем самым доступ к дру­гим записям. Техника частичных реплик также снижает затра­ты на синхронизацию реплик, так как ограничивает количество передаваемых по сети изменений данных.

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

На рис. 5.9 иллюстрируется подход к организации общей схемы распределенной информационной системы по делопро­изводству некоторой организационной структуры на основе технологий репликации данных.

Рис. 5.9. Пример подхода к организации схемы распределенной информационной системы по делопроизводству на основе техники реплицирования

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

* Хотя, конечно же, более надежных и функциональных.

 

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

Тем не менее развитие и все более широкое распростране­ние распределенных информационных систем, определяемое самой распределенной природой информационных потоков и технологий, является основной перспективой развития автома­тизированных информационных систем.

Вопросы и упражнения

1. Что «распределено» в распределенных информационных систе­мах и каковы основные принципы создания и функционирования распределенных информационных систем?

2. Поясните суть техники «представлений» в базах данных и задачи, которые решаются на основе техники «представлений».

3. Какой из основных принципов распределенных информационных систем принесен в «жертву» в системах «Клиент-сервер»? Пояс­ните преимущества и недостатки такого подхода.

4. На какие компоненты подразделяется программное обеспечение систем «Клиент-сервер»? Какие функции выполняются каждым компонентом?

5. Поясните принципы и схемы RDA, DBS и AS-моделей систем «Клиент-сервер» и дайте их сравнительную характеристику. Ка­кие системы называются системами с «тонкими» («толстыми») клиентами, с 2- или 3-уровневой (2- или 3-звенной) архитекту­рой?

6. Охарактеризуйте роль и место монитора транзакций в СУБД cиcтем «Клиент-сервер».

7. Какие издержки совместной обработки общих данных предотв­ращает монитор транзакций в системах «Клиент-сервер»?

8. Дайте определение сериальному плану выполнения транзакций и охарактеризуйте основные подходы к механизмам построения та­ких планов.

9. Поясните суть двухфазного протокола синхронизационных захватов объектов и механизм возможного образования тупиковых ситуаций.

10. Как распознаются и разрушаются тупиковые ситуации в технике двухфазного протокола синхронизационных захватов?

11. В чем заключается гранулирование объектов захватов и почему такой подход обеспечивает более эффективные стратегии пост­роения сериальных планов выполнения транзакций?

12. Каковы достоинства и недостатки техники временных меток при синхронизационных захватах объектов?

13. В чем заключается суть и механизм объектного связывания дан­ных при построении распределенных информационных систем из разрозненных локальных баз данных?

14. Существует ли системный каталог распределенной базы данных, построенной на основе технологии объектного связывания, и ка­ким образом выражается логическая схема такой базы данных? В чем достоинства и недостатки такого подхода?

15. Какие (функции, кроме традиционных, выполняют локальные («на­стольные») СУБД при использовании технологий объектного свя­зывания?

16. Охарактеризуйте главную идею и основные подходы к построе­нию распределенных информационных систем в технологиях реплицирования данных.

17. Поясните принцип отложенных обновлений и процессов синхро­низации реплик.

18. Чем главная реплика отличается от остальных? Как наличие глав­ной реплики соотносится с принципами распределенных систем?

19. Что обеспечивается возможностью создания частичных реплик?

6. Документальные информационные системы

В развитии программного обеспечения СУБД в 70-е—80-е годы превалировало направление, связанное с фактографичес­кими информационными системами, т. е. с системами, ориен­тированными на работу со структурированными данными. Были разработаны основы и модели организации фактографических данных, отработаны программно-технические решения по на­коплению и физическому хранению таких данных, реализова­ны специальные языки запросов к базам данных и решен це­лый ряд других задач по эффективному управлению большими объемами структурированной информации. В результате осно­ву информационного обеспечения деятельности предприятий и организаций к началу 90-х годов составили фактографичес­кие информационные системы, вобравшие в себя в совокупно­сти колоссальный объем структурированных данных.*

* В этом смысле очень характерным является рекламный девиз корпорации Oracle: «Мы храним триллионы бийт».

 

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

Кроме того, входные информационные потоки в целом ряде организационно-технологических и управленческих сфер пред­ставлены неструктурированными данными в виде служебных документов и иных текстовых источников. Извлечение из тек­стов данных по формализованным позициям для ввода в фактографические системы может приводить к ошибкам и потере час­ти информации, которая в исходных источниках имеется, но в силу отсутствия в схеме базы данных адекватных элементов не может быть отражена в банке данных фактографических АИС.

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

* Представлена в электронном виде в текстовых файлах, но без средств система­тизации, обработки, анализа и эффективного поиска 6.1. Общая характеристика и виды документальных информационных систем.

 

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

Однако теоретические исследования вопросов автоматизи­рованного информационного поиска документов, начавшись еще в 50-х—60-х годах, к сожалению, не получили такой стро­гой, полной и в то же время технически реализуемой модели представления и обработки данных, как реляционная модель в фактографических системах. Не получили также стандартиза­ции (как язык SQL) и многочисленные попытки создания уни­версальных так называемых информационно-поисковых язы­ков, предназначенных для формализованного описания смыс­лового содержания документов и запросов по ним. В итоге, несмотря на то, что первые системы автоматизированного ин­формационного поиска документов появились еще в 60-х го­дах, развитые коммерческие информационно-поисковые сис­темы, ориентированные на накопление и обработку текстовых документов, получили распространение лишь в конце 80-х — начале 90-х годов.