Как документировать базы данных

Казалось бы, если архитекторы информационных систем что-то и умеют делать, то это что-то – документирование структуры базы данных. Питер Чен еще в 1976 году предложил модель «сущность-связь», в которой сущности отображаются в виде прямоугольника, их атрибуты — в виде овала, а отношения между сущностями в виде ромба. В дальнейшем, отношения выродились в стрелки или птичьи следы (crow’s foot) атрибуты вписались в квадратики сущностей и все это преобразовалось в знакомую нам нотацию IDEF1x. Затем появились case-средства, типа ErWin и задача документирования реляционных баз данных, вроде бы, была решена. Но есть, как минимум, две проблемы.

Первая заключается в том, что структура данных и сами данные вещи немного разные. Как сказали бы приверженцы нейро-лингвистического программирования, карта – не территория, а меню это не еда. Вторая проблема лежит в самих реляционных базах данных. По словам Эдгара Кодда реляционной модели недостает возможностей для отображения семантики данных (см. Как внести больше смысла в структуры основных данных). Одним словом, если мы хотим адекватно описать базу данных, мы не можем ограничиться рисованием ER-модели. В конечном счете, она придумывалась для проектирования структуры данных, а не для описания того, что выросло из такого проекта за несколько лет эксплуатации развития. Игнорируя задачу описания данных, мы уподобимся «библиотекарям» из знаменитой книжки Терри Уайта «Чего хочет бизнес от ИТ»

Вы, ИТ-специалисты, никогда не сможете занять ключевые посты в своей организации… Потому что вы ведете себя как библиотекари, которые никогда не читают книг, — вы регистрируете их, вносите в каталог, расставляете по полкам, выдаете по первому требованию и даже берете с читателей пеню за не сданные вовремя книги, но сами их никогда не читаете!

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

  1. UML color. Питер Код (Peter Coad), известный книжками по объектно-ориентированному проектированию предложил раскрашивать разные типы сущностей в разные цвета. Это хорошая и уже достаточно распространенная идея.
  2. Таблицы и атрибуты не одинаковы. Эдгар Кодд, размышляя о внесении семантики в реляционную модель данных, выделяет три вида свойств: непосредственные, характеризующие и ассоциативные. Очевидно, что таблица, ассоциирующая основные данные должна выделяться от таблиц с основными данными, а основные данные должны отличаться от таблиц с транзакциями.
  3. Характеризующие свойства можно вынести с диаграммы. Вообще, не нужно на ER-диаграмме рисовать все таблицы. А в тех таблицах, которые надо нарисовать, совершенно необязательно перечислять все поля. Интерфейсные таблицы, копии и логии транзакций затрудняют понимание структуры данных.
  4. Справочники свойств, допустимых состояний и т.д. интересны не своей структурой, а содержанием. Содержание таких таблиц надо выносить на отдельные диаграммы. Например, диаграмму состояний.
  5. Размер имеет значение. Примерное количество записей, указанное в комментарии или на самом классе, вряд ли окажется лишним.

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

Реклама

5 Comments

  1. Цветовое кодирование — хорошая идея, но при распечатке на ч/б принтере такая информация будет потеряна.

    Желательно при проектировании систем придерживаться стандартных наименований сущностей. Можно использовать префиксы, предварительно классифицировав сущности проектируемой системы.

    Это может занять некоторое время, может вызвать даже полемику, но в итоге (при разумном подходе) классов и соответствующих им префиксов будет на самом деле не очень много.

    Ответить

    1. Согласен. Я еще не написал о том, как происходит распихивание иерархии классов по разным таблицам и о том, как их потом собирать на картинке. Но это сложная тема, для писателя масштаба Мартина Фаулера. И еще о схожих атрибутах для разных сущностей.

      Но это все относится к проектированию, а не к документированию существующих СУБД

      Ответить

  2. Вообще-то любой мэппинг приводит к нужде документировать БД, причем формально. Этим довольно долго занимались люди в промышленности (когда нужно передать большой кусок БД какого-нибудь САПР или PLM заказчику, чтобы тот мог с ним что-нибудь сделать. Что это как не документирование?). Пока лучшее решение — это ISO 15926 (литература в http://dot15926.livejournal.com/27293.html). Особо отмечу, это главным образом про документирование существующих СУБД, а не про проектирование новых.

    Ответить

  3. Максим Здравствуйте. Очень понравился логотип к Вашей заметке. Если у Вас есть изображение данного логотипа в более высоком качестве буду признателен если Вы позволите использовать его в презентации. Спасибо

    Ответить

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

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s