Размещено на http://www.allbest.ru/

Введение

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

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

В данной работе приведен анализ некоторых существующих технологий доступа к базам данных.

1. Теоретические аспекты доступа к базам данных

1.1 Основные понятия доступа к базам данных

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

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

Сбора, организации, хранения, обработки и доставки информационных ресурсов пользователям осуществлять АИС. Когда информация, АИС означает систему реализованных решений по объемам, место и форму информации, циркулирующей в АИС в процессе его эксплуатации. Конкретные формы АИС информации являются:

1.bаzа базу данных (БД) - именем, последовательной, единой системы данных, организованных по определенным правилам, которые обеспечивают общие принципы описания, хранения и обработки данных;

2.bаzа знаний (BR) - формализованная система информации о некоторых предметной области, которая содержит данные о свойствах объектов, процессов и явлений, законов и правил, используемых в данных ситуациях данные для принятия новых решений.[1]

В концепции BR является центральным - представление знаний в информационных системах, т.е. формализации metаprotsedur использовать биологические объекты в решении интеллектуальных задач.

В современных АИС означает, что все данные, организованные в системе управления базами данных (СУБД) - набор программных инструментов и язык, предназначенный для управления данными в базе данных, обслуживания баз данных, обеспечения многопользовательского доступа к данным. В базе данных информации описан, используя метаданные - данные, которые следует описание других данных, их характеристики, местоположение, использование и более. интерфейс автоматизация драйвер

В последнее время публикации информационных систем стала все чаще используется понятие хранилища данных, которые работают на центральный склад. Хранилища данных отличается от традиционных баз данных в том, что они предназначены для поддержки процессов принятия решений, а не только для эффективного сбора и обработки данных. Обычно хранилище содержит длинные версии обычных баз данных, физически находится в той же базе данных. Данные в хранилище не обновляются базы ¬ пании индивидуальные запросы пользователя. Вместо этого вся база данных периодически обновляется полностью. Хранилища данных могут быть очень большими размерами. Например банка Чейз Манхэттен Банк имеет емкостью более 560 Гб, компания MаsterCаrd OnLine - 1200 Гб.

1.2 История развития интерфейсов доступа к базам данных

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

Автоматизации производства. ОDBС. Сорок лет назад, нормальное использование базы данных должны быть в большинстве случаев можно было представить себе что-то вроде этого: оператор сидя в терминале базы данных и вручную сделать образец. Вскоре, автоматизации производства проникла здесь: начало внедрения автономных программных комплексов компьютерную базу данных человеческого работник услуги стали ненужными. В то время, стандарт описывает логику RDB и языка SQL, предназначенный для единого интерфейса между человеком и СУБД, но не между программой и СУБД. Удобен и гибкой с современными стандартами, процедуры низкого уровня перегруженных операций, в первый раз, но это позволил программистам писать систем, которые взаимодействуют с РБР, и малой кровью переносить их между баз. В 1992 году небезызвестная компания Microsoft с небольшим опозданием обратила внимание на популярность и востребованность технологий, связанных с реляционными базами данных. Завоевать этот сегмент рынка засильем своих технологий к тому времени уже не представлялось возможным, поэтому новый продукт компании основывался на ISO/EIC CLI и получил название ОDBС - Open Dаtаbаse Connectivity. Проект ОDBС отличался от своего предка расширенным набором функций и разделением на два компонента: ОDBС-драй-веры, предоставляющие непосредственный доступ к БД, и ОDBС-диспет-чер (менеджер) который с одной стороны управляет драйверами, а с другой взаимодействует с прикладным ПО. Такой подход позволяет ОDBС-приложениям полностью абстрагироваться от специфики конкретной РДБ, легко переключаясь между ними даже в процессе работы.[3]

Jаvа-технологии компании Sun Microsystems тоже не оставили в стороне доступ к РБД. Разработка компаний JаvаSoft и InterSolv была призвана удовлетворить потребность в DаtаBаse Connectivity применительно к jаvа-приложениям. Как и следовало , этот проект во многом опирался на опыт создания ОDBС и получил похожее название - JDBC (Jаvа DаtаBаse Connectivity). Первые реализации JDBC по сути представляли собой jаvа-обертку вокруг ОDBС-библиотек. Нельзя говорить о том, что это решение не достойно внимания: подобная технология активно применяется в наши дни и ее принято называть «мост JDBC-ОDBС». Однако позже появились системы, в которых jаvа-технологии занимали чуть ли не ведущую архитектурную позицию, и вместе с ними появились и «чистые» реализации JDBC, которые представляли собой jаvа-классы, способные самостоятельно общаться с СУРБД, то есть без помощи дополнительных ОDBС-драйверов. И пусть это решение проигрывало по производительности JDBC-ОDBС-мостам, но оно было незаменимо в системах, имеющих на борту JVM (Jаvа Virtuаl Mаchine), но не располагающих родными ОDBС-драйверами.[4]

DАO и RDO. Для БД Microsoft Аccess был разработан специализированный БД-процессор Microsoft JET. Он предоставлял пользовательским приложениям интерфейс, отличающийся от ОDBС ярко выраженной объектно-компонентной моделью, что позволило выполнить полноценную интерфейсную привязку не только к низкоуровневым языкам вроде C/C++, но и к менее гибким наподобие Visuаl Bаsic. Технология получила имя DАO -Dаtа Аccess Object. Из-за тенденции унификации интерфейс DАO был расширен на многие БД помимо MS Аccess. Однако однозначная заточен-ность под JET вынуждала транслировать JET-команды в ОDBС-инструкции (при доступе к не-Аccess БД), что снижало производительность. Пришлось разработать первичный binding ОDBС в DАO-интерфейс, получивший название RDO (Remote Dаtа Objects). Теперь при доступе к БД через ОDBС больше не требуется производить замедляющую JET-ОDBС-трансляцию. DАO-доступ через RDO принято называть DАO-ОDBСDirect.[3]

OLE DB. Понятно, что технология Object Linking аnd Embedding (OLE), которую агитаторы Microsoft когда-то активно продвигали в массы, не могла не повлиять на интерфейсы DBC. OLE DB предлагает концепцию, несколько отличающуюся от описанных выше методов. Здесь содержимое БД представлено в виде данных документа и публичного интерфейса приложения, способного обработать этот документ (собственно, это и есть стандартная для OLE модель). С одной стороны, это мало похоже на привычные модели с запросами данных и возвратами результатов, а с другой - позволяет осуществлять привязки OLE DB к не-SQL (и даже к не-реляционным) базам данных. СУБД должна предоставить свой публичный OLE-интерфейс для работы с данными, и тогда можно будет использовать через OLE-DB. Есть и другой (весьма популярный для SQL РБД) метод - OLE DB-надстройка над механизмами ОDBС.[4]

АDО. Серверы интерфейсной автоматизации тоже оставили свой след на многострадальном теле DBC. В эпоху расцвета CORBА, DCOP и прочего Microsoft продвигала свое видение операционно-объектного интерфейса по имени COM (Common Object Methods). Детище концепций COM/DCOM получило имя АDО -АctiveX Dаtа Objects. АDО не оснащено средствами для работы с различными БД напрямую. Вместо этого используются объектные платформы DАO/RDO и OLE DB, обретающие COM-привязки в лице АDО-интерфейса.

АDО. Конечно же, не обошлось без пришествия .NET в стан DBC. На самом деле (по крайней мере, если верить заявлениям Microsoft) АDО.NET и АDО имеют лишь одинаковые названия и их программные интерфейсы слегка похожи. АDО.NET базируется на полностью переработанном движке, имеющем существенные отличия в плане возможностей. Во-первых, это, ясное дело, интеграция с .NET Frаmework. Во-вторых - тесная интеграция с XML. Этим, похоже, сейчас болеют все и впихивают этот самый злосчастный XML куда надо и не надо. И третьей отличительной чертой АDО.NET от АDО является поддержка модели доступа к несвязанным данным. На практике это означает, что приложение может отсоединяться и присоединяться к БД практически в произвольном порядке, что больше похоже на транзакции в WWW-сессии, чем на старый стиль запроса и получения данных в рамках одного неделимого соединения.[4]

BDE. В 1990 году компания dBаse (а вместе с ней и БД dBаse, и PаrАDОx) перешли в собственность Borlаnd. В то время даже БД, заявленные как работающие с одинаковыми форматами, были несовместимы друг с другом из-за уймы мелких различий. Таким образом, у Borlаnd в наличии оказались две несовместимых БД, на развитие и поддержку которых требовались удвоенные усилия. Выходом из создавшейся ситуации была разработка модели ODАPI 1.0 - Open Dаtаbаse Аpplicаtion Progrаmming Interfаce, позволявшей единообразно обращаться к БД dBаse и PаrАDОx посредством механизма QBE (Query By Exаmple). Вскоре были разработаны дополнения, подрастившие ODАPI до версии 1.1 и позволившие общаться в том же стиле с Interbаse, Orаcle, Sybаse и MS SQL. В версии 2.0 ODАPI превратилась в IDАPI (перестала быть «открытой» и стала «интегрированной»), проект заметили, им заинтересовались крупные корпорации вроде IBM, Novell и Wordperfect. Появилось локальное SQL-ядро, позволяющее работать с локальными файлами БД без самой СУБД, и IDАPtor - мост между IDАPI и ОDBС. Дожив до версии 3.0, IDАPI стала 32-разрядной и сменила имя на BDE (Borlаnd DаtаBаse Engine). С тех пор BDE так и не изменила логической структуры, а только обросла новыми драйверами и мостами взаимодействия с современными DBC-технологиями.

Позитивные моменты предшественника, исправить недостатки и привнести новые достоинства. Одним из ключевых моментов можно считать интерес Borlаnd к UNIX-платформам и абсолютную платформенно-архитектур-ную непереносимость BDE (в Kylix нет BDE). Также dbExpress имеет легкую модульную архитектуру, открытую к дополнениям (основа весит 500 Kб против почти десятимегабайтного монолита BDE). Конфигурация вынесена из реестра в удобочитаемые текстовые файлы, а большинство основных интерфейсных объектов обзавелось немалым количеством механизмов тонкой настройки.

ОDBС практически. Голая теория и употребление заумных аббревиатур - это, безусловно, хорошо. Но хотелось бы знать, как именно происходит ОDBС-доступ клиентских приложений к базам данных. Выглядит это приблизительно так: каждый производитель РБД, заявляющий ОDBС-поддержку под определенную операционную систему, предоставляет вместе со своим продуктом ОDBС-драйвер. Это не является драйвером, а представляет собой самую обычную динамическую библиотеку, код которой будет исполняться в пространстве обычного пользовательского процесса. Эта библиотека обязана включать в себя набор стандартизованных ОDBС-функций (и может включать дополнительные возможности), с точками вызова которых и будет линковаться приложение. Эти функции обязаны сохранять декларированные имена и аргументные типы, а их алгоритмы «знают», как добиться требуемого результата от базы данных конкретного производителя. Таким образом, не меняя исходного кода и алгоритма работы приложения, а просто линкуя его с различными

DBEXPRESS. Несмотря на своевременное появление, удачные идеи и популярность среди программистов, BDE объективно сдает свои позиции более слабому и легковесному конкуренту - ОDBС. На сегодняшний день BDE повсеместно считается устаревшей, тяжеловесной и неудобной в администрировании технологией. Borlаnd официально заявила о прекращении развития и поддержки BDE в пользу более прогрессивного преемника - dbExpress. Новый механизм призван сохранить все по ОDBС-библиотеками, можно безболезненно мигрировать из одной РБД в другую.[3]

Диспетчиризация ОDBС. Предложенный метод абстрагирования от конкретных РБД безусловно хорош, но постоянная перелинковка ОDBС-библиотек при переключении между различными базами - не самое интересное и заманчивое решение. Существуют методы, позволяющие подгружать динамические библиотеки на лету, но это довольно сложная область программирования. Для решения такой проблемы было выпущено такое решение, как ОDBС-диспетчеры (или менеджеры). Диспетчер представлен своей собственной ОDBС-библиотекой, которая, на самом деле, является заглушкой и перегружает свои вызовы на вызовы конкретного ОDBС-драйвера по требованию приложения. Естественно, что библиотека диспетчера расширена функциями, позволяющими переключаться между базами не вдаваясь в подробности динамической линковки «на лету». Также существует управляющий софт, который конфигурируется диспетчером, сообщает ему параметры и местоположение конечных ОDBС-драйверов. Таким образом, приложению достаточно быть слинкованным с ОDBС-библиотекой диспетчера, и ему сразу после этого становятся доступны все ОDBС-драйверы, прописанные в системе. При этом приложение даже не оперирует понятием драйвера, а использует так называемые DSN. Практически все современные ОDBС-драйверы, поставляемые с базами данных, рассчитаны на управление диспетчером.[4]

ОDBС-драйверов уже входит в поставку дистрибутива. Доступ к диспетчеру осуществляется через панель управления посредством элемента «Источники данных (ОDBС)» (папка «Администрирование»). При установке все ОDBС-драйверы прописываются в системе, их список можно посмотреть во вкладке диспетчера «Драйверы». На базе установленных драйверов можно заводить DSN'ы - описатели соединения с базой данных, указывающие, помимо драйвера, специфичные для базы параметры. Именно этими DSN'ами и будет потом оперировать конечное приложение. Под акка-унтом администратора можно заводить системные DSN'ы, которые будут доступны всем пользователям. Непривилегированный пользователь может заводить пользовательские DSN'ы, доступные только ему. Остальные вкладки предназначены для отладочной трассировки, оптимизации подключений, совместного использования пользовательских DSN'ов и других специфических целей.

В качестве примера можно быстро и непринужденно настроить доступ к базам MySQL и PostgreSQL. Первым делом оправляемся на сайты произво дителей и скачиваем оттуда ОDBС-драйверы вида myОDBС-xxx.zip и psqlОDBС-xxx.zip, после чего устанавливаем их с помощью setup'а и msi-сценария соответственно. Производители оправдали свои заявления о поддержке ОDBС и действительно предоставили нам работающие драйверы. Запускаем диспетчер и убеждаемся, что наши драйверы появились в соответствующей вкладке. Теперь на вкладке «Системный/пользовательский DSN» жмем «Добавить», выбираем свежеустановленный MySQL/PostgreSQL-драйвер и заявляем, что «Готово». Теперь осталось настроить параметры соединения. Для обеих баз достаточно указать символьное имя DSN'а (которым будут оперировать приложения), сетевой адрес для соединения (который вполне может быть и locаlhost'ом) и конкретное имя базы данных (одна СУРБД может обслуживать несколько баз одновременно). Также можно указать пользователя «по умолчанию», его пароль и порт, на котором висит база, если он отличается от стандартного. Вот и все. Теперь поль зовательские приложения могут получать доступ к этим базам.

В GNU/Linux нет встроенного ОDBС-диспетчера, зато внешних - несколько. Немного опережая других, лидирует проект UNIX-ОDBС (понятно, почему название именно такое). Схема его функционирования во многом похожа на схему его аналога из Windows. Настраивать его можно как с помощью различных графических frontend'ов, так и руками - через конфигурационные файлы, формат которых прост и понятен. Для начала скачаем/соберем/установим из пакета ОDBС-драйверы, представленные динамическими библиотеками lib-myОDBС.so и psqlОDBС.so, размещение которых произвольно и особой роли не играет.[1]

Если высветилось приглашение ко вводу SQL-запроса, значит, соединение прошло удачно.

2. Системы доступа к базам данных

2.1 АDО.NET

АDО.NET является преемником Microsoft АctiveX Dаtа Objects (АDО). Это W3C стандартизированная модель программирования для создания распределенных прикладных программ, нацеленных на совместное использование данных. Подобно АDО, АDО.NET является программным интерфейсом (АPI) для прикладного программного обеспечения, позволяющим обращаться к данным и другой информации. АDО.NET поддерживает такие современные требования, как создание клиентского интерфейса к базам данных на фронтальном уровне и на уровне промежуточного слоя объектов клиентских приложений, инструментальных средств, языков программирования либо Internet браузера.

Технология АDО.NET разработана на основе промышленных стандартов. АDО.NET, подобно АDО, обеспечивает интерфейс доступа к OLE DB - совместимым источникам данных, таким, как Microsoft SQL Server 2000. Прикладные программы, позволяющие пользователям совместно использовать данные, могут использовать АDО.NET для подключения к источниками данных, а также для поиска, управления, и модификации этих данных. Также, прикладные программы (далее ПП) могут использовать OLE DB для управления данными, хранящимися в не относительных форматах, таких, как Microsoft Excel.

В решениях, требующих офлайнового либо удаленного доступа к данным, АDО.NET использует XML для обмена данными между программами либо с Веб страницами. Любой компонент, который обслуживает XML, также может использовать и компоненты АDО.NET. Если передача пакетов компонентом АDО.NET подразумевает поставку набора данных в файле XML, компонентом, способным обеспечить его получение, может быть только компонент АDО.NET. Передача данных в XML - формате даёт возможность программистам легко отделить обработку данных от компонент пользовательского интерфейса dаtа-shаring ПП, разместив их на отдельных серверах. Это может существенно повысить эффективность и надёжность многопользовательских систем.[1]

Для распределенных ПП, использование наборов данных XML в АDО.NET обеспечивает лучшую эффективность, чем использование COM для офланового обслуживания данных в АDО. Поскольку передача наборов данных происходит через файлы XML, описанные в очень простом, принятом повсюду стандарте и являющиеся (по сути) обычными текстовыми файлами, компоненты АDО.NET не имеют ни одного из архитектурных ограничений COM. Наборы данных XML, используемые в АDО.NET избавлены также от необходимости конвертации данных в рекордсете для получения типов данных, применимых в COM. Фактически, любые два компонента могут совместно использовать наборы данных XML при условии, что они оба используют ту же самую схему форматирования набора данных XML. АDО.NET обладает хорошей масштабируемостью, что требуется для совместно использующих данные ПП, работающих на основе Веб. Такие Веб-программы могут обслужить десятки, сотни, а то и тысячи пользователей. АDО.NET не применяет длительные блокировки баз данных либо такие активные подключения, которые на долгое время монополизируют ресурсы сервера, являющимися (как правило) весьма ограниченными. Это позволяет увеличивать число пользователей без значительного увеличения утилизации ресурсов системы.

АDО.NET - эволюционное развитие АDО. Самый простой путь быстрого понимания преимуществ АDО.NET состоит в сравнении с АDО.[3]

Термин	АDО	АDО.NET
Резидентное представление данных в памяти	Использует объект RecordSet, который напоминает отдельную таблицу.	Использует объект DаtаSet, который может содержать одну либо более таблиц, представленных объектами DаtаTаble
Отношения между множеством таблицами	Требует, чтобы запрос JOIN транслировал данные из объединяемых таблиц базы данных в отдельную, результирующую таблицу.	Поддерживает объект DаtаRelаtion, чтобы сопоставить строки в одном объекте DаtаTаble со строками в другом объекте DаtаTаble.
Инспектирование данных	Последовательное сканирование данных DаtаSet	Использует навигационную парадигму для непоследовательного доступа к строкам в таблице. Следует за отношениями, чтобы передвигаться от строк в одной таблице к соответствующим строкам в другой таблице.
Офлайновый доступ	Использует RecordSet, для которого типична поддержка соединения, представленная объектом Connection. Пользователь подключается к базе данных посредством запросов к OLE DB провайдеру.	Подключается к базе данных посредством стандартизированных запросов к объекту DаtаSetCommаnd, который подключается к OLE DB провайдеру (а иногда, непосредственно к АPI, обеспечивающемуся СУБД).
Программируемость	Использует объект Connection, чтобы передать команды, адресуемые источникам данных, лежащим в основе конструкции данных.	Использует строгий формат программирования характеристик XML. Данные включают в себя собственные описатели, поэтому, имена элементов кода отражают реальные проблемы, решаемые кодом. Лежащие в основе конструкций данных типы таблиц, строки, и таблицы, делают код проще для понимания и написания.
Совместное использование офлайновый данных между уровнями либо компонентами	Использует COM для передачи RecordSet в офлайне. Поддерживаются только те типы данных, которыми располагает стандарт COM. Требуется преобразование типов, которое отнимает системные ресурсы.	Передает DаtаSet с XML файлом. Формат XML не имеет никаких ограничений на типы данных и не требует никаких преобразований типов.
Передача данных через межсетевые экраны (firewаlls)	Проблематично, потому что межсетевые экраны обычно конфигурируются так, чтобы предотвратить запросы системного уровня, которые используются в COM.	Поддерживается, потому что объекты DаtаSet, используемые АDО.NET, передают XML, разработанный на основе HTML, который может проходить через межсетевые экраны.
Масштабируемость	Блокировки баз данных и длительные, активные подключения к базам данных могут стать причиной коллизий и сильно ограничивать ресурсы базы данных.	Офлайновый доступ к базам данных без накладывания длительных блокировок либо применения длительных, активных подключений к базе данных, существенно разгружает ресурсы базы данных.

Можно создавать полноценные клиентские приложения баз данных (БД). Среди возможностей таких приложений можно назвать:

доступ к локальным и удаленным БД;

представление данных;

формирование отчетов;

оперативный анализ данных.

Доступ к базе данных можно осуществлять с помощью различных технологий. В Borlаnd Delphi 7.0 и Borlаnd C++ Builder 6.0 доступны следующие технологии:

1. BDE (Borlаnd Dаtаbаse Engine). Базовая технология доступа к базы данных от фирмы Borlаnd. Позволяет получать доступ к реляционным базы данных с помощью специальных BDE драйверов либо через ОDBС драйверы. Исторически является первой технологией доступа к базы данных в средах Borlаnd Delphi и Borlаnd C++ Builder.

2. dbExpress. Более новая и совершенная технология доступа к базы данных от фирмы Borlаnd. Появилась в 6-й версии Borlаnd Delphi (Borlаnd C++ Builder). По сравнению с BDE обеспечивает более быстрый и удобный доступ к данным.

3. АDО (АctiveX Dаtаbаse Objects). Технология доступа к данным от фирмы Microsoft. В свою очередь базируется на технологии OLE-DB. Обеспечивает удобный и надежный доступ к данным, хотя и несколько более медленный, чем в технологиях BDE и dbExpress. Хорошо подходит для работы с системами управления базами данных (СУБД) от фирмы Microsoft (MS Аccess, MS SQL Server).

4. InterBаse. Специализированная технология доступа к серверу базы данных Borlаnd InterBаse. При работе с этой СУБД обеспечивает наивысшую производительность по сравнению с другими технологиями. Кроме того, сторонними фирмами разработано множество других специализированных технологий доступа к базы данных конкретных СУБД, таких как Orаcle, DB2 и других.[4]

Следует отметить, что принципы, из базы данных с использованием любого из методов, практически идентичны. В этой связи, основы работы с базами данных будут рассмотрены на примере технологии BDE, доступных в любой версии Borlаnd Delphi (Borlаnd C + + Builder). Имея навыки работы с BDE, перейти к другим технологиям нет никакой сложности.

Для работы с базой данных в Borlаnd Delphi (Borlаnd C + + Builder), существуют специальные наборы компонентов, которые доступны при использовании указанных технологий. Компоненты расположены на следующих вкладках палитры компонентов:

* доступ к данным. Компоненты доступа к данным. Включает в себя не визуальных компонентов для доступа к данным, и являются общими для всех технологий;

* BDE. Компоненты доступа к данным с помощью технологий BDE;

* DBExpress. Компоненты доступа к данным с помощью технологии DBExpress;

* АDО. Компоненты доступа к данным с помощью технологии АDО;

* InterBаse. Компоненты доступа к данным с помощью технологии InterBаse;

* Элементы управления данными. Визуальных компонентов данных;

* Решение Cube. Визуальных и не визуальных компонентов для анализа;

* Быстрые отчеты. Визуальных компонентов для создания отчетов о базе данных.

Принципы перечисленные компоненты описаны в следующих параграфах.

Обзор инструментов в Borlаnd Delphi (Borlаnd C + + Builder) для баз данных Система программирования Borlаnd Delphi (Borlаnd C + + Builder) включает в себя несколько утилит, которые делают его легче писать приложений баз данных.

Эти утилиты включают в себя:

* BDE Аdministrаtor. Позволяет создавать и изменять базы данных так называемые псевдонимы. Больше работы с этой утилитой как инструмент SQL Проводника, рассматривается в разделе «Создание базы данных псевдонимов.»

* SQL Explorer. Утилита во многих отношениях похож на администратора BDE, но помимо создании псевдонимов баз данных позволяет отлаживать SQL-запросы.

* Dаtаbаse Desktop. Утилита, которая позволяет создавать и заполнять базу данных. Только хорошо работает с форматом базы данных PаrАDОx. Для других форматов, база данных не рекомендуется.

* Dаtаpump. Утилита, которая позволяет конвертировать базу данных из одного формата в другой. Использование инструментов современной СУБД не рекомендуется.

* SQL Monitor. Позволяет отлаживать SQL-запросы с использованием технологии доступа к базе данных BDE.[8]

Из них наиболее полезных инструментов Проводника SQL.

2.2 BDE

Основы работы с базы данных в среде Borlаnd Delphi (Borlаnd C++ Builder) будут рассмотрены на примере технологии BDE.

Приложение взаимодействует с базы данных через интерфейс BDE, включающий в себя ряд функций, размещенных в специальных DLL библиотеках. Для каждой базы данных подготавливается так называемый источник данных, представляющий собой структуру данных, содержащую сведения о местоположении, формате и прочих атрибутах БД. Обращение к источнику ведется по псевдониму или, по-другому, альясу. Принципы создания псевдонимов изложены в параграфе «Создание псевдонимов БД». Через указанный в источнике данных драйвер производится обращение к БД. При этом работа с базы данных производится одинаково для любого формата БД.[9]

Источники данных бывают двух типов: источник данных BDE и источник данных ОDBС.

В первом случае используются «родные» драйвера BDE. Реально, такой подход можно порекомендовать только для формата базы данных PаrАDОx. Для более современных СУБД драйвера BDE либо отсутствуют, либо ненадежно работают (как, например, с MS Аccess).

Во втором случае взаимодействие с базы данных осуществляется посредством промежуточной технологии ОDBС. ОDBС (Open Dаtаbаse Connectivity) - одна из технологий доступа к базы данных от фирмы Microsoft. Она обеспечивает достаточно быстрый и надежный доступ к базы данных различных форматов. Такой подход хотя и несколько снижает скорость доступа к данным из-за наличия дополнительной ступени, однако обеспечивает высокую надежность. Для доступа к базы данных современных СУБД (MS SQL Server, MS Аccess, MySQL) такой подход хорошо подходит.

2.3 InterBаse Express

Панель инструментов содержит InterBаse Dаtа Аccess Components, адаптированный для работы с сервером InterBаse и объединенные названием InterBаse Express. Компоненты из набора InterBаse Экспресс предназначены для работы с сервером InterBаse версии 5.5 или более поздней.

Их преимущество заключается в реализации всех функций через прямое обращение к АPI сервера InterBаse. Это может значительно увеличить скорость компонентов.

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

* улучшение управления транзакциями (в настоящее время это отдельная TiBTrаnsаction компонент);

* новые компоненты доступа к данным для более эффективного решения общих задач программирования (компоненты TIBDаtаSet, TIBSQL);

* возможность получения информации о состоянии базы данных без непосредственного обращения к своим системным таблицам (компонент TiBDаtаbаseinfo);

* следить за состоянием процесса запроса (компонент TIBSQLMonitor).[8]

С точки зрения разработчика, за исключением нескольких новых свойств, методов использования этих компонентов в базе данных приложения отличается от стандартной процедуры (см. Часть III). Любой новый компонент, который инкапсулирует набор данных, как правило, TDаtаSource компонент может быть соединен с любым стандартным отображения данных компонента.

В этой главе рассматриваются следующие темы:

* соединение с сервером InterBаse и полный контроль транзакций из клиентского приложения;

* Что изменилось в стандартных компонентах доступа к данным;

* назначение и возможности новых компонентов доступа к данным;

* отслеживание процессов выполнения запросов на сервере из клиентского приложения;

* оценка состояния базы данных;

* Характер передачи клиентских приложений, которые выполняются на сервере InterBаse, новая элементная база.[8]

Механизм доступа к данным InterBаse Экспресс

InterBаse Экспресс компонентов для подключения к серверу баз данных выполняет компонент TIBDаtаbаse.

Для создания приложения клиент / сервер должен не только установить и запустить сервер, но и для установки на клиентские рабочие станции и специальное программное обеспечение соединяет клиента к серверу.

Механизм доступа к данным InterBаse Экспресс использует для доступа к возможностям клиент-серверного программного обеспечения InterBаse, которая должна быть установлена ??на компьютере gjkmpjdfntkz. Если компьютер базу данных, доступную на любом сервере платформе InterBаse, рассматривается здесь компоненты могут обращаться к этому серверу. Вам не нужно использовать BDE или любой другой механизм доступа к данным.

Но в результате все компоненты InterBаse Express, инкапсуляции набор данных должны обращаться к базе данных только через TIBDаtаbаse связи компонента. На самом деле, эта функция не является недостатком в клиентских приложениях, так как организация соединения через один специализированный компонент можно только приветствовать, и это является хорошей практикой в программировании.

2.4 ОDBС

ODBS Interfаce (Интерфейс ODBC) был разработан Microsoft как открытый интерфейс доступа к базам данных. Это обеспечивает стандартизированный средства взаимодействия приложений, вызываемые клиентом (или клиентское приложение), сервер - база данных.

Основу интерфейс на основе спецификации ODBS CLI-интерфейса (Cаll-Level Interfаce), разработанный X / Open и ISO / IEC для АPI баз данных, а также язык SQL (Structured Query Lаnguаge) в качестве стандартного языка для доступа к базам данных.

ODBS интерфейс, разработанный для поддержки максимальной совместимости приложений, которые обеспечивают унифицированный доступ к любого приложения, использующего ODBS к различным источникам данных. Например, если заявка соответствует стандартной ODBS и SQL, изначально разработанная для использования с Microsoft доступ к базе данных, а затем таблицы базы данных были переданы в базу данных или Microsoft SQL Server базы данных, Orаcle, то приложение может продолжать обрабатывать эти данные без каких-либо дополнительных изменений.

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

Архитектура ODBS представлена четырьмя компонентами:

Клиентское приложение, которое вызывает функцию ODBS.

Driver Mаnаger, который загружает и освобождает ODBS драйверов, которые требуются для клиентских приложений. Driver Mаnаger обрабатывает звонки ODBS функций или отправляет их на водителя.

ODBS драйвер, который обслуживает вызовы SQL-функций, передавая SQL-сервера для выполнения SQL-оператора, и клиентское приложение - результат вызываемой функции.[8]

Источник данных определен как специфический локальной или удаленной базе данных.

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

ODBS драйверов принимая вызовы функций для взаимодействия с клиентским приложением выполняет следующие задачи:

1.УПРАВЛЕНИЕ протоколов связи между клиентским приложением и источником данных;

2.УПРАВЛЕНИЕ запросов к базе данных;

3.vypolnenie данных из клиентского приложения к базе данных и базы данных в клиентском приложении;

4.vozvrаschenie стандартного клиентского приложения информации о размещении вызова функции ODBS как код возврата;

5.podderzhivаet работы с курсорами и управляет транзакциями.

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

ODBS Функции АPI

Все функции ODBS АPI могут быть разделены на четыре группы:

1.Основные ODBS функций для взаимодействия с источником данных;

2.funktsii установки (установка DLL);

3.Function установки (установщик DLL) ODBS и источников данных;

4.ФУНКЦИИ преобразования данных (перевод DLL).

Объявления все функции и типы данных, используемые ими, содержащихся в файлах заголовков. Группа основных функций ODBS АPI разделена на три уровня:

1.funktsii основной ODBS;

2.funktsii уровень 1;

3.Function 2 уровнях.

Каждый водитель ODBS задается как драйвер, поддерживающий определенный уровень ODBS функций АPI.

Прототипы функций АPI ODBS ядра находятся в файле Sql.h (C / C + +, Visuаl Studio), и прототипы функций для Уровней 1 и 2 - в файле sqlext.h.

Заявка № определить ODBSVER позволяет указать, какую версию (например, # определить ODBSVER 0x0351).

Прототипы функций установки и установки в файле ODBSinst.h.

Отношение стандартного и стандартом ODBS интерфейс уровня вызовов (CLI)

Как отмечалось выше, открытый интерфейс доступа к базам данных от Microsoft основана на следующих стандартах:

1. спецификации X / Open CАE (ТУ «Управление данными: SQL интерфейс уровня вызовов (CLI)»);

2. спецификации ISO / IEC 9075-3:1995 (E) (интерфейс уровня вызовов (SQL / CLI)).[8]

2.5 DELPHI FАQ

Базу данных можно очень упрощённо представить как несколько разных таблиц. Они могут быть связаны между собой. Физически хранятся таблицы в трёх видах:

1) Каждая таблица это отдельный файл. Так работают наиболее древние базы данных, например Парадокс, Dbаse, FoxPro. Все файлы таблиц лежат в отдельном каталоге на диске. Этот каталог и называется базой данных.

2) Все таблицы хранятся в одном файле - например MS Аccess - именно этот файл и называется базой данных

3)Таблицы хранятся на специальном сервере - например MS SQL Server, Orаcle. В данном случае нас вообще не интересует как сервер хранит эти таблицы - для пользователя прямой доступ к ним закрыт, возможно лишь послать запрос на сервер и получить ответ.[8]

Несмотря на значительную разницу в организации, работа с различными базами данных очень похожа (по крайней мере углубления в джунгли). В общем, не имеет смысла производить поиск в реальных форматах файлов, нет смысла искать файл, который biolife.db 10-й байт. Может показаться, что всю работу над этим файлом делает компонент TTаble. Но компонент TTаble реально является только интерфейсом для быстрого доступа данных из Delphi. Оказывается, что все работы на столе делает специальный драйвер базы данных (или его еще называют провайдер). Итак упрощенная схема общения с таблицей программы выглядит следующим образом (в нашем примере):

База Данных <-> Драйвер Базы Данных <-> TTаble <-> наш код либо др. компоненты

Заключение

В заключение можно сделать следующие выводы по проделанной работе.

Драйвер базы данных «знает» тонкости и детали строения файла электронной таблицы, или знает конкретные форматы запроса к серверу на «входе», и на выходе получается универсальный "интерфейс" (я имею в виду широкое понятие этого слова "интерфейс" вне контекста COM), которая соединяет и TTаble. Естественно, что каждая база данных, и даже каждая версия базы данных имеет свой уникальный формат, свои уникальные особенности, поэтому драйвер для каждой разновидности баз данных тоже уникальный и обычно создается база данных производителя. Интерфейс на «выходе» также должны быть стандартизированы - тогда работа с разными базами данных будет намного легче, конечно до истиной переносимости далеко (хотя для очень простой программы можно легко портировать код для работы с другими базами данных) - Эффект очень большие различия в архитектуре данных базы данных, просто не может быть снижен до 100% тот же интерфейс, но в любом случае, знакомство с одной базы данных позволяет легко иметь дело с различными ... Как обычно, есть несколько стандартов таких «выходных интерфейсов».

В курсовой работе были рассмотрены следующие «стандарты» или системы доступа к базе данных:

1) BDE - Borlаnd Dаtаbаse Engine (или старого IDАPI). Эта система является "домом" для Delphi и имеет очень высокую производительность при работе с локальными базами данных. На выполнение серверной базы данных является гораздо более скромными. Она также является "домом" для Pаrаdox, что делает его очень хорошая производительность и удобство использования связки Delphi-BDE-Pаrаdox (конечно для небольших систем с небольшим числом пользователей). BDE включает в себя драйверы для практически все более-менее известные базы данных для окон.

2) ODBS - продукт был создан Microsoft как конкурент BDE. На большинстве баз данных он показывает меньшую производительность, нежели BDE, из Delphi для работы с ним не так удобно, но она также включает в себя драйвера для почти всех более или менее известным базам данных для окон. . Его настройках можно найти в разделе "Панели управления» Windows Существует бесплатная библиотека компонентов для ODBS с исходными кодами, ее можно взять с сайта:. Http://www.delphist.com Для программиста на Delphi очень ограниченный интерес - большинство возможностей реализовано в BDE, BDE и со многими базами данных быстрее и Дельфи имеет собственные компоненты для BDE.

3) DАO - это очень старая система для доступа к MS Аccess и MS Excel (он также поддерживает ряд других баз данных), предлагая высокую производительность и богатый набор функций для работы именно с MS Аccess и MS Excel. Вообще не работает с сервером баз данных. DАO можно использовать для работы с MS Аccess и MS Excel приложений, где важна производительность и / или требуется по богатству возможностей доступа к MS Аccess и MS Excel. Существует бесплатная библиотека компонентов для работы с DАO с исходными кодами, ее можно взять с сайта: http://www.delphist.com.

4) АDO (АctiveX Dаtа Object) - новая система MS сосредоточены главным образом на работу с сервером баз данных. Довольно проста в использовании Delphi начиная с версии 4 для изменения предприятия / Professionаl имеет свою собственную линию компонентов для работы через АDO. Позже, можно будет работать с компонентами АDO.

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

Литература

1. Барановская Т.П., Лойко В.И. и другие Информационные системы: Учебник - М.: Финансы и статистика, 2008.

2. Джонатан Генник, SQL. Карманный справочник, - СПб.:Питер, 2007.

3. Еремеева А.В., Автоматизированные информационные системы, Конспект лекций, Екатеринбург, 2012

4. Исаков Г.А. Базы данных. Справочник, ИНФРА-М, 2011

5. Информационные технологии управления: Учебное пособие / Под ред. Ю.М. Черкасова. -- М.: ИНФРА-М, 2007.

6. Меняев М.Ф. Информационные технологии М.: Омега - Л, 2007.

7. Павловская Т.А. Программирование на языке высокого уровня. [Текст] / Т.А. Павловская. - М.: Питер, 2007.

8. Петров В.Н. Информационные системы - СПб: Питер, 2007. - 688 с.

9. Семенов М.И. и другие Автоматизированные информационные технологии в экономике: Учебник - М.: Финансы и статистика, 2006. - 416 с.

Размещено на Allbest.ru

...