храним в базе данных подробности о большом количестве раундов и часто выполняем итоговые запросы типа Лучший раунд для Арнольда Палмера , Лу>гшие первые девять лунок для Кори Пэйвина в Сент-Эндрюсе и т.д. В денормализованной структуре запросы такого типа будут работать хорошо.

Рис. 4.8. Таблица счета, содержащая повторяющуюся группу с фиксированным числом элементов

А вот обеспечрггь обращение к лункам как к набору будет трудно, да и реализация его будет неэлегантной. Рассмотрим запрос на поиск всех попаданий в лунку с одного удара или, хуже того, запрос на поиск всех препятствий путем соединения с таблицей, в которой имеется по одной строке на трассу, что дает все 18 номиналов для трассы. Это старая-престарая история: подход к денормализации должен определяться требованиями к обработке данных. Одна из замечательных особенностей представленной выше таблицы с повторяющейся группой состоит в том, что вставка в нее осуществляется очень быстро. Для этого нужен всего один оператор INSERT, тогда как в нормализованной версии понадобится девятнадцать таких операторов.

Мы отметили, что правильность предположения о том, что в раунде всегда 18 лунок, сомнительна. В некоторых раундах это число никогда не достигается, тогда как в матчевых встречах оно может быть и больше. Впрочем, возможно, нам не придется регистрировать дополнительные лунки и мы сможем оставить несыгранные лунки пустыми, поэтому наше предположение может оказаться приемлемым. Тем не менее, такая ситуация свидетельствует о том, с какими проблемами можно столкнуться в такой структуре. Единственный случай, где фиксированные группы надежны, - это когда они соответствуют абсолютно постоянным вещам, например, дням недели. В частности, опасно применять этот метод для отражения существующей тенденции с возможными непредвиденными обстоятельствами в будущем. Например, весьма рискованно денормализовать места в самолете и предусмотреть наличие 1000 пассажиров на рейс. Конечно, можно побиться об заклад, что какую бы цифру мы ни использовали, такие гиганты, как Боинг и Эйрбас Индастриз , когда-нибудь построят самолет, рассчитанный на большее число пассажиров!

Альтернатива данному способу денормализации - физическое размещение таблиц в общем кластере. Это позволяет хранить рядом строки логически отдельных таблиц. Кластеры мы опишем в главе 6.

в этой главе:

Тчлы дакныл

Числовые данные

Дата н время

Строковые данные

Ilecnipjjhtiiypupoenmtbic dojuibie и BLOB

Другие типы данных

Неопределетше танения

Выбор типов данных, неопределенные значения

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

amount NUMBER(8,2) NOT NULL CONSTRAINT cc lirait arant CHECK (amount > 0)

В этом столбце можно размещать только числовые данные; он должен быть заполнен для каждой строки таблицы; его значение должно быть положительным; точность этого значения - два значащих десятичных разряда. Максимальное значение, которое может храниться в этом столбце, ~ 999999 99 g этом простом определении столбца мы фактически определили ряд неявных правил, которые Oracle принудительно включает при вводе данных в базу данных.

В концептуальной информационной модели, создаваемой на этапе анализа, среда реализации не учитывается. Аналитик просто определяет атрибуты как строку, число или дату, в идеале он также назначает атрибуту домен. Домен - это просто тип атрибута, например деньги или рабочий день. Аналитик может включить ряд проверок допустимости или правил обработки, например требование, что значение должно быть положительным, ненулевым и иметь максимум два десятичных разряда (это полезно для сумм долларовых тратт, выставляемых банком на другой банк). Использование доменов упрощает задачу обеспечения непротиворечивости. К сожалению.

Oracle не поддерживает (пока) абстрактные типы данных (АТД) (есть определяемые пользователем типы столбцов). Следовательно, при проектировании мы должны переводить и описания атрибутов, и описания доменов в определения столбцов. Например, можно определить домен MONEY как NUMBER(8,2) и домен CHASSIS NO как NUMBER(ll), Ожидается, что в OracleS АТД будут поддерживаться; их поддерживают многие CASE-средства.

В этой главе мы попытаемся научить вас определять наиболее приемлемый для столбца тип. Например, какой тип данных лучше использовать для хранения числовых данных, предназначенных только для справки (а не для расчетов): NUMBER, CHAR или VARCHAR2? Выбор конкретного типа данных иногда оказывает едва заметное влияние, причем нежелательных побочных эффектов может и не быть.

Кроме того, в этой главе мы фокусируем внимание на использовании неопределенных значений (NULL). Неопределенные значения кажутся совершенно безопасными, пока вы не начнете изучать их глубже и задавать философские вопросы вроде: Что в данном случае означает неопределенное значение? . Неопределенные значения очень распространены в большинстве баз данных, с которыми мы встречались, и мы задаемся вопросом, а нужно ли это?

Типы данных

в Oracle? немного типов данных. Если исключить те, которые используются только для Trusted Oracle, то останется всего восемь:

VARCHAR2 (известный также как VARCHAR)

NUMBER

LONG

DATE

LONG RAW

ROWID

CHAR

Наиболее распространены три из них - VARCHAR2, NUMBER и DATE. Наличие такого небольшого набора типов данных может показаться недостатком, однако это не так. Типы, популярные в других продуктах и языках баз данных, в Oracle можно создать. Например, тип MONEY - это тип NUMBER с двумя десятичными разрядами, а тип POSITIVE INTEGER - тип NUMBER без десятичных разрядов и с ограничением на ввод отрицательных значений. По крайней мере, при таком положении дел вам не приходится беспокоиться об ограничениях на внутреннюю память, решая, как хранить вещественное число - с использованием типа FLOAT или типа DOUBLE.