Только хорошо спланированная и хорошо спроектированная база данных даст вам возможность достигнуть хорошей производительности. Реляционные базы данных и хранилища данных имеют множество отличий, которые требуют разных методов проектирования. Реляционные базы данных проектируются с помощью хорошо известной модели «сущность - отношение» (entity-relationship, ER), в то время как пространственная модель используется для проектирования хранилища данных и киоска данных.
При использовании реляционных баз данных избыточность данных устраняется при использовании нормальных форм. Процесс нормализации разделяет каждую таблицу базы данных, которая включает избыточные данные, на две отдельные таблицы. Процесс нормализации должен быть завершен, когда все таблицы базы данных содержат только не избыточные данные.
Хорошо нормализованные таблицы имеют преимущества в OLTP, поскольку в этом случае все транзакции могут быть максимально простыми и короткими. С другой стороны, процессы бизнес-аналитики основываются на запросах, которые оперируют огромным количеством данных и никогда не бывают ни короткими, ни простыми. По этой причине хорошо нормализованные таблицы не подходят для проектирования хранилищ данных, поскольку цель систем бизнес-аналитики совершенно другая: тут существует мало одновременно выполняющихся транзакций, а каждая транзакция обращается к очень большому количеству записей. (Представьте огромный объем данных, принадлежащих хранилищу данных, содержащихся в сотнях таблиц. В большинстве запросов на поиск будут содержаться дюжины соединений больших по размеру таблиц. Подобные запросы не могут хорошо выполняться, даже если вы используете оборудование с параллельными процессорами и систему базы данных с наилучшим оптимизатором запросов.)
Хранилища данных не могут использовать модель ER, потому что эта модель подходит для проектирования баз данных с не избыточными данными. Логическая модель, используемая для проектирования хранилищ данных, называется пространственной моделью.
В пространственном моделировании каждая модель состоит из одной таблицы, которая хранит критерии, и нескольких других таблиц, которые описывают это пространство (рис. 22.1). Первая называется таблицей фактов, а остальные - таблицами измерений. Примеры данных, хранимых в таблице фактов, включают реестры продаж и расходы. Таблицы измерений обычно включают время, счета, продукцию и данные по служащим.
Каждая таблица измерений обычно имеет первичный ключ из одного столбца и несколько других атрибутов, которые подробно описывают этот элемент. С другой стороны, первичный ключ таблицы фактов является комбинацией первичных ключей всех таблиц измерений (см. рис. 22.1). По этой причине первичный ключ таблицы фактов состоит из нескольких внешних ключей. (Количество измерений также определяет количество внешних ключей в таблице фактов.) Как вы можете видеть на рис. 22.1, таблицы в пространственной модели созданы в звездообразной структуре. Поэтому такая модель часто называется схемой «звезда».
Другим отличием в природе данных в таблице фактов и соответствующих таблицах измерений является то, что большинство неключевых столбцов в таблице фактов являются числовыми и аддитивными, потому что подобные данные могут быть использованы для выполнения необходимых вычислений. (Помните, что типичный запрос к хранилищу данных считывает тысячи или даже миллионы строк за один раз, и единственно полезной операцией по отношению к такому огромному количеству строк является применение агрегатных функций (сумма, максимум, минимум или среднее значение).) Например, столбцы вроде units_of_product_soid (количество единиц проданной продукции), Total_sales (общие продажи), Profit (прибыль), или Dollars_cost (цена в долларах) являются типичными столбцами в таблице фактов. Числовые столбцы в таблице фактов, которые не составляют первичный ключ этой таблицы, называются измерениями.
С другой стороны, столбцы таблицы измерений являются строками, которые содержат текстовые описания измерений. Например, такие столбцы как Address (адрес), Location (размещение) и Name (имя) часто появляются в таблицах измерений. Такие столбцы обычно используются в качестве заголовков отчетов. Другим следствием текстовой природы столбцов в таблицах измерений и их использования в запросах является то, что каждая таблица измерений содержит гораздо больше индексов, чем соответствующая таблица фактов. (Таблица фактов обычно содержит только один уникальный индекс, состоящий из всех столбцов, входящих в состав первичного ключа таблицы.) В табл. 22.1 описываются отличия таблицы фактов от таблицы измерений.
Столбцы в таблице измерений обычно являются весьма ненормализованными, это означает, что множество столбцов зависит друг от друга. Ненормализованная структура таблицы измерений имеет одно важное назначение: все столбцы такой таблицы используются в качестве заголовков отчетов. Если отсутствие нормализации данных в таблице измерений не является желательным, то таблица измерений может быть разделена на несколько подчиненных таблиц. Это обычно бывает необходимым, когда столбцы в таблице измерений составляют иерархию. (Например, измерение product может иметь такие столбцы, как Product_id, Category__id и Subcategory_id, которые создают
трехуровневую иерархию с первичным ключом Productid в качестве корня.) Такая структура, в которой каждый уровень базовой сущности представлен в своей собственной таблице, называется схемой с контуром снежинки. На рис. 22.2 показана такая схема измерения product.
Расширение схемы «звезда» до соответствующей схемы с контуром снежинки имеет несколько преимуществ (уменьшение используемого дискового пространства, например) и один главный недостаток: схема «снежинка» требует большего количества соединений для получения информации из таблиц, что негативно влияет на производительность при выборке данных. По этой причине производительность запросов, основанных на Схеме «снежинка», обычно низкая. Поэтому проектирование с использованием схемы «снежинка» рекомендуется только в небольшом количестве очень специфических случаев.