Архитектор нереляционных баз данных

На днях завершил чтение книжки Кайла Бэнкера ”MongoDB в действии” Освоил консоль, поразбирался с примерами, которых в книжке достаточное количество. (Естественно, как и в большинстве подобных книжек, строим интернет-магазин). Единственное с чем не сумел разобраться, так это как заставить JavaScript-оболочку под Windows работать с русскими строками. Это не очень большая беда, т.к. существует достаточное количество web-приложений для работы c MongoDB и в них такой проблемы не возникает.

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

В нереляционных базах нет таблиц. База данных это просто набор объектов. Для группировки схожих сущностей в MongoDB существуют коллекции, но они никоим образом не влияют на структуру сохраненных в них объектов. Каждый объект это просто набор атрибутов «ключ-значение». Набор этот не плоский, а иерархический, т.е. у некоторых ключей атрибутом является вложенный набор ключей со значениями. Одним словом, документ он и есть документ. У каждого объекта есть уникальный в рамках всей базы данных первичный ключ, по которому объекты и связываются друг с другом. Впрочем, связывать объекты можно и по-другому. Все это представляет идеальную «песочницу» для игр архитектора данных, свободного от стереотипов реляционной или объектно-ориентированной модели. Пожалуй, единственное ограничение заключается в том, что приложение, построенное поверх такого хранилища, все же должно заработать =)

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

Пример очень простой, но наглядный. Несмотря на то, что сотрудников всего шесть (их имена, по традиции соответствуют первым буквам алфавита), в примере есть достаточной набор отношений, включая иерархические. В ходе курса мы используем разные подходы к отображению этих фактов в виде моделей. Слушатели разных ИТ-специальностей тяготеют к разным видам моделей. Кто-то видит в этом наборе фактов организационную структуру, другие – граф отношений между людьми и приложениями. Если попросить разработчиков построить модель, то он нарисует диаграмму классов. Аналитик же скорее нарисует одну или несколько таблиц для отображения таких отношений. Естественно эти данные можно представить в виде реляционной базы (у меня получается 5 таблиц и 23 записи =)

Теперь я дополню набор упражнений с этим примером разработкой структуры базы в MongoDB. Уверен, это будет достаточно нетривиально, но интересно

Архитектор нереляционных баз данных: 2 комментария

  1. Спасибо! Актуально =)

    Но я вот пока не могу избавиться от стереотипов реляционных БД.

  2. Вы не смотрели Intersystems Cache? Если нет, то очень рекомендую. На мой взгляд, одна из (если не самая) оптимальная платформа для задач телекома. И тоже нереляционная в своей основе СУБД (SQL- и ОО- модели реализуются при необходимости поверх старых добрых иерархических глобалов).

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *