Автор оригинала Bill Inmon
Дата публикации оригинала 2007-10-25
Перевод: Константин Лисянский
Материал опубликован на сайте B-Eye Network

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

Как мы проектируем базу данных? Давным-давно мы научились нормализации у Теда Кодда и Криса Дейта. Или, может быть, мы сидели на коленях у Джеймса Мартина и изучали у него высокопроизводительные и хорошо налаженные денормализованные структуры. Как бы мы это не делали, мы изучили проектирование баз данных.

И я держу пари, что когда мы изучали проектирование баз данных, никто никогда не слышал о проектировании баз данных с разделением семантически темпоральных и статических данных. Это просто не появилось ни в чьём поле зрения, когда были положены начала проектирования баз данных.

А должно было появиться.

Для начала, что же такое семантически темпоральные и семантически статические данные? Семантически статические данные – это данные, элементы которых часто не изменяются. Общеизвестно, что данные о продажах семантически стабильны. Когда нужно производить измерение и сбор данных о продажах, эти данные не изменяются со временем. Торговцы на базаре в Каире две тысячи лет назад собирали информацию о продажах того же типа, как и Wal-Mart собирает сегодня. И можно поспорить, что в 2100 году, когда наши внуки будут управлять делами, будут собираться те же типы данных.

Семантически темпоральные данные – это данные, структура которых часто изменяется. Попытайтесь создать модель данных организационной структуры и посмотрите, как долго она проживёт. Попробуйте разработать модель данных для территорий продаж и посмотрите, что случится в следующем году. Или попробуйте смоделировать федеральное или местное законодательство. Угадайте, что произойдёт после очередных выборов? Таким образом, некоторые данные по своей природе являются семантически стабильными, в то время, как другие семантически нестабильны.

Когда вы занимались классическим проектированием баз данных, была ли проблемой семантическая стабильность? Нет, если только вы не обладали предвидением Галилея.

Что случилось бы, если бы у нас была смелость физически разделить семантически статические и семантически темпоральные данные в момент проектирования? Случилось бы нечто практически волшебное. Мы обнаружили бы, что наши базы данных способны легко противостоять изменениям требований бизнеса, которые периодически происходят.

Отделяя семантически статические данные от семантически темпоральных, наши системы могли бы элегантно принимать изменения. И как это происходит?

Когда требования бизнеса изменяются, семантически статические данные не изменяются. Это просто природа семантически статических данных. Таким образом, изменения требований бизнеса не влияют на семантически статические данные. Но, что насчёт семантически темпоральных данных? Семантически темпоральные данные изменяются каждый раз при изменении требований бизнеса. Если бы мы были достаточно умными, чтобы включать в ключевые параметры семантически темпоральных данных ДАТУ и ДАТУ ОКОНЧАНИЯ (что является довольно естественным), то каждый раз, когда в бизнесе происходят изменения, необходимо было бы создавать новый набор снимков семантически темпоральных данных. А как тяжело сделать новый набор снимков? Это же очень легко! Нам не нужно возвращаться в прошлое и изменять старые семантически темпоральные данные. Мы просто создаём новый набор снимков. И вуаля… мы можем обрабатывать изменения.

Теперь, означает ли это, что нам нужно возвращаться назад и перепроектировать наши старые базы данных? В реальности этого не произойдёт. Посмотрите на потрясение Y2K. Перепроектирование старых баз данных и переписывание кода просто не стоит на повестке дня. Но проектирование новых баз данных, идущих в будущее – это совсем другая история.


Для удобства отслеживания новых публикаций рекомендуем подписаться на рассылку или на канал RSS.

Читайте также: