Зубрицкая Е.А.
Требования корпоративного доступа к ресурсам и появление локальных вычислительных сетей привели к созданию наиболее многочисленных на сегодня решений на базе технологии "клиент-сервер". Необходимость работы с различными видами неструктурированной бизнес-информации вызвала к жизни внедрение объектной идеологии в реляционные базы независимо от того, достигалось ли это полным переписыванием ядра или интеграцией готовых реляционных и объектных баз данных.
Классическую СУБД в общем случае можно описать как комплекс из инструментария для поддержки таблиц и отношений между связанными таблицами, пользовательского интерфейса для ввода, поиска данных и их представления и высокоуровневых средств разработки приложений. Выделение в этой среде своеобразного исполнительного информационного центра, принимающего короткие запросы от клиентов, отыскивающего оптимальный путь их выполнения и передающего в ответ результирующие множества, приводит к разделению функций СУБД, часть из которых закрепляется за сервером, а часть - за клиентом.
Традиционно на сервер возлагаются обязанности по оперативному исполнению транзакций, поддержке целостности данных, обеспечению безопасности хранения и доступа, обеспечению пользовательских соединений и соблюдению части логики приложения, большей или меньшей в зависимости от самого конкретного приложения. Естественно, самая минимальная часть серверной логики должна обеспечивать проектирование структурной схемы базы вместе с соответствующими ограничениями. На стороне клиента остаются другая часть бизнес-логики приложения и пользовательский интерфейс.
Предполагается, что существует определенная база данных, к которой необходимо обеспечить доступ определенному кругу пользователей по сети. Для того, чтобы сделать доступным какой-либо объект, находящийся на компьютере подключенному к сети, необходимо чтобы на ресурсе который выполняет роль Сервера, обеспечивался централизованный организованный способ предоставления доступа к сервисам и ресурсам к которым относиться и доступ к хранилищу данных - базе данных.
В частности, этот доступ можно предоставить, используя какой-либо из программных средств именуемых, как HTTP-сервер (Web-сервер). При выборе веб-сервера, необходимо отталкиваться от того на какой платформе он будет работать.
Из существующих СУБД можно отметить MySQL. На сегодняшний день СУБД MySQL является одной из самых известных, надежных и быстрых из всего семейства существующих СУБД. Одной из причин являются правила ее распространения - за нее не надо платить деньги и распространяется она вместе со своими исходными текстами. Сегодня MySQL получила распространена на платформах Linux и Windows. Причем на последней встречается гораздо реже.
Существует ряд технологий предоставляющих доступ (connectivity) к источникам данных из приложений СУБД. На заре эпохи баз данных разработчикам достаточно было знать только те базы данных, которые они использовали. Но базы данных и их технологии развивались довольно быстро - от реляционных баз данных к нереляционным информационным хранилищам, таким, как электронная почта и файловые системы. С появлением клиент-серверных и многоуровневых архитектур разработчикам уже приходится разбираться во всем многообразии технологий баз данных. Большинство разработчиков потратили годы на изучение ODBC, DAO, RDO, OLE DB, ADO и RDS. К настоящему моменту Microsoft представила .NET Framework и вместе с ней новую технологию баз данных ADO.NET.
Как только мы начинаем углубляться в какую-то новую технологию, мы забываем, как она развивалась, и что рационального за ней стоит. Проследив развитие технологий баз данных от ODBC до ADO.NET, проще выбрать подходящую технологию и оптимизировать ее для своих целей.
Завоевала популярность у разработчиков, благодаря универсальности - базовый набор интерфейсов OLE DB имеется в каждой современной операционной системе Microsoft. Поэтому для обеспечения доступа приложения к данным достаточно лишь правильно указать провайдер соединения ADO и затем переносить программу на любой компьютер, где имеется требуемая база данных и, конечно, установленная ADO. Технология ADO и интерфейсы OLE DB обеспечивают для приложений единый способ доступа к источникам данных различных типов. Например, приложение, использующее ADO, может применять одинаково сложные операции и к данным, хранящимся на корпоративном сервере SQL, и к электронным таблицам, и локальным СУБД. Запрос SQL, направленный любому источнику данных через ADO, будет выполнен.
Обеспечивает общий интерфейс для доступа к разнородным базам данных стандарта SQL. ODBC использует язык SQL как стандарт для доступа к данным. Этот интерфейс очень удобен: одно приложение может обращаться к различным базам данных SQL через общий набор команд. Таким образом, разработчик может создавать и распространять приложения, не привязываясь к конкретной базе данных.
ODBC использует низкоуровневый интерфейс, поэтому программисты на С и С++ реально задействуют все преимущества технологии ODBC. Программисты на Visual Basic (VB) не имеют простого доступа к интерфейсу ODBC. До появления VB 6.0 разработчики применяли высокоуровневый доступ к данным. DAO базируется на технологии баз данных Microsoft Jet - процессоре баз данных, предназначенном для Microsoft Access. JET был первым объектно-ориентированным интерфейсом для связи с Access. Приложения, использующие Access, могут задействовать DAO для прямого доступа к данным. Поскольку DAO создавалась сразу же вслед за Access, применение этой технологии - самый быстрый и наиболее эффективный способ доступа к базам данных Access. DAO может работать и с отличными от Access базами данных, такими, как SQL Server и Oracle. DAO использует ODBC, но, поскольку метод DAO спроектирован специально для взаимодействия с JET, JET транслирует запросы между DAO и ODBC. Этот дополнительный шаг трансляции и является причиной замедления работы с базами данных, отличными от Access.
Спустя несколько лет ODBC становится стандартом для клиент-серверного доступа к базам данных. ODBC обеспечивает стандартный интерфейс, который требует функций SQL и оптимизирован под методы SQL. Однако что произойдет, если нужно будет обратиться к нереляционной базе данных, в которой не используются принципы SQL (например, Microsoft Exchange Server, хранилище которого не содержит данные реляционно).
Рассмотрим OLE DB. Технология OLE DB построена на ODBC и расширяет ее до компонентной архитектуры, которая обеспечивает высокоуровневый интерфейс доступа к данным. Эта архитектура предоставляет постоянный доступ к SQL-данным, не SQL-данным и неструктурированным источникам данных по локальным сетям и Internet. В действительности для доступа к SQL-данным OLE DB использует ODBC, потому что это самая подходящая архитектура для работы с SQL. OLE DB - это единый API, который обрабатывает как совместимые с SQL источники данных, так и несовместимые, такие, как почта и каталоги.
Когда Microsoft начала разрабатывать .NET Framework, она имела хорошую возможность пересмотреть модель доступа к данным. Решив не продолжать разработку технологии ADO, специалисты Microsoft приступили к созданию новой структуры доступа к данным, при этом сохранив акроним. Microsoft разрабатывает ADO.NET на базе уже зарекомендовавшей себя объектной технологии ADO. Но ADO.NET ориентируется на три важные возможности, которые не поддерживаются ADO: поддержка модели доступа к несвязанным данным, что является ключевым элементом для работы в Web; поддержка тесной интеграции с XML; интеграция с .NET Framework (например, совместимость с базовой библиотекой классов типичной системы).
Visual Studio .NET содержит два поставщика данных .NET. Поставщик данных SQL Server .NET обеспечивает связь с SQL Server 7.0 и более поздними версиями. Этот метод доступа наиболее эффективен для SQL Server 7.0 и выше, потому что поставщик данных SQL Server .NET связывается напрямую с SQL Server через протокол Tabular Data Stream (TDS). Поставщик данных OLE DB .NET необходим для соединения с отличными от SQL Server базами данных, такими, как Oracle или IBM DB2. Этот поставщик данных использует OLE DB для соответствующих баз данных.
Хотя в ADO.NET реализовано много новых возможностей, можно продолжать применять ADO. При разработке нового приложения на .NET следует отдать предпочтение ADO.NET. Но если процесс разработки продолжается, можно оставить ADO в старых проектах и использовать ADO.NET в новых. .NET Framework позволяет задействовать ADO в .NET приложениях через COM, который поддерживает обратную совместимость без необходимости модифицировать ADO.
В заключение хочу добавить, что технологии доступа к базам данных постоянно развиваются. Пока осваивается одна технология, уже появляется другая. Только одно остается неизменным: базы данных играют все более важную роль при разработке приложений. Знание новейших технологий и эволюционных изменений, которые они вызывают, поможет найти оптимальную технологию для текущей задачи и сделать обоснованный выбор в случае необходимых изменений.
Использованные материалы: