Oracle 8 и традиционные методы
В каких случаях следует продолжать пользоваться традиционными методами разработки, а в каких — применять совершенно новый, объектно-ориентированный подход?
Очевидно, вы можете взять существующую систему на базе Oracle? и запустить ее под OracleS. Oracle всегда относилась серьезно к поддержке совместимости снизу вверх. Такая система будет работать с OracleS так же хорошо, как и с Oracle?, но не сможет воспользоваться многими преимуществами OracleS. Можно также разработать новое приложение для OracleS, в котором не будет использована ни одна из новых возможностей. Для таких проектов (а их, по нашим прогнозам, будет довольно много) традиционные методы разработки подходят так же, как и для Oracle?.
Начиная изучать особенности OracleS, мы должны поставить под сомнение некоторые концепции реляционного моделирования, например нормализацию. С тех пор как была задумана реляционная модель, принцип нормализации оставался священным и неприкосновенным. Как проектировщики, мы считаем непреложным фактом то, что логическая модель данных, лежащая в основе проекта, должна быть представлена минимум в третьей нормальной форме (3NF). Давайте, однако, вспомним о первой нормальной форме (1NF), которая утверждает, что допустимы только атомарные значения атрибутов. Все повторяющиеся группы должны быть удалены и помещены в новую (связанную) сущность. В OracleS введены два элемента, которые кажутся чуждыми для первой нормальной формы: вложенные таблицы и массивы данных переменной длины (VARRAY). Они ориентированы на ненормализованные структуры данных.
Мы настоятельно рекомендуем оставлять логическую модель данных, создаваемую при анализе, в третьей нормальной форме. Логическая модель (как следует из ее названия) не должна содержать никаких предположений относительно механизма ее физической реализации. Решение о том, следует ли использовать такую структуру, как вложенная таблица или VARRAY, должно приниматься на уровне проектирования. При каких условиях можно применять эти структуры? Если родительский элемент в модели данных имеет порожденный элемент с фиксированным числом строк и этот порожденный элемент интересует вас только в контексте родительского, то, возможно, будет разумно реализовать такую порожденную таблицу как VARRAY (рис. 2.1).
В электроэнергетике Великобритании день делится на 48 получасовых интервалов, и цена электроэнергии меняется в зависимости от времени суток и спроса. В данном случае мы имеем фиксированное число разбитых по получасовой сетке показаний счетчиков. Эти показания имеют смысл только в контексте дня в целом, поэтому мы создаем массив данных типа VARRAY и размещаем его в таблице meter_days следующим образом:
CREATE TYPE hh__reading AS VARRAY (48) OF NUMBER (9,2); CREATE TABLE meter_days(reading_date,
22
Oracle 8