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

Выявление потенциальных узких мест в предлагаемой системе

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

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

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

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

Обнор продуктов третьих фирн

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

Не жалейте времени на объективную оценку готовых продуктов и сравнение их друг с другом и с вашим доморощенным решением. В приложении А мы подробно расскажем о том, с какими проблемами вам, может быть, придется столкнуться при работе с покупным ПО. Если вас жестко ограничивают сроки и смета, то покупное ПО может несколько ослабить напряжение (а может и усилить его).

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

Согласование стандартов проектирования и реализации

Вам понадобится система стандартов, регламентирующих такие вещи, как правила именования объектов базы данных, стандарты проектной документации, механизмы инициирования изменений в программах и т.д. Кроме того, понадобятся стандарты, определяющие правила использования языков SQL и PL/SQL, и отдельный стандарт на каждый инструмент или продукт, используемый для разработки.

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

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

Рассмотрение возможности использования CASE-cpedcme

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

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

в нашей системе-примере анализ проводился средствами Oracle Designer/2000, и мы будем продолжать пользоваться этим продуктом при проектировании.

Сондание инфраструктуры проектирования и полной среды реализации

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

Проектирование базы данных

Задачи, изложенные в этом разделе, касаются проектирования реальной] базы данных. Именно на этом этапе мы проектируем определения физиче- i ских таблиц и столбцов, индексы или кластеры для их поддержки, ограни-1 чения и триггеры, которые вводят определенные правила, и элементы управления целостностью, а также некоторую часть резидентного кода базы данных.

Построение согласованной, реализуемой

и нормализованной информационной модели

Работа проектировщиков базы данных очень зависит от того, насколько точна информационная модель. Модель, созданная на этапе анализа, не должна содержать никаких непонятных конструкций, которые нельзя реализовать в базе данных Oracle? (подробнее об этом в главе 3). Эта модель должна быть полностью преобразована в третью нормальную форму (ЗНФ) или в нормальную форму Бойса-Кодда (НФБК). Четвертая и пятая нормальные формы (они также описываются в главе 3) вам не нужны.

Hocnipoeuue логической и физической людели данных

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

Помните, что проектирование базы данных не может происходить в отрыве от проектирования приложений и модулей. Это особенно характерно