Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 7)

Первичная документация по Редактору системных правил находится в руководстве Microsoft Windows 95 Resource Kit.

6. Сравнительный анализ систем управления базами данных.

6.1. Сравнительный анализ систем управления базами данных.

При выборе использования той или иной СУБД необходимо произвести некоторый анализ, определяющий результат выбора. Его удобно производить оценивая несколько возможных вариантов. Такой сравнительный анализ предусматривает прежде всего формулировку критериев оценки СУБД, которые в основном определяются исходя из двух проблем, влияющих на успешность выполнения СУБД своих функций. Это большой объем данных, хранящихся в базе данных и, что актуально для СУБД, поддерживающих работу в сети, большое количество одновременных транзакций. Исходя из этого критерии оценки можно сформулировать следующим образом:

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

• Обеспечивает ли СУБД сугубо последовательный режим записи в журнальные файлы (что выполняется быстро), или возможны "обратные чтения" журналов, если они используются для отката транзакций (что, несомненно, может вызвать задержку всех выполняемых в данный момент транзакций)?

• Осуществляется ли запись в журнальные файлы только измененных данных БД, либо запись производится более крупными блоками (что также очевидно отрицательно влияет на производительность)?

• Обеспечивает ли СУБД асинхронное выполнение контрольных точек, или данная операция требует приостановки выполнения транзакций (что будет неизбежно приводить к периодическим "зависаниям" СУБД, тем более значительным, чем больший ресурс оперативной памяти на сервере используется)?

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

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

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

• Масштабируемость (возможности СУБД адекватно адаптироваться как к увеличению нагрузки, так и к расширению конфигурации или увеличению мощности сервера).

Кроме этого имеет смысл учитывать слудющие характеристики СУБД:

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

• Архитектурные решения СУБД (рассматриваемые в комплексе с архитектурными решениями ОС), направленные на обеспечение максимально возможного использования ресурсов сервера.

Если рассматривать современные СУБД клиент/сервер, то можно отметить что они обладают, в общем, схожими характеристиками.

Однако, согласно техническому заданию распределенная БД должна работать под управлением СУБД Oracle.

6.2. Система управления базами данных Oracle.

6.2.1. Средства разработки Oracle

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

В зависимости от масштаба и назначения разработки, инструменты Oracle могут комплектоваться в наборы, наиболее оптимально соответствующие поставленным задачам. Из основных инструментов Oracle необходимо выделить следующие:

1. Designer/2000 - Средство описания разрабатываемой системы в виде всеохватывающей модели и генерации на ее основе законченных приложений для различных средств разработки.

2. Developer/2000 - Многоплатформленное и масштабируемое средство визуального создания промышленных приложений, легко настраиваемых в зависимости от мощности сервера и клиентских компьютеров и переносимых на работу в среду Internet/Intranet.

3. Power Objects - Инструмент для разработки приложений небольшого масштаба, способного работать с разнообразными источниками данных.

4. Programmer/2000 - Набор предкомпиляторов

для C/C+, заметно упрощающих создание приложений на C/C+ для сервера Oracle7.

1. Mobile Agents - Позволяет разрабатывать приложения для мобильных пользователей или для удаленных систем, работающих через плохие, неустойчивые каналы связи.

Необходимо отметить, что в отличие от "универсальных" средств разработок, ориентированных на работу с любыми СУБД (Delphi, Visual Basic, PowerBuilder), "родные" инструменты полностью используют все возможности сервера Oracle7. А именно, поддержка последовательностей и синонимов, работа с механизмом обеспечения секретности на сервере, доступ к хранимым на сервере процедурам и переменным, управление оптимизатором выполнения SQL-команд - использование этих возможностей либо невозможно в универсальных средствах разработок, либо требует большого труда при кодировании.

6.2.2. Инструменты сквозного проектирования и разработки приложений

На этапе предварительного обследования деятельности предприятия (той деятельности, которую необходимо автоматизировать) используется компонента Designer/2000 - средство построения диаграмм деловых процессов BPR (Business Process Modeler). С его помощь возможно не только построить модель всех процессов, протекающих в ходе повседневной деятельности организации (предприятия), но и произвести ряд анализов, способных выявить узкие места. Даже без последующего создания приложения, такая модель позволяет лучше понять как протекает деятельность организации и найти пути по ее улучшению.

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

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

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

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

Генерация для клиентской части возможно для целого ряда различных средств разработок. Сейчас поддерживаются :

1. Oracle Developer/2000

2. Oracle Power Objects

3. Oracle WebServer

4. MS Visual Basic 3.0 и 4.0

5. Классы C/C+

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

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

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

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

Важной особенностью является возможность восстановить модель приложения по уже существующему приложению, созданного без применения Designer/2000, с помощью процедуры реинжиниринга. Так же и вручную сделанные изменения в сгенерированной системе можно отразить в модели приложения и при последующей генерации они не будут потеряны.

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

6.2.3. Обеспечение независимости от смены платформ и технологий

Другой иллюстрацией подхода корпорации Oracle к обеспечению создания независимых от платформы приложений является Developer/2000. Это инструментарий визуального проектирования клиентских приложений для технологии Клиент-сервер. Developer/2000 полностью переносим на все используемые ныне платформы, начиная от символьных терминалов и кончая графическими средами вроде Windows или Motif. Если при разработке не использовались платформенно зависимые особенности (например компоненты OCX/ActivX для Windows), то перенос приложения на другую платформу не требует никакого кодирования! Рост популярности приложений для Internet/Intranet вызвал необходимость для разработчиков изучения как новых технологий, так и новых сред разработки для Web. Перенос приложения в среду Internet/Intranet означал практически полностью его переписывание на новом средстве разработки. Поэтому многие фирмы-производители инструментальных средств поддержали технологию Netscape Plug-In, которая позволяла определенным способом распространять и вызывать приложения через Web, не сильно их переделывая. Но на самом деле, это только временное решение, т.к. для выполнения приложения необходимо держать на клиентском компьютере полностью Run-Time среду, а само приложение целиком закачивается с Web-сервера.

Применение Developer/2000 позволяет перенести прикладную систему в среду Internet/Intranet более элегантным способом. Существует возможность разместить Run-Time среду Developer/2000 на Web-сервере, а откомпилированное приложение передается ей безо всякой модификации. Специальный кэтридж Web Developer'а формирует на лету Java Applets, которые передаются на клиентский компьютер в любую программу просмотра Web. Пользователь видит перед собой тот же пользовательский интерфейс, как если бы приложение выполнялось на его компьютере, а работать может даже на DOS-компьютере с 640 КБ памяти!

Характеристики

Список файлов домашнего задания