Предисловие

 
 

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

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

Дейв посвятил много лет руководству Oracle Worldwide's Performance Studies Group. Работая там, он вновь и вновь убеждался в том, что проблемы производительности Oracle имеют одну основную причину. Как правило, они не были результатом дефектов в составлении методик или просчетов в настройке Oracle. Чаще всего они были следствием того, что проектировщики принимали неверные проектные решения. Мы не хотим сказать, что "традиционные" проблемы производительности не имеют место. Мы просто хотим подчеркнуть, что во многих проектах никогда невозможно будет достичь надлежащей эффективности из-за неверных проектных решений. Именно в этом контексте Дейв создал однодневный семинар под названием "Проектирование для Oracle7", который он проводил для специалистов по всему миру. Однако даже этот семинар не помог в получении надежного рецепта проектирования. Готовя его, Дейв, как и Йен, обнаружил, что каждый случай необходимо рассматривать отдельно, точно учитывая все требования проекта и техническую среду, в которой он выполняется.

Если жестких правил нет, зачем писать книгу по этому предмету? Более того, почему на рынке так мало книг о проектировании? Ответим сначала на второй вопрос. Мы считаем, что многих авторов и издателей сдерживает то, что во многих случаях здесь невозможно дать категоричные ответы (даже на такие базовые вопросы, как вопрос о том, должна ли каждая таблица иметь первичный ключ). Они считают, что читатели смогут справиться с техническим материалом лишь в случае, если есть однозначные и полные ответы на все интересующие их вопросы. Это совсем не так.

Самых веских причин, побудивших нас написать эту книгу, можно назвать две:

1. Во всех разрабатываемых проектах мы потратили много драгоценного времени, пытаясь реализовать возможности, изначально обреченные на неудачу. Другими словами, как мы ни старались, у нас ничего не получалось. Знай мы это, то не ставили перед собой недостижимые цели и сэкономили бы время.

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

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

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

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


Почему Oracle?

Одними из первых вопросов, которые задал нам издатель, были такие:

"Почему руководство по проектированию именно для Oracle? Почему не для всех реляционных баз данных? Разве Oracle так сильно отличается?" Эти вопросы остаются очень важными, и мы хотим на них ответить.

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

Мы не рассчитываем на то, что эта книга за один день сделает из вас преуспевающего проектировщика для Oracle. К сожалению, опыт ничем заменить нельзя, и главной чертой лучших проектировщиков является то, что они все время учатся. Здесь же мы собираемся создать "каркас", который позволит вам проектировать свою систему в более структурированной и управляемой форме. В каждой главе предлагаются альтернативы основным проектным решениям, подчеркиваются их достоинства и недостатки. Конечно, решение принимать вам, но мы надеемся, что поможем хорошо вооружиться для того, чтобы обосновать свой выбор.

Oracle7 — зрелый продукт. После того как корпорация Oracle впервые анонсировала его, стало ясно, что эта система знаменует собой общую тенденцию, которой следует корпорация, — изымать интеллект бизнес-правил из приложения (или пользовательского интерфейса) и помещать его в базу данных (или сервер). Это означает, что теперь необходимо тратить значительно больше времени на проектирование базы данных, чем в проектах для Огас1е6 или в проектах, где используются средства разработки 3GL. Но этап генерации теперь упрощается, особенно если проектирование проведено качественно. После начала генерации исправлять плохие решения, принятые на этапе проектирования, становится все труднее и дороже.

Неудачные проектные решения могут привести к значительному удлинению и усложнению цикла разработки и в итоге часто являются причиной низкого качества готовой системы. Если проектирование выполнено на плохом уровне, то готовой системы вообще может не быть или, если она все-таки получилась, она будет "больной". Проектируя систему, всегда думайте о ее практичности и производительности. Если вам говорят, что время реакции не имеет значения, или уверяют, что, мол, "мы исправим это позже", рекомендуем поспорить. Устранение недостатка, связанного с проектированием, в работающей системе — очень дорогое удовольствие. Попытки решить проблемы с производительностью, "бросая на них больше аппаратных средств", дают результат, по нашему опыту, только в низкопроизводительных системах, но даже там абсолютной гарантии нет.

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

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

• функциональность и адаптируемость;

• пропускную способность;

• время реакции;

• готовность;

• простоту эксплуатации;

• безопасность.


Структура книги

Книга разделена на пять частей, содержание которых кратко изложено ниже. Конечно, нам хотелось бы, чтобы вы прочитали каждое слово в книге, но мы знаем, что некоторые не захотят просматривать ее от корки до корки, а даже те, кто читают большую часть материала, часто делают это в произвольном порядке. Чтобы помочь вам, мы попытались сделать главы книги достаточно независимыми и свести число перекрестных ссылок к минимуму. Опытные проектировщики и те, кто хорошо знаком с жизненными циклами проектов, возможно, лишь бегло просмотрят некоторые из первых глав (в основном главы 1 и 2), где освещаются эти темы. Тем, кто работает с последними версиями Oracle7, наверное, можно пропустить главу 2. Многие главы, в которых описаны конкретные технологии, представляют для читателя интерес лишь в случае, если он работает над проектом, где используется какая-нибудь из этих технологий. Примерами таких технологий является использование распределенных баз данных (глава 12) и хранилищ данных (глава 13).

Часть 1: Основы проектирования

• В главе 1, "Введение", рассматриваются этапы разработки проекта — выбор стратегии, анализ, проектирование и генерация. Дается упрощенный пример реального проекта, на основе которого описываются различные этапы и результаты.

• В главе 2, "Почему проектирование так важно для Oracle?", внимание сосредотачивается на СУБД Oracle. Здесь излагаются особенности проектирования и выделяются наиболее важные черты СУБД Oracle7, а также даются краткие замечания по СУБД Огас1е8.

В главе 3, "Моделирование данных", подробно рассматриваются основы моделирования данных. Здесь определяются классические для реляционных баз данных понятия: сущность, отношение, третья нормальная форма (3НФ), а также описывается, какие результаты должны выдать аналитики проектировщикам, чтобы последние смогли превратить концептуальную модель данных в логическую.

Часть 2: Проектирование базы данных

• В главе 4, "Принятие решения о денормализации", изучаются специальные методы денормализации данных с целью повышения производительности.

• В главе 5, "Выбор типов данных, неопределенные значения", описаны различные типы данных Oracle и рассмотрены такие важные темы, как смысл неопределенного значения и возможности его обработки.

• В главе 6, "Выбор ключей и индексов", рассматриваются методы выбора наиболее подходящих ключей для конкретных баз данных.

• В главе 7, "Обработка временных данных", исследуется одна из проблем, которые свойственны Oracle и другим реляционным базам данных: отсутствие должной поддержки временных рядов (временных данных). Здесь предлагается ряд характерных для Oracle приемов, с помощью которых можно преодолеть ограничения, связанные с данными этого типа.

• В главе 8, "Загрузка и выгрузка данных", исследуются различные способы заполнения базы данных Oracle? информацией из внешних источников. Здесь также рассматривается методика извлечения данных из БД Oracle7.

• В главе 9, "Размещение и хранение объектов", изучаются некоторые наиболее важные физические аспекты проектирования баз данных, такие как оценка размеров объектов и размещение файлов.

• В главе 10, "Защита данных", освещаются вопросы резервного копирования, архивации, аудита и безопасности.

Часть 3: Проектирование под конкретные архитектуры

• В главе 11, "Проектирование для архитектур клиент/сервер", методы проектирования Oracle7 рассматриваются применительно к модели клиент/сервер. Мы изучим разнообразные приемы распределения обработки с целью оптимизации производительности и достижения эффективности обработки.

• В главе 12, "Проектирование для распределенных баз данных", рассматриваются принципы работы распределенных баз данных, изучаются различные возможности Oracle7 в этом плане и предлагаются варианты проектирования для разных сценариев.

• В главе 13, "Проектирование для хранилищ данных", рассматриваются этапы настройки и сопровождения хранилища данных. Освещаются вопросы многомерного моделирования и исследуются различные методы ввода данных в хранилища и извлечения их оттуда.

• В главе 14, "Проектирование для параллельной обработки", излагаются основы параллельной обработки данных, рассматривается практическое применение средств Oracle Parallel Query Option и Oracle Parallel Server, a также освещаются такие технологии, как стрипинг и RAID.

Часть 4: Проектирование модулей кода

• В главе 15, "Введение в проектирование кода ", рассматриваются основные понятия, связанные с проектированием модулей кода.

• В главе 16, "Где разместить логику обработки?", описан способ распределения логики приложения.

• В главе 17, "Метрики, макеты и спецификации", освещается формальная сторона проектирования кода. В частности, рассматривается вопрос о том, как обеспечить соответствие проектируемых модулей поставленным требованиям.

• Глава 18, "Блокирование", содержит информацию, которая поможет свести к минимуму проблемы, связанные с конкуренцией, в приложениях.

• В главе 19, "Выбор инструментальных средств", сравниваются достоинства различных категорий интерфейсных продуктов, которые могут поддерживать СУБД Oracle.

• В главе 20, "Экранные формы, отчеты и пакетные программы", освещаются специальные вопросы проектирования экранных форм, отчетов, пакетных программ, средств обработки ошибок, навигации и оперативных справочных систем.

Часть 5: Приложения

• В приложении А, "Готовые пакеты прикладных программ ", сравниваются выгоды от приобретения готового пакета с выгодами от разработки полного приложения "с нуля".

• В приложении Б, "Секреты мастерства ", рассматриваются три специфических приема проектирования. Мы предлагаем метод, позволяющий обойти проблему мутирующих таблиц в триггерах Oracle7. Также мы затронем проблемы, связанные с неизбежным наступлением нового столетия, и, наконец, ознакомим читателя с расширяемым SQL.


Для кого предназначена эта книга

Мы предполагаем, что читатель достаточно хорошо знаком с Oracle. Однако в книге найдется много полезного и для тех, кто имеет опыт работы с другой реляционной системой управления базами данных (РСУБД) и переходит на Oracle. He имеет значения, что ваш опыт до настоящего времени касался главным образом разработки или администрирования БД — главное, чтобы вы были знакомы с терминами и понятиями, используемыми в книге. Кроме того, мы предполагаем, что читатель обладает базовыми знаниями о цикле реализации проекта.

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


Какая версия Oracle?

Большинство из того, о чем мы говорим, касается всех версий Огас1е7. В тех немногих случаях, когда это не так, мы четко указываем, к каким версиям относится материал. А как насчет Огас1е8? Когда книга уходила в печать, этот продукт еще не был анонсирован. Естественно, мы предполагаем, что Огас1е8 поставит новые проблемы, когда пользователи начнут работать с новыми средствами. Надеемся, что при помощи Огас1е8 можно будет решить некоторые из проблем, затронутых в этой книге. В любом случае мы уверены, что подавляющее большинство наших рекомендаций останется в силе.

Примечание

То, что мы называем просто версией 7.2, в фирменной документации Oracle может называться Oracle7 Release 7.2 (редакция 7.2). Мы же в этой книге ссылаемся, как правило, на Огас1е7 (а иногда на Огас1е6 и Огас1е8), а разные редакции Огас1е7 называем версиями, потому что так их называют большинство пользователей. Корпорация Oracle предпочитает термин редакции.


Условные обозначения

В книге применяются следующие условные обозначения и шрифтовые выделения:

курсив

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

жирный шрифт

используется в заголовках.

равноширинный шрифт

используется в примерах кода.

ПРОПИСНЫМИ БУКВАМИ

в примерах кода набраны ключевые слова Oracle.

строчными буквами

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

знаки препинания

в примерах кода нужно вводить буквально.

отступ

в примерах кода помогает показать структуру, но он не обязателен.

. (точка)

в примерах кода и сопутствующих дискуссиях уточняет ссылку, отделяя имя объекта от имени компонента.

постоянная<переменная>

в примерах кода и сопутствующих дискуссиях одна часть строки или элемента данных является постоянной, а другая - переменной.

модели сущностей

изображаются согласно правилам Методики разработки информационных систем (IEM).


О примерах

Сначала мы хотели приложить к книге дискету или компакт-диск, но потом решили этого не делать, так как приведенные примеры относительно короткие и независимые. Если же вы хотите получить электронную версию какого-нибудь примера, обратитесь на Web-сервер издательства O'Reilly. Кроме того, примеры можно получить по анонимному FTP.


Комментарии и вопросы

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

Комментарии и вопросы по книге направляйте, пожалуйста, издателю:

O'Reilly & Associates
101 Morris Street
Sebastopol, CA 95472
1-800-998-9938 (в США и Канаде)
1-707-829-515 (международный или местный)
1-707-829-0104 (факс)

Можете посылать нам сообщения по электронной почте.


Слова благодарности

В создание этой книги внесли свой вклад многие люди. Прежде всего хотелось бы отметить поддержку и профессиональные советы сотрудников издательства O'Reilly & Associates. В частности, хотелось бы поблагодарить Дебби Расселл, нашего редактора, Майка Сьерру, специалиста по инструментальным средствам, который решил за нас массу проблем преобразования форматов, Джона Файлза и Дэвида Фьютато, производственных редакторов, Денни Маркуса, корректора, Криса Рейлли, художника-иллюстратора, Эди Фридмен, которая разработала обложку, Нэнси Прист, разработавшую макет, и Сета Мэйслина, который подготовил алфавитный указатель.

Сердечно благодарим наших рецензентов Марка Дейнса, Барри Гудселла, Грэма Вуда, Мартина Кантвелла, Стивена Фойерштейна и Марка Гарри за их конструктивные комментарии и рецензии.

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

Йен хотел бы особенно поблагодарить Эндрю Мэкли за его вклад в главу о хранилищах данных.

Он также выражает благодарность за поддержку своей жене Бренде и детям Тодду и Таре, особенно за то, что они мирились с тем, что он проводит за работой долгие часы.

Дейв хотел бы поблагодарить Йена, предложившего идею книги и пригласившего его в качестве соавтора. Он также благодарит свою жену Мефус за терпение, которое она проявила за это время (и за прошедшие 27 лет семейной жизни).

 
 
Используются технологии uCoz