Автор работы: Пользователь скрыл имя, 08 Марта 2012 в 20:38, доклад
Эффективность функционирования информационной системы во многом зависит от ее архитектуры.
Обработка данных с помощью мэйнфреймов (больших машин с несколькими терминалами), популярная в 70-е годы, имела свои преимущества, утраченные позже, в эпоху персональных компьютеров и настольных СУБД.
Информационные системы, использующие архитектуру <клиент-сервер>, обладают серьезными преимуществами по сравнению с их аналогами, созданными на основе сетевых версий настольных СУБД:
1. Снижение сетевого трафика при выполнении запросов.
Например, при необходимости выбора пяти записей из таблицы, содержащей миллион записей, клиентское приложение посылает серверу запрос, который сервером анализируется на корректность и, если запрос корректен, компилируется, оптимизируется и выполняется. После этого результат запроса (те самые пять записей, а вовсе не вся таблица) передается обратно клиенту. В клиентское приложение передается только результат запроса, и в этом случае сетевой трафик не зависит от числа записей в таблицах, к которым произведен запрос.
2. Возможность хранения бизнес-правил (например, правил ограничения целостности данных) на сервере, что позволяет избежать дублирования кода в различных клиентских приложениях, использующих общую базу данных. Кроме того, в этом случае любое редактирование данных может быть произведено только с учетом этих правил.
3. Для описания серверных бизнес-правил в наиболее типичных ситуациях (например, при реализации связей master/detail) часто используют так называемые CASE-средства (Computer-Aided System Engineering). Эти инструменты позволяют описать подобные правила на уровне логической и физической моделей данных без программирования, а затем сгенерировать код соответствующих серверных объектов - триггеров, хранимых процедур, серверных ограничений. В этом случае клиентские приложения будут избавлены от значительной части кода, связанного с реализацией бизнес-правил непосредственно в приложении. Часть кода, связанного с обработкой данных, также может быть реализована в виде хранимых процедур сервера, что позволяет еще больше <облегчить> клиентское приложение, а это означает, что требования к рабочим станциям могут быть не столь высоки. Это снижает стоимость информационной системы, даже при использовании дорогостоящих серверных СУБД и аппаратного обеспечения.
Помимо перечисленных преимуществ, следует также отметить, что современные серверные СУБД обладают широкими возможностями:
o управления пользовательскими привилегиями и правами доступа к различным объектам базы данных. Как правило, в базе данных хранятся сведения об ее пользователях, их паролях и привилегиях, а каждый объект базы данных принадлежит какому-либо пользователю. Владелец объекта может предоставить другим пользователям право использовать его тем или иным способом (например, позволить читать из него данные какому-либо другому пользователю). Большинство серверных СУБД поддерживает так называемые роли, представляющие собой совокупность прав на доступ к тем или иным объектам базы данных. В этом случае каждый пользователь может иметь одну или несколько ролей и соответственно определенные в этих ролях привилегии;
o резервного копирования и архивации данных, а также оптимизации выполнения запросов;
o параллельной обработки данных, особенно в случае использования многопроцессорных компьютеров в качестве сервера баз данных.
Перед тем, как обсуждать наиболее популярные серверные СУБД, давайте обратим внимание на то, какими способами решается проблема модернизации устаревших информационных систем, с целью перехода к архитектуре <клиент-сервер>, и с какими проблемами можно при этом столкнуться.
С проблемой модернизации устаревших информационных систем рано или поздно сталкивается почти каждый разработчик или IT-менеджер. Проблема модернизации информационных систем в России еще долго будет оставаться актуальной.
В каждой организации, переживающей процесс модернизации информационной системы, возникают свои проблемы:
o В одной пользователи требуют сохранить привычный пользовательский интерфейс;
o в другой нужно суметь не просто перенести в новую базу унаследованные данные, но и изменить их в соответствии с вновь возникшими потребностями (например, исправить ошибки, допущенные много лет назад при проектировании данных, или объединить данные из нескольких разных источников);
o в третьей организации сохранилось и используется большое количество отчетов, созданных с помощью старой настольной СУБД, и нужно обеспечить возможность их использования в новой информационной системе;
o в четвертой процесс ввода новых данных происходит непрерывно, и это накладывает свои ограничения на то, как именно производить процесс замены СУБД и клиентских приложений.
В целом варианты модернизации информационной системы можно условно разделить на следующие категории:
1. Замена: только СУБД
Сохранение: структуры базы данных,
пользовательских приложений (или небольшой их модернизацией).
2. Замена: и СУБД,
и пользовательских приложений
Сохранение: структуры базы данных.
3. Замена: СУБД,
пользовательских приложений
и одновременная модернизация структуры базы данных.
На первый взгляд, первый вариант представляется наиболее безболезненным для пользователей и разработчиков, и он широко пропагандировался некоторое время. Если говорить о первом варианте модернизации, то больше всего повезло пользователям Microsoft Access - процесс замены базы данных Microsoft Access на Microsoft SQL Server происходит достаточно безболезненно, и пользовательские приложения при этом обычно сохраняют свою работоспособность. Так как эти СУБД (Access, и SQL Server) принадлежат одному производителю, перенос данных между ними осуществляется вполне корректно, с сохранением всех определенных в базе данных бизнес-правил. Кроме того, утилиты переноса данных содержатся в комплекте поставки различных серверных СУБД (например, Oracle). Относительно безболезненно можно осуществить перенос данных из Visual FoxPro в Microsoft SQL Server.
Что касается замены других версий настольных СУБД на серверные, здесь могут возникнуть определенные проблемы. Например, при переносе данных из dBase или Paradox в какую-нибудь серверную СУБД обслуживающее их приложение, написанное на Delphi, вполне может отказаться работать даже после корректной перенастройки библиотек доступа к данным. Возможны неприятности, связанные с несовместимостью некоторых типов данных. Наконец, если в серверной СУБД определены какие-либо бизнес-правила, нет никакой гарантии, что они идеально соблюдались в настольной СУБД, из которой переносятся данные, и в этом случае некоторое количество <ручного> труда по разбору данных, не соответствующих этим правилам гарантировано.
Отметим, однако, что переход к архитектуре <клиент-сервер> отнюдь не исчерпывается переносом данных в новую СУБД. Чтобы воспользоваться всеми преимуществами этой архитектуры, следует также реализовать бизнес-правила, содержащиеся в клиентском приложении, в виде триггеров и хранимых процедур, а затем модифицировать код клиентского приложения, удалив реализацию бизнес-правил и заменив ее на обращения к соответствующим объектам базы данных.
Второй вариант модернизации информационной системы представляет собой по существу создание нового проекта по готовой модели данных плюс только что рассмотренный перенос данных в новую СУБД.
Что касается третьего варианта модернизации, его можно рассматривать как два самостоятельных проекта: Первый из них представляет собой создание информационной системы практически <с нуля>, второй - заполнение базы унаследованными данными. При этом, поскольку структуры баз данных различны, стандартными утилитами переноса данных (имеющимися в комплектах поставки многих средств разработки и серверных СУБД) здесь обычно обойтись не удается - как правило, в этом случае создаются <одноразовые> приложения, производящие нужные преобразования данных в процессе их переноса.
Обсудив проблемы, возникающие при переносе информационных систем в архитектуру <клиент-сервер>, можно перейти к обсуждению того, какие сервисы предоставляют современные серверные СУБД, и чем следует руководствоваться при их выборе.
Выше мы обсудили преимущества архитектуры <клиент-сервер>, обусловленные ее базовыми принципами и не зависящие от того, какая конкретно СУБД выбрана. В условиях конкуренции между различными производителями СУБД каждый из них стремится к завоеванию как можно большей части рынка. Это приводит к тому, что они пытаются перегнать друг друга и предоставить потенциальному потребителю как можно больше сервисов различного назначения.
Ниже перечислены наиболее характерные для сегодняшнего дня сервисы, предоставляемые серверными СУБД.
Почти все современные серверы баз данных существуют в нескольких версиях для различных платформ. Большинство производители серверных СУБД выпускают версии для Linux. Исключением из этого правила является Microsoft SQL Server (для этой СУБД это вполне оправданно, т.к. компания Microsoft сама производит серверные операционные системы).
Администрирование сервера баз данных, конечно, - удел профессионалов. Однако и профессионал предпочтет удобные утилиты администрирования унылому окну с интерфейсом командной строки. Наличие удобных утилит администрирования, как ни странно, иногда оказывается одним из решающих факторов при выборе СУБД. Следует отметить, что производители СУБД, вовремя не заметившие эту тенденцию, оказались лишенными значительной части рынка или практически вытесненными с него.
Резервное копирование данных и журналов транзакций поддерживается всеми без исключения коммерческими серверными СУБД. Различия между СУБД в поддержке резервного копирования заключаются в том, возможно ли производить резервное копирование в процессе работы пользователей, и если да, то какие пользовательские операции в это время нельзя выполнять.
Репликация по существу представляет собой гарантированное копирование информации из одной базы в несколько других. Репликации используются для разделения нагрузки между серверами в сети, для перемещения поднаборов данных на вспомогательные серверы, для синхронизации данных на нескольких серверах и многих других целей.
В том или ином виде репликации поддерживаются всеми современными серверными СУБД. Различия могут быть лишь в поддержке тех или иных конкретных сценариев репликаций.
Если вы планируете иметь несколько серверов баз данных с необходимостью синхронизации данных (например, у вашего предприятия существует несколько филиалов), стоит обратить внимание на то, какие сценарии репликаций поддерживаются в выбранной вами СУБД.
О возможностях повышения производительности с помощью параллельной обработки запросов в многопроцессорных системах начали говорить после появления первого продукта такого класса - Oracle Parallel Server. Серверы, поддерживающие параллельную обработку, разрешают нескольким процессорам обращаться к одной базе данных, что позволяет обеспечить высокую скорость обработки транзакций.
В настоящее время подавляющее большинство производителей современных серверных СУБД поставляют на рынок версии, поддерживающие параллельную обработку данных.
OLAP (On-Line Analytical Processing) представляет собой технологию построения многомерных хранилищ данных, как правило, агрегатных, то есть являющихся результатом обработки набора данных. Такие хранилища данных в последнее время широко используются в системах поддержки принятия решений.
Многомерные хранилища данных могут быть реализованы как в виде набора обычных реляционных таблиц, так и в виде нереляционной многомерной базы данных. В последнем случае такое хранилище обычно управляется отдельным сервером. Многие производители серверных СУБД поставляют такие серверы отдельно (Oracle, Informix), некоторые включают их в состав сервера реляционных баз данных (Microsoft SQL Server).
О распределенных транзакциях и запросах заговорили, когда наличие нескольких серверов баз данных в одной организации стало обычным явлением. Нужно отметить, что возможности выполнения распределенного запроса или распределенной транзакции поддерживаются сейчас почти всеми серверными СУБД. С этой целью используется механизм двухфазного завершения транзакций (two-phase commit), когда на первом этапе серверы, вовлеченные в транзакцию, сигнализируют о готовности ее завершить, а на втором этапе происходит реальная фиксация изменений в базах данных.
Многие производители серверных СУБД производят также средства анализа бизнес-процессов и проектирования данных, иногда универсальные, а порой ориентированные главным образом на конкретную СУБД (как в случае Oracle Designer/2000). Многие производители СУБД не имеют в своем арсенале собственных средств проектирования данных, ориентируясь на универсальные CASE-средства. Нередко производители СУБД встраивают в административные утилиты несложные средства проектирования данных, позволяющие визуально редактировать схемы данных, как это сделано, например, в Microsoft SQL Server.
Многие производители серверных СУБД выпускают также средства разработки и генераторы отчетов.
Практически все производители серверных СУБД делают все возможное для того, чтобы клиентские приложения для их СУБД можно было создавать с помощью других средств разработки. Например, это сделано в клиентских частях Oracle, Microsoft SQL Server, Informix. Производители серверных СУБД, ориентирующиеся только на собственные средства разработки, как правило, оказываются вытесненными с рынка или теряют его часть.