Другие факторы, которые нужно учитывать при проектировании

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

Очень большие базы данных

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

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

Временные ряды (временные данные)

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

Наиболее часто в таблицы в качестве дополнительного измерения вводят время. Это бывает в случаях, когда нужно сохранить старые значения, чтобы составить полную историю данных. Она может понадобиться либо для аудита, либо для выполнения транзакций так, как будто вы находитесь в прошлом (например, применение цен предыдущего месяца для оформления счетов-фактур текущего месяца). Клк правило, в этом случае во всех строках таблицы добавляются столбцы (например, DATE TO и DATE FROM). Пусть вас не обманывает кажущаяся легкость этой операции - здесь есть много проблем, они рассматриваются нами в главе 7.

В нашем примере с прокатом автомобилей мы добавляем столбцы (DATE TO, DATE FROM) к таблице BILLING RATES. Это позволяет в случае необходимости пересчитывать счета-фактуры, используя старые данные.

Стыковка с другилш системами

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

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

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

Проектирование для Oracle?

Как уже отмечалось, проектирование заключается в максимально эффективном использовании имеющегося материала и технологии. Проектируя базы данных для Oracle, вы убедитесь, что один из важнейших моментов при Принятии проектных решений - это выбор версии СУБД Oracle, которая будет использоваться для генерации. Чем новее версия, тем больше у нее возможностей.

Мы предполагаем, что вы уже обладаете достаточным опытом работы с Oracle. В этом разделе мы не пытаемся привести полное описание СУБД Oracle?, а лишь хотим подчеркнуть некоторые особенности, существенно влияющие на проектирование, и объяснить, почему они так важны.

Примечание

Если вы хорошо знакомы с Oracle?, можете пропустить этот раздел. Однако задумайтесь, хорошо ли вы понимаете, что такое:

триггеры и хранимые процедуры;

разделяемый пул;

буферный пул;

ограничения целостности;

табличные пространства только для чтения;

симметричная репликация;

ручное секционирование.

Учтите, что у многих потребителей работает несколько экземпляров СУБД на нескольких серверах, и они вряд лив состоянии обеспечить согласованность этих экземпляров. Другими словами, даже на одном и том же сервере у них могут работать разные экземпляры под разными версиями Oracle. Существует целый ряд причин возникновения подобной ситуации. Самая простая (и, вероятно, самая распространенная) состоит в том, что это позволяет протестировать новую версию перед запуском ее в эксплуатацию.

Более сложные ситуации возникают, если на узле эксплуатируются аппаратные платформы разных типов. Это связано с тем, что корпорация Oracle не выпускает одновременно версии для всех поддерживаемых платформ. Более того, некоторые версии для определенных платформ вообще отсутствуют.

Одно из величайших достижений Oracle состоит в том, что код, успешно работающий с одной версией СУБД Oracle, будет (в большинстве случаев) работать и со следующей версией. Корпорация обращает серьезное внимание на то, чтобы версии обладали такой совместимостью. Исключения из этого правила наблюдались в основном при переходе с версии 5 на версию 6. Для большинства читателей этот факт сейчас имеет чисто историческую ценность, хотя ходят слухи, что в мире до сих пор есть узлы, на которых эксплуатируются промышленные системы на базе OracleS. Мы знаем одну многонациональную компанию, у которой в июне 1996 г. в Европе было несколько узлов с OracleS. Она оправдывала это, в частности, тем, что данное приложение обеспечивает требуемую производительность и поэтому никаких причин тревожить его нет.

Отметим, однако, что если в версию Oracle внесут изменение, например, в реализацию языка SQL добавят новые зарезервированные слова, то вам придется либо работать в режиме совместимости (в котором нельзя будет воспользоваться как минимум несколькими новыми возможностями), либо обеспечить, чтобы это зарезервированное слово не применялась в приложении как имя объекта или столбца.