Денормализация в дизайне таблиц

Таблицы, сделанные для человека, не требуют нормализации.

Не стоит делать колонку для данных, которые отличаются у одной-двух строк большой таблицы; можно просто указать на исключительность этих строк, сделав сноску или, ещё лучше, подписав то, что нужно, прямо под ними. Иногда можно повторить единицу измерения для каждой ячейки данных, а не выносить её в заголовок, особенно если это проценты. Иногда данные двух колонок можно подписать одной колонкой в шапке, скажем «Наблюдаемая концентрация, от…до» вместо двух колонок «Минимальная наблюдаемая концентрация» и «Максимальная наблюдаемая концентрация» (или ужасной двухярусной шапки «Наблюдаемая концентрация», и ниже: «минимальная», «максимальная»). Когда нам нужно сослаться на максимальную концентрацию в 7-й строке таблицы в последующем тексте, вовсе не обязательно нумеровать строки, можно просто выделить интересное число курсивом или цветом, и потом использовать такое же выделение в ссылке.

Существует точка зрения, что «ненормализованная» таблица хуже воспринимается человеком, потому, что человек должен разбираться в её системе. Дескать, если таблица имеет универсальную шапку, покрывающую все случаи, то человеку она привычна и понятна, а если в таблице где-то что-то подписано поперёк структуры, где-то один заголовок относится к двум строчкам, а где-то подписана единица измерения прямо у данных, то человек воспринимает такую таблицу как нечто странное.

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

Обычную таблицу человек видит — и думает, что видит данные. Но если потом у него спросить, какая же всё-таки концентрация-то была, он её не вспомнит. Человек просто отметил для себя: «Ага, вот тут много данных, если мне надо будет вникнуть — вникну». И продолжил читать текст дальше, не возвращаясь к таблице.

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

Если есть задача донести табличную информацию до человека, то нужно оформлять её так, чтобы она не казалась неким квадратным бруском, который можно пропустить и продолжить читать текст. Её нужно делать частью этого текста, но форматировать так, чтобы в ней было удобнее сориентироваться.

Нет ничего страшного в том, что такой подход непривычен, а классические таблицы в рамочках — привычны. Привычность чего-то не означает, что это хорошо. Она лишь означает, что человек перестаёт обращать внимание на связанные с этим неудобства. При этом, если человеку, привыкшему ковыряться под капотом «Жигулей», предложить пересесть на «Мерседес», вряд ли он будет против, мотивируя это привычкой.

Не стоит забывать и о том, что справочные таблицы и иллюстративные таблицы в текстах — это совсем разные вещи. Справочные таблицы созданы скорее для быстрого поиска, а не для анализа, сопоставления и осмысления данных.

Таблицы, сделанные для человека, требуют денормализации. Вдумчивой, внимательной, осмысленной денормализации, направленной на то, чтобы всеми средствами показать особенности данных.

Ведь особенности — это и есть данные; количество ног — это не данные о человеке, если их две.

Подписаться на блог
Отправить
Дальше
5 комментариев
Kosyan 2007

Илья, не плохо бы примеры показать, если не сложно.

Илья Бирман 2007

Как-нибудь в другой раз. Пока я не хотел бы поднимать спор о примерах. Здесь я о подходе говорю.

Тош 2007

ИМХО даже при проектировании БД не всегда нужно увлекаться нормализацией.
видел недавно базу, заоптимизированную до такой степени, что связь между базой и тем, что она описывает — потерялась напрочь. и сиди думай, какие таблицы в каком порядке заджойнить, чтобы вытащить сведения о нужном объекте.
а «сестренка» этой базы (та же задача, но другой разработчик) была жутко избыточна и неоптимальна, содержала кучу дубликатов — но вопросов «как теперь с этим работать» ни у кого не возникло :)

Mercury 2007

По поводу сотовых операторов. К сожалению, мне всё больше кажется, что жутко корявые таблицы тарифов ОпСоСов — «это не баг, это фича». Это часть их «программы надувательства». Потому что часто понять, как действует тот или иной тариф, можно только ценой своих денег.

buddah 2007

Полностью согласен.
Надоело объяснять заказчику, что таблички из ворда — это очень плохо и неудобно.
Илья, ты очень хорошо объяснил почему.

Ым7в 2007

2 Тош

Возникнет, когда «дубликаты» совпадать перестанут.

Мои книги