Реляционная модель не обязательно является решением
Пережив продолжительные дебаты 1974 года [Rus74] и дискуссии между защитниками Codasyl и реляционной модели данных, авторы не желают более «кормить эту священную корову». Однако они считают уместным обсудить модель данных (или модели данных), на которой они основывают свои системы. В 1970-е гг. в мире СУБД имелись только приложения обработки бизнес-данных, и идея Теда Кодда о нормализации данных в плоские таблицы хорошо послужила сообществу баз данных в течение 30 лет. Однако теперь имеются новые области приложений, которые необходимо принимать во внимание: хранилища данных, Web-ориентированный поиск, аналитика в реальном времени и полуструктурированные данные. Авторы предлагают следующие наблюдения.
- В области хранилищ данных почти сто процентов схем относятся к категориям «звезда» или «снежинка», содержащим центральную таблицу фактов с соединениями 1-к-n с окружающими ее таблицами измерений, которые, в свою очередь, могут участвовать в соединениях 1-к-n с таблицами измерений второго уровня и т.д. Хотя схемы «звезда» и «снежинка» легко моделируются с использованием реляционных схем, на самом деле, в этой среде проще и естественнее использовать модель «сущности-связи». Более того, в E/R-модели проще формулируются запросы к хранилищам данных. Наконец, операции над хранилищами данных в реляционной реализации являются существенно более дорогостоящими. Например, операцию, эквивалентную операции изменения ключа строки в таблице измерений, можно гораздо быстрее выполнить в реализации на основе E/R-модели.
- В области обработки потоковых данных имеются следующие потребности:
- обработка потоков сообщений, поступающих с высокой скоростью;
- установление соотношений таких потоковых данных с хранимыми данными.
Для решения обеих задач принято использовать язык StreamSQL, обобщение SQL, позволяющее одновременно указывать в разделе FROM SQL-запроса хранимые таблицы и потоки.
Этот язык появился в результате пионерской работы [ABW06], выполненной в Стэндфордском университете, и в настоящее время активно обсуждается его стандартизация. Конечно, в StreamSQL поддерживаются реляционные схемы как для таблиц, так и для потоков.
Однако в коммерческих каналах, таких как Reuters, Infodyne и т.д., не фиксирована модель данных, которой должны следовать передаваемые сообщения. Некоторые из них являются плоскими и хорошо укладываются в реляционную схему. Но имеются и иерархические сообщения, например, в канале FX по поводу курсов иностранных валют. Системы обработки потоковых данных, такие как StreamBase и Coral8, в настоящее время поддерживают только плоские (реляционные) сообщения. В таких системах входной адаптер должен нормализовывать иерархические объекты в несколько типов плоских сообщений для их дальнейшей обработки. Но, к сожалению, довольно неприятным занятием является соединение частей исходного сообщения, когда требуется обработка нескольких компонентов иерархии.
Авторы статьи ожидают, что для решения этой проблемы поставщики потоковых систем будут активно переходить к использованию иерархических моделей данных, и тогда они, несомненно, отойдут от принципов Теда Кодда.
- Очевидно, реляционная модель никогда не использовалась в области текстовой обработки.
- В любой СУБД, ориентированной на обработку научных данных, такой как ASAP [SBC+07], в качестве базового типа данных, вероятно, будут использоваться многомерные массивы, а не таблицы.
- В последнее время ведутся активные обсуждения моделей данных, подходящих для представления полуструктурированных данных. Конечно, энергично обсуждается чрезмерная сложность спецификации XMLSchema [SC05]. Имеются сторонники использования для таких данных RDF [MM04] и те, кто утверждает, что RDF можно эффективно хранить в реляционной базе данных с хранением данных по столбцам [AMM+07]. Авторы считают достаточным сказать, что имеется много идей, на которых может основываться дальнейшее развитие этой области.
Реляционная модель разрабатывалась для «безразмерного» мира.При переходе к специализированным системам для каждой из них можно подобрать модель данных, наилучшим образом соответствующую конкретным особенностям этой системы.