Добрый день!
Сначала опишу ситуацию. У нас есть довольно много баз данных с временными рядами полевых наблюдений. Все эти БД работают под управлением одной и той же самописной СУБД, которая обеспечивает интерфейс для выполнения стандартных (и не очень стандартных) операций с рядами данных и их фрагментами.
Раньше все это работало локально. В каждой лаборатории (научной группе) была своя собственная БД, которая регулярно пополнялась данными наблюдений. А при необходимости хозяин (автор) БД как-то скидывал копии своей "мастер-базы" коллегам для работы с этими данными.
Но недавно мы обнаружили, что если такую базу (по сути - каталог с файлами БД) разместить в облаке, а именно, на Я-диске, то возникает новая ситуация. Любой юзер, у которого установлен клиент Я-диска и есть доступ этому облачному каталогу, может включить синхронизацию этой БД на свой локальный комп. После чего можно запустить свой экземпляр СУБД (это просто набор exe-шников на локальном компе) и подключиться к "чужой" БД: вынуть оттуда нужные данные, и т.д. Процессы синхронизации базы на разных компах происходят
почти незаметно для юзерана самом деле из-за задержек синхронизации у нас иногда возникают некоторые проблемы, которые СУБД не может предотвратить, а только "расхлебывает последствия". Но такие случаи довольно редки, так как количество пользователей у нас небольшое, и вероятность строго одновременного подключения двух юзеров к одной и той же БД очень маленькая. А при не-одновременном подключении все обрабатывается корректно
В общем, на практике все выглядит так, что теперь любой юзер потенциально может работать с любой из "частных" БД, включенных в эту систему. Однако это нельзя назвать единой БД в полноценном смысле этого слова, так как
каждая локальная БД ничего не знает про остальные То есть, ничего подобного на иерархическую или сетевую структуру баз у нас нет. Если юзер хочет добавить в свое рабочее пространство данные из другой БД, то по команде "подключиться к другой БД" он видит не список баз данных, входящих в систему, а список тех каталогов, к которым у него есть доступ. Если он знает, в каком каталоге лежит нужная ему БД, то он может туда зайти и к этой БД подключиться. Но если не знает - то найти нужную БД в принципе невозможно. Разве что заходя поочередно во все доступные каталоги с разными базами и пытаясь угадать правильный по названию каталога. А если у него нет доступа к какому-то каталогу, то он даже его название не увидит
Короче говоря, работать-то все это работает, чем мы уже почти год пользуемся. А проблема в том, что у нас научный институт, и нам теперь надо как-то все это описать в годовом отчете. В
плановом заданииэто такие обещалки, которые надо отправить начальникам, чтобы выиграть грант или утвердить тему
мы называли такую систему совместного хранения и использования наблюдений "распределенная база данных". Не знаю, насколько это правильный термин, но он хотя бы дает намек на направление движухи. Но... теперь нам надо описать все это в отчете подробнее. И вот тут-то к нам и подкрался незаметно известный зверек. Если все это вместе называется базой данных (что вроде бы логично?), и каждая отдельная "личная" (лабораторная) БД тоже называется "базой данных" (как мы всегда раньше делали и за многие десятилетия уже привыкли), то возникает путаница. Как БД может быть частью БД? Это ведь только в теории множеств нормально, а в других контекстах почти аморалка... А отчет пишется для специалистов совсем в другой сфере, которые про теорию множеств, вероятно, не слышали ничего...
А как тогда?
БД и суб-базы?
Или БД и ее фрагменты? (но каждый из которых - это абсолютно самостоятельная БД)?
Или распределенная БД, состоящая из "частных" (локальных?) баз?
Или БД, состоящая из "малых" баз? (Но "малый" намекает на размер, а он бывает совсем не маленький)
Все эти (и многие другие) варианты не нравятся, так как для нашего рабоче-крестьянского уха получается непонятно и только сбивает с толку.
Наверно, в мире настоящих БД существует какая-то общепринятая терминология для описания таких ситуаций? Можете что-то посоветовать людям, которые уже 40 лет пишут и довольно успешно используют собственную велосипедную СУБД, но за все это время так и не разобрались с терминологией?
Простой
Средний
Простой
Простой
