Границы моего языка — это границы моего мира.
Людвиг Витгенштейн. Логико-философский трактат (1922)
Модели данных — вероятно, важнейшая часть разработки программного обеспечения в силу оказываемого ими глубочайшего воздействия не только на процесс разработки, но и на наше представление о решаемой проблеме.
Большинство приложений создаются путем наслоения одной модели данных поверх другой. Ключевой вопрос для каждого слоя: как его представить на языке непосредственно прилегающего к нему более низкого слоя? Можно привести следующие примеры.
- Разработчик приложений смотрит на окружающий мир (с людьми, фирмами, товарами, действиями, денежными потоками, датчиками и т. п.) и моделирует его на языке объектов или структур данных, а также API для манипуляции этими структурами данных. Такие структуры часто отражают специфику конкретного приложения.
- При необходимости сохранить эти структуры их выражают в виде универсальной модели данных, например документов в формате JSON или XML, графовой модели или таблиц в реляционной базе данных.
- Разработчики, создающие программное обеспечение для БД, выбирают для себя способ представления этих JSON/XML/реляционных/графовых данных в виде байтов памяти/дисковой памяти/трафика в сети. Благодаря этому появляется возможность отправлять запросы к данным, производить поиск по ним, выполнять с ними различные манипуляции и обрабатывать.
- На еще более низких уровнях инженеры аппаратного обеспечения занимаются тем, что находят способ выразить байты в терминах электрического тока, световых импульсов, магнитных полей и т. п.
В сложном приложении может быть много промежуточных уровней (например, API, создаваемые поверх других API), но исходная идея остается неизменной: каждый слой инкапсулирует сложность нижележащих слоев с помощью новой модели данных. Благодаря таким абстракциям становится возможной совместная эффективная работа различных групп людей — например, специалистов компании-производителя СУБД и использующих эту базу данных разработчиков приложений.
Существует множество различных видов моделей данных, причем каждая из них воплощает какие-либо допущения относительно ее предполагаемого использования. Одни сценарии применения поддерживаются, а другие — нет; какие-то операции выполняются быстро, а какие-то — медленно; некоторые преобразования данных можно произвести легко и естественно, а некоторые выглядят трудновыполнимыми.
Для освоения одной-единственной модели данных придется потратить немало усилий (задумайтесь, сколько уже написано книг по реляционному моделированию данных). Создание ПО — непростая задача даже при работе с одной моделью данных и без углубления в вопросы ее внутреннего функционирования. Но поскольку от нее так сильно зависит функциональность основанного на ней программного обеспечения, важно выбрать подходящую для приложения модель.
Далее в моем блоге мы рассмотрим группу универсальных моделей, ориентированных на хранение данных и выполнение запросов (пункт 2 в вышеприведенном списке). В частности, сравним реляционную модель, документоориентированную модель и несколько моделей данных на основе графов. Кроме того, рассмотрим несколько языков запросов и сравним их сценарии использования. В главе 3 мы обсудим функционирование подсистем хранения: как эти модели данных реализованы на самом деле (пункт 3 в нашем списке).