записка1. Вебприложение для реализации алгоритмов поиска на примере шахматной игры
 Скачать 202.24 Kb.
|
СУБД как способ реализации ИСЗначимой частью любой ИС являются данные. Эффективность ИС определяется тем, насколько эффективно производится управление этими данными. При реализации первых ИС разработчикам приходилось самим решать такие вопросы, как структурирование и размещение данных на магнитных носителях, способы навигации по данным и манипулирования ими, создание средств поддержания целостности данных. В настоящее время имеется широкий выбор различного рода программных систем, берущих на себя все вопросы по организации данных и работе с ними (далее СУБД). По принципам организации данных СУБД можно разделить на следующие: модель, основанная на инвертированных списках, иерархическая модель, сетевая модель и реляционная модель. Первые три являются предшественницами реляционной модели. Общим моментом у этих СУБД является отсутствие абстрактной модели данных, появившейся только с возникновением реляционных СУБД, и наличие навигации, осуществляемой на уровне записей. То есть сами системы не имеют каких-либо средств оптимизации доступа к данным и эту проблему приходится решать самому пользователю. Все это обуславливает сильную зависимость таких СУБД от физического способа представления данных и файловой системы конкретной операционной системы.
Разработка базы данных - поэтапный процесс, в котором можно выделить 6 стадий. Экспертам предприятия приходится участвовать в этом процессе почти на всех его стадиях. Первая стадия разработки - начальное планирование для определения потребностей и возможностей разработки новой системы. Цель - определить, является ли предлагаемая система технологически и экономически возможной. Если это так, то начинается новая стадия. Далее идет определение требований, которое включает определение области применения предлагаемой базы данных, основных требований к программному и аппаратному обеспечению, а также потребностей пользователей. Область применения определяется в консультациях с руководством организации и отражает информационные потребности организации, ее стратегические цели и задачи. После этого собирается информация о таких факторах, как число пользователей и ожидаемый объем операций, которые используются для определения основных требований к программному и аппаратному обеспечению новой системы [4]. Данные о потребностях пользователей собираются различными методами, например, с помощью интервью или анкетирования. Эти данные используются для предварительного определения отдельных представлений пользователей (внешних подсхем), которые бы отражали как требования обработки операций, так и требования процесса принятия решений. При разработке базы данных приходится принимать во внимание несколько требований: база данных должна содержать все данные и отношения, нужные различным пользователям. Интересы пользователей и источников данных должны быть скоординированы; собираться и храниться должны только полезные и относящиеся к делу данные; хранимые данные должны постоянно обновляться, чтобы отразить текущее состояние дел; в базе данных не должно быть ошибок и неточностей; хранимые данные должны быть доступны для всех легальных пользователей в нужное им время; на хранение данных должно тратиться не очень много ресурсов, а время обновления, извлечения данных и эксплуатация базы данных должно быть приемлемым; затраты на содержание базы данных не должны превышать выгод от ее использования; база данных должна быть защищена от потери данных, разрушения и несанкционированного доступа; возможные изменения в жизни организации не должны приводить к полной замене базы данных; К сожалению, не всегда возможно добиться наилучших результатов по всем этим требованиям. Во многих случаях приходится идти на компромисс. Например, экономичность часто находится в противоречии с гибкостью и доступностью базы данных. Поэтому при разработке базы данных пытаются достичь возможного баланса между целями. На этапе логического проектирования завершается разработка внешних схем базы данных. Требования различных пользователей и прикладных программ переводятся на язык концептуальной схемы, используя REA модель и E-R диаграммы. Часто на этом этапе выделяются подсистемы будущей базы данных, отвечающие за различные информационные нужды. Например, подсистемы продаж, закупок, кадров, производства и т.д. Это делается для удобства разработки и эксплуатации. Кроме того, на этом этапе определяются первичные и вторичные ключи, разрабатывается справочник данных. Физическое проектирование состоит в переводе концептуальной разработки в физически существующие структуры хранения данных и работающих с ними программ. Здесь концептуальная схема переводится во внутреннюю, создается справочник данных, определяются способы физического хранения и доступа к базе данных, в том числе принимаются решения об использовании индексов. Внедрение состоит в том, чтобы подготовить, инициировать и запустить все процессы, связанные с эксплуатацией базы данных. Это включает преобразование существующих данных в формат файлов новой базы данных, разработку новых прикладных программ и модификацию существующих, обучение пользователей, тестирование работы базы данных, переход на ее использование. Стадия эксплуатации включает не просто реальное использование базы данных, но и наблюдение за ее работой и выявлением неудовлетворенности пользователей, чтобы определить, что необходимо усовершенствовать. По различным причинам базы данных "стареют" и если простой модификации становится недостаточно, то возникает потребность разработки новых принципов работы. На этом жизненный цикл БД начинается сначала. Эксперты организации должны быть вовлечены во все стадии разработки базы данных. На стадии планирования они предоставляют информацию для оценки возможностей и участвуют в принятии решения по этому вопросу. На стадии определения требований и логического проектирования они участвуют в определении информационных потребностей пользователей, разработке схем, словаря данных, мер контроля. Во время внедрения - в тестировании базы данных и прикладных программ. Наконец, при эксплуатации они используют базу данных и помогают принимать решения по ее управлению. Примерно 30% успеха проектов моделирования базы данных определяется выбором моделей данных, которое должно поддерживаться существующими вычислительными возможностями. Программное обеспечение (ПО) сервера службы сервисной поддержки должно удовлетворять следующим требованиям: переносимость; масштабируемость; простота администрирования; минимальные требования к аппаратной части; низкая стоимость ПО или возможность получить его бесплатно. Кроме перечисленных условий, сервер центра сервисной поддержки должен: соответствовать архитектуре - "клиент-сервер"; иметь документно-ориентированный способ хранения информации; иметь мультиплатформенность для увеличения гибкости развертывания системы и удешевления внедрения; автоматически выполнять резервное копирование баз данных и основных приложений; иметь надежную и проверенную временем систему безопасности. При этом ключевым фактором остается вид базы данных. На сегодняшний день существуют 2 принципиально разных вида баз данных: реляционный и постреляционный (объектно-ориентированный). К первому относится подавляющее большинство промышленных БД: MS SQL Server, Oracle, InterBase и т.д. Ко второй группе можно отнести Lotus Notes/Domino и СУБД Cache. СУБД характеризуются различными логическими моделями, на которых они основаны.
Такая СУБД представляет данные в виде упорядоченного набора деревьев. При этом удобно оперировать терминами "потомок" и "предок". "Потомок" должен иметь только одного "предка", а "предок" может иметь несколько "потомков". Порядок обхода определен сверху вниз и слева направо. То есть применяется известная методология работы с древовидными структурами данных. Также поддерживается целостность ссылок между "предками" и "потомками".
Это естественное расширение предыдущей модели, характеризующееся снятием ограничений на количество "предков" у "потомков". При этом появились различные типы связей между "потомками" и "предками", необходимость которых объясняется потребностью при навигации правильно определить нужного "предка". Поддержание ограничений целостности здесь не требуется, однако иногда необходимо иметь целостность по ссылкам, как в иерархической модели. К достоинствам вышеописанных систем можно отнести достаточно развитые средства управления данными во внешней памяти на низком уровне; возможность построения вручную эффективных прикладных систем; возможность экономии памяти за счет разделения подобъектов (в сетевых системах). К недостаткам этих же систем относится заметная сложность в использовании; необходимость знаний о физической структуре организации данных; зависимость прикладных систем от этой организации; логика прикладных систем перегружена деталями доступа к данным СУБД.
Реляционные базы данных представляют связанную между собой совокупность таблиц баз данных. Связь между таблицами может находить свое отражение в структуре данных, а может только подразумеваться, то есть присутствовать на неформализованном уровне. Каждая таблица БД представляется как совокупность строк и столбцов, где строки соответствуют экземпляру объекта, конкретному событию или явлению, а столбцы - признакам, характеристикам, параметрам объекта (события, явления). Реляционные БД в 70-х годах практически вытеснили БД других видов. В качестве основных причин этого называют сложность представления данных в иерархической и сетевой моделях и необходимость определения связей между данными на этапе проектирования БД, в то время как в реляционных БД связи между таблицами могут устанавливаться непосредственно в момент выполнения запросов. Кроме того, разработчикам и пользователям значительно проще отображать сущности предметной области в табличных структурах данных. Реляционные СУБД выгодно отличаются наличием мощного математического аппарата, опирающегося главным образом на теорию множеств и математическую логику и обеспечивающего теоретический базис реляционного подхода к организации баз данных; наличием возможности ненавигационного манипулирования данными, без необходимости знания конкретной физической организации баз данных во внешней памяти. Однако иерархическая и сетевая модели БД продолжают использоваться, они находят свое воплощение в отдельных специализированных БД и являются одной из основ, на которых строятся архитектуры так называемых "постреляционных" баз данных. В настоящее время быстрыми темпами развиваются объектно-ориентированные БД, оперирующие категориями объектов, и, так называемые, полнотекстовые БД, позволяющие производить быстрые выборки из неструктурированной информации (текстов, изображений). Тем не менее реляционные БД остаются наиболее используемыми.
Создание модели вычислений "клиент-сервер", знаменует собой следующий этап в развитии СУБД. Характерной особенностью архитектуры "клиент-сервер" является перенос вычислительной нагрузки на сервер БД и максимальная разгрузка от нее приложения клиента. Вычисления "клиент-сервер" имеют преимущества модели сетевых вычислений, с доступом к совместно используемым данным, и высокие характеристики производительности, присущие модели вычислений с хостмашиной. Система вычислений "клиент-сервер" состоит из трех различных компонентов, каждый из которых выполняет конкретную работу: сервер базы данных, клиентское приложение и сеть. Сервер ("внутренний компонент") управляет ресурсом (таким, как информационная база данных). Основной функцией сервера является оптимальное распределение одновременно запрашиваемых ресурсов между клиентами. Серверы баз данных выполняют такие задачи, как управление одной информационной базой данных, с которой совместно работают множество пользователей; управление доступом к БД; защита информации в БД с помощью средств архивации/восстановления и создания резервных копий; централизованное задание для всех клиентских приложений правил глобальной целостности данных. Клиентское приложение ("внешний интерфейс") - это часть системы, которую пользователь использует для взаимодействия с данными. Клиентские приложения в СУБД "клиент-сервер" выполняют следующие задачи: представление интерфейса, с помощью которого пользователь может выполнять свою работу; управление логикой приложения; выполнение логики приложения; проверка допустимости данных; запрос и получение информации от сервера базы данных. Средством передачи данных между клиентом и сервером в системе являются сеть и коммуникационное программное обеспечение, имеющееся у клиента и на сервере и позволяющее им взаимодействовать через сеть. Поскольку клиентское приложение и сервер базы данных работают совместно и распределяют загрузку приложения, система "клиент-сервер" обеспечивает лучшую производительность, чем система с файловым сервером. Сервер управляет для нескольких клиентов базой данных, а клиенты посылают, получают и анализируют переданные с сервера данные. В приложении "клиент-сервер" клиентское приложение работает с небольшими специальными наборами данных (например, строками таблицы), а не с целыми файлами, как в системе с файловым сервером. Сервер базы данных здесь является интеллектуальным. Он блокирует и возвращает строки по запросам клиентов, что обеспечивает параллельность, минимальный сетевой трафик и улучшенную производительность системы. Сервер реализует управление транзакциями и предотвращает попытки одновременного изменения одних и тех же данных, отслеживает уровни доступа для каждого пользователя и блокирует выполнение неразрешенных для него действий, что обеспечивает высокий уровень безопасности БД, смысловую и ссылочную целостность информации. Преимущества модели "клиент-сервер" определяются и тем фактом, что клиентская и серверная часть системы работают на разных компьютерах. Поэтому каждая конфигурация компьютера выбирается так, что он лучше всего отвечает требованиям каждого компонента системы. Благодаря этому организация может свести до минимума затраты на приобретение аппаратных средств, требующихся для функционирования системы. Кроме того, данная модель обладает хорошей адаптируемостью и гибкостью в случае неизбежных изменений в программном и аппаратном обеспечении. Еще одним из достоинств является то, что система "клиент-сервер" легко масштабируется, приспосабливаясь к изменениям в рабочей группе. Развитие идей архитектуры "клиент-сервер" привело к появлению многозвенной архитектуры доступа к базам данных. Архитектура "клиент-сервер" является двухзвенной. Одним звеном является приложение клиента, другим - сервер БД и сама БД. В трехзвенной архитектуре наборы данных (группы записей из одной или нескольких таблиц БД), бывшие ранее собственностью клиентских приложений, выделяются в отдельное звено, называемое сервером приложений. На сервере приложений расположены реальные наборы данных. Он разделяется между несколькими клиентами и формирует запросы к удаленной базе данных, то есть к серверу. В клиентском приложении размещается локальная копия данных с сервера приложений. Все изменения, вносимые пользователем, записываются в локальную копию. При обновлении набора данных клиентское приложение посылает серверу приложений только измененные записи. Сервер приложений, в свою очередь, отсылает эти изменения к серверу, который вносит их в БД. Приведенный выше перечень архитектур баз данных далеко не исчерпывает всех возможных вариантов. Представляют интерес и комбинированные решения. Целесообразность применения того или иного из них может быть определена в ходе проработки проекта ИС, на основе системных требований. Для этого необходимо оценить не только стоимость реализации конкретной технологии, но и ее потенциальные достоинства и недостатки, причем должны приниматься во внимание такие факторы, как соответствие технологии общему характеру работы организации, обеспечение безопасности, целостности и восстанавливаемости данных после возникновения отказов в системе, простота реализации системы, требования, предъявляемые к квалификации пользователей. ВыводыБла бла бла бла бла блаа |