Это первая статья из серии статей, рассматривающей разработку приложений баз данных в Delphi.
В этом выпуске эксперт по базам данных в Delphi Кэри Дженсен рассматривает базы данных в целом и даёт общее введение в поддержку приложений баз данных в Delphi.
Задам тривиальный вопрос:
Как называлась Delphi во время своего первоначального бета-тестирования
(передрелизом в феврале 1995 года)?
Ответ: Delphi
(возможно, выужее это знаете).
Но почему же команда разработчиков выбрала столь странное название для своего нового, основанного на компонентах, расширения компилятора Pascal и IDE(интегрированной среды разработки)?
Ответ: это связано с базами данных.Delphi - это название города и храма в Греции, куда люди совершали паломничества, чтобы поговорить с оракулом (Oracle) - очевидна связь с Oracle Database Server. И хотя Delphi может работать практически с любой базой данных, про которую только можно думать, речь идёт о том, что она с самого начала разрабатывалась, чтобы быть отличной средой для разработки приложений баз данных.
Хотя разработка баз данных не всегда считалась самой гламурной областью разработки программного обеспечения (так
думают другие, не я - я считаю, разработка баз данных - это вполне гламмурно, честно),
имеется сильный аргумент - базы данных сильно влияют на нашу повседневную жизнь. Почти невозможно провести день, не проведя хотя бы одного действия, включающего в себя работу с базой данных. Чтобы сделать покупку на рынке, зарегистрироваться в отеле, купить билет на самолёт или снять деньги с банковской карты необходимо, чтобы некие данные были получены и, в большинстве случаев, использованы для обеспечения результата, либо для его улучшения в будущем.И вот тут - наша работа. Как разработчики баз данных, мы ответственны за понимание того, откуда данные поступают, где они проходят и как должны быть использованы. Понимание этого помогает нам создавать программы, помогающие людям быть более продуктивными, и улучшать их жизнь.
(1) С самых основ.
Во-первых, я действительно верю в основы.
Я вижу, что чем больше Вы знаете о фундаменте используемых вами инструментов, тем лучше вы сможете их использовать.
Увы, когда мы говорим о столь зрелом продукте, как Delphi, сейчас, в отличие от ранних лет Delphi, основы постепенно забываются.
И здесь есть проблема, в частности потому что рынок Delphi вновь растёт. Мало того, что существует потребность в новых разработчиках Delphi для поддержки существующих проектов, Delphi стала ещё и одним из передовых средств разработки приложений для Windows, и эта конкретная область разработки никуда не девается.
И тут на сцену выходит эта серия статей.
В моем сердце я - разработчик баз данных. Я разворачивал многопользовательские приложения баз данных с 1980-х годов и делаю это в Delphi с момента его появления.
Это позволит мне начать с самых основ. Чтобы упростить понимание описываемого мной материала, я собираюсь начать с краткого обзора баз данных. Ближе к концу статьи я расскажу об основных классах Delphi, связанных с базами данных.
В следующих статьях этой серии я детально расскажу о многих средствах Delphi, ориентированных на базы данных, в том числе ClientDataSet, многоуровневую разработку с использованием DataSnap, облачные вычисления, и многое другое.
Но сейчас, мы начнем с главного вопроса.
(2)Что такое база данных?
База данных - это механизм для хранения и извлечения данных. Вот и всё, на самом деле. В простейшем случае базой данных может быть даже текстовый документ. XML - это текстовый формат, и многие используют его в качестве базы данных.
С другой стороны, приложение базы данных - это гораздо больше. Большинство приложений баз данных участвуют в сборе данных, управляют этими данными и превращают их в информацию (отчёты, диаграммы, действия и т.д.). Правда, эти приложения требуют саму базу данных, но здесь я забегаю вперёд.
В большинстве случаев, данные из базы структурированы - так сказать, организованы. В этой связи текстовые документы часто им проигрывают. В результате разработчики баз данных чаще всего используют иные методы.
Для краткости я упрощу мысль и скажу, что большинство разработчиков Delphi используют три типа баз данных: свои собственные форматы файлов, локальные файловые базы данных и удаленные базы данных на серверах. Да, есть и другие, но в некоторых отношениях это - вариации (или даже комбинации) одного или нескольких из этих типов.
(3) Свои файловые форматы
Базы данных на основе таких структур являются обычно либо простыми текстовыми, либо двоичными файлами.
В большинстве случаев, эти файлы являются высоко организованными. Например, каждый блок данных может быть отделён от других специальным символом (разделителем). Примером такого файла является файл формата CSV (Comma separated values), который является обычным текстовым форматом.
Данные не обязательно должны быть разделены символами-разделителями. В частности, если известно, что каждый элемент данных занимает в файле четыре байта, можно извлекать отдельные значения, анализируя файл и отсчитывая по четыре байта за каждый элемент. Вы также можете сохранить эти данные в файл, записывая каждое значение как 4-хбайтовый блок.
С помощью Delphi некоторые разработчики создают файлы, содержащие последовательности структур, где под структурами я понимаю типы record в Delphi. Эти файлы называются типизированными, так как они являются файлами из типизированных данных Delphi: в данном случае, из данных типа Record.
Это лишь несколько возможных вариантов работы с файлами своего формата. Одним из преимуществ таких структур является то, что их обычно можно считывать и записывать очень быстро. Кроме того, ваши Delphi-приложения, использующие такие файлы, редко используют средства, иные, чем встроенные функции ввода/вывода Delphi. Ещё момент - большинство других типов баз данных работают с использованием внешних файлов, таких как клиентские DLL-библиотеки. На рисунке 1 показана простая диаграмма, которая изображающая взаимодействие приложений Delphi и пользовательских структур данных.
Однако у них есть и недостатки. Во-первых, эти типы баз почти всегда однопользовательские, а это значит, что только одна программа или пользователь может работать с файлами данных в один момент времени.
Конечно, можно разработать механизм, посредством которого два или более приложений
(людей)
смогут совместно и одновременно использовать эти данные, но это весьма сложно и почти никогда не стоит затраченных усилий (притом, что уже существуют хорошие многопользовательские решения).
Во-вторых, эти типы баз данных, как правило, проприетарны. Это означает, что только Ваши приложения смогут прочитать данные. Хотя иногда это может быть и желательно, тем не менее, это - важное ограничение.
Хотя файл-серверные базы данных имеют много преимуществ по сравнению с файлами своего формата, они имеют свои ограничения, особенно по сравнению с имеющими богатый функционал удаленными серверами баз данных.
Приведу только два ограничения: они связаны с доступом по сети и стабильностью базы данных.
Если два или более пользователей должны обмениваться данными с файл-серверной БД, данные должны быть размещены в сетевом каталоге, доступном для всех пользователей.
Пока этим пользователям нужно читать данные, данные должны просто передаваться по сети. Если же большое количество клиентов читают и записывают данные, трафик по всем узлам сети может быть очень большим. На самом деле, это гораздо хуже, чем кажется.
Предположим, если клиентскому приложению нужен определенный набор данных, например, информация о конкретной личности, по сети необходимо передать некоторые данные обо всех людях, чтобы клиентское приложение считывало данные каждого человека в поисках нужного.
Другими словами, если в файл-серверной БД хранятся данные на примерно миллион людей, а ваш клиент ищет одного конкретного человека, вполне вероятно, что по сети будут переданы некоторые сведения обо всём миллионе человек, и это только для одного клиентского приложения
(я говорю "некоторые сведения", так как большинство баз данных используют индексы. Мы обсудим индексы более подробно в следующей статье этой серии).
Подумайте, что произойдёт, когда 12 клиентских приложений на 12 рабочих станциях в одной сети ищут одного человека в базе данных. Я думаю, вы поняли, что я имею в виду.
Что касается стабильности, то в файл-серверных базах данных отсутствует централизованное управление данными. Вследствие этого эти базы склонны к повреждению данных.
В файл-серверной базе данных каждое клиентское приложение может читать и записывать данные, хранящиеся в общедоступных файлах в сети.
Из-за этого любое клиентское приложение в процессе записи данных может создать проблемы (например, при разрыве сетевого подключения), из-за которых база данных может получить повреждения.
Вероятность повреждения увеличивается прямопропорционально числу клиентских приложений, пишущих данные в базу. Даже если лишь один клиент пишет данные в базу, ошибка во время записи может сделать эту базу данных непригодной для использования. (Вот почему резервное копирование ваших данных очень важно. Вы не сможете предсказать, в какой момент вы столкнётесь с такой или похожей проблемой.)
(4) Удалённые сервера баз данных
Удалённый сервер баз данных - это приложение, которое управляет вашей базой данных. Когда вы пишете клиентское приложение, включающее работу с удаленным сервером баз данных, ваше приложение не читает/пишет данные в файлы самостоятельно. Вместо этого оно делает запрос удалённому серверу баз данных. Такая архитектура называется клиент-серверной.
Это распределение функций даёт три основных преимущества. Прежде всего, обработка данных распределена между несколькими компьютерами
(например, рабочая станция, на которой работает клиентское
приложение, и сервер, на котором запущен удалённый сервер баз данных).
В результате, общая вычислительная мощность увеличивается, так как большая часть обработки данных производится на сервере, оптимизированном для выполнения таких задач, а клиентское приложение - это в первую очередь интерфейс пользователя. На рисунке 3 приведена диаграмма, изображающая типичную клиент-серверную архитектуру с участием приложений на Delphi.Вторым преимуществом является большое снижение сетевого трафика. Рассмотрим предыдущий пример, когда клиентское приложение должно найти одного человека в файле с миллионом людей. В клиент-серверном сценарии клиент запрашивает данные конкретного человека у сервера баз данных, который сам ищет нужные данные в базе и, если находит, возвращает клиенту по сети только запрошенные им сведения. Сетевой трафик сокращается почти в миллион раз. Наконец, клиент-серверная архитектура гораздо более стабильна, чем файл-серверные базы данных. Это потому, что удаленный сервер баз данных может записывать любые получаемые от клиента данные в базу специальным образом - а именно, используя транзакции. Например, как только удалённый сервер базы данных получает от клиента корректно сформированный запрос на запись данных, сервер запускает транзакцию
(и если сетевое соединение клиента прервётся во время приёма данных, запрос не будет корректным и, следовательно, будет проигнорирован сервером).
Транзакция на сервере обычно включает в себя следующие процессы: сервер делает своего рода заметку о том, что он хочет записать, затем пытается записать данные, а после этого стирает заметку
(здесь это упрощено, но вы поняли общий принцип).
Если во время записи что-то пойдет не так, сервер использует эти заметки, чтобы либо успешно завершить запрос записи (если это возможно), либо вернуть данные в исходное состояние. В результате повредить данные на удалённом сервере баз данных очень тяжело.(5) Delphi и базы данных
Если вы хотите использовать свой формат данных в приложениях баз данных, то вам очень многое придётся придумать самому. В частности, вам нужно написать процедуры для создания и заполнения ваших структур данных
(которые могут быть типом record),
процедуры чтения и записи данных и всё остальное, включая отображение данных структур в пользовательском интерфейсе, обнаружение пользовательских изменений в этих данных, и заполнение ваших структур данных из пользовательского интерфейса с целью записи в файлы.Да, вы можете инкапсулировать всё это в пользовательские компоненты, но суть в том, что вы отвечаете за все этапы процесса.
Если же вы используете одну из поддерживаемых файл-серверных баз или удалённый сервер баз данных - это совсем другая история.
Delphi включает в себя большое количество компонентов, умеющих читать и писать данные из широкого спектра промышленных баз данных, а также богатое разнообразие компонентов визуализации данных, которые могут как отображать эти данные, так и позволить пользователю их вводить или править. Наконец, Delphi имеет специальный компонент, который действует как связка между классами, описанными в предыдущем предложении.
Эти компоненты могут быть разделены на три категории: наследники TDataset, компоненты визуализации данных (data-aware) и класс TDataSource. Каждая категория описана ниже в своём разделе.
Delphi-компоненты TDataSet
Delphi-компоненты TDataset предназначены для связи с базой данных через библиотеку процедур, "понимающих" нужную БД. Некоторые из этих библиотек основаны на промышленных стандартах, таких как ODBC
(Open DataBase Connectivity)
- стандарт для доступа к данным, ставший частью операционной системы Windows с 1990-х годов. Другие созданы для работы с конкретным видом баз данных, например, с InterBase.Эти компоненты относятся к TDataset с тех пор, как большинство компонентов в этих наборах компонентов стали наследоваться от абстрактного класса TDataset библиотеки VCL
(Visual Component Library).
Рассмотрим оригинальные классы TDataset, ассоциированные с BDE(Borland Database Engine).
Основные классы этой группы, используемые в приложениях для работы с таблицами, выполнения запросов и хранимых процедур, называются, соответственно, TTable, TQuery, и TStoredProc. Каждый из этих классов происходит от TDataset (не напрямую, а через несколько промежуточных классов, например, TDBDataset).
Что касается TTable, TQuery, и TStoredProc, эти классы работают не в одиночку.
Существуют и другие классы, которые, хотя и не происходят от TDataset, тем не менее считаются классами TDataset. Например, класс TDatabase определяет соединение с базой данных, которое в случае файл-серверной БД просто ссылается на каталог, в котором хранятся файлы Paradox или DBase, а в случае удаленного сервера баз данных - содержит параметры сервера и базы данных, расположенной на нём.
Важно, что эти классы работают вместе, чтобы обеспечить всё необходимое для работы с базой данных.
Например, TDatabase может быть использован для хранения имени пользователя и пароля, необходимых для доступа к зашифрованной базе Paradox.
После того, как TDatabase установит соединение, можно использовать TTable для открытия конкретной таблицы Paradox, либо TQuery для выполнения запроса в отношении одной или нескольких таблиц в БД Paradox.
Чтобы эти TTables и TQueries успешно выполнили свои задачи, они должны быть связаны с TDatabase.
Это делается с помощью свойства Database классов TTable и Tquery.
При этом здесь есть неочевидные тонкости. В частности, чтобы узнать размещение файлов данных, TTable может сослаться на псевдоним BDE, определение которого хранится в настройках BDE. "Не очевидной" частью является то, что, если вы откроете TTable, и этот TTable видит, что он не связан с TDatabase, он на лету создает скрытый TDatabase, и этот TDatabase используется для установления соединения с БД.
Каждый набор классов-потомков TDataset имитирует его базовую структуру, хотя между разными наборами имеются некоторые различия.
В частности, всегда есть некоторые классы, созданные для выполнения запросов, выполнения хранимых процедур или открытия запроса SELECT * на таблицу (обычно то, что представляет Ttable). Кроме того, всегда есть один или несколько компонентов, определяющих соединение с базой данных.
В мире BDE это TDatabase (и он работает с другим компонентом -Tsession), но большинство наследников TDataset включают в себя класс с названием, похожим на TConnection, таких как TSQLConnection, TIBConnection, и TADSConnection.
Есть также и другие классы TDataset, играющие иные роли, но сейчас мы о них говорить не будем.
В Delphi 1 включен только один набор потомков TDataset. Delphi 2010 включает в себя не менее 6 наборов (я опишу их более подробно в будущей статье этой серии). Кроме того, некоторые производители СУБД предоставляют собственные реализации потомков TDataset. Через них вы можете получить доступ к данным в огромном диапазоне баз данных, включая Paradox, DBase, MS Access, MS SQL Server, Oracle, DB2, MySQL, SQL Anywhere, Sybase ASE, InterBase, Firebird, BlackfishSQL, Advantage Database Server, и многие другие.
Элементы управления данными в Delphi
Пока различные классы TDataset дают Вам доступ к замечательной коллекции баз данных, различные элементы управления данными в Delphi позволяют легко создавать пользовательские интерфейсы, позволяющие пользователям взаимодействовать с этими данными. Некоторые из этих классов, таких как DBNavigator и DBGrid, ссылаются на весь TDataset целиком, в то время как другие, такие как TDBEdit и TDBMemo, относятся к одному полю TDataset
(подробнее о полях и данных мы поговорим в следующей статье этой серии; на данный момент достаточно сказать, что некоторые элементы управления ссылаются на коллекцию данных, а другие - на одиночные записи).
Во многих случаях, эти элементы управления не только отображают данные, но и разрешают пользователям эти данные изменять. Например, DBGrid может быть использован для отображения большинства типов текстовых данных из базы, а также редактирования этих данных (если набор данных, к которому он привязан, разрешает редактирование). Пример отображения данных из базы в DBGrid показан на рисунке 4.
Рисунок 4: Отображение данных в DBGrid
Некоторые другие элементы управления, например, DBImage и DBLabel, отображают данные, но не позволят Вам их изменить. Наконец, компонент DBNavigator не отображает данные вообще, зато вместо этого даёт Вам удобное средство перемещения вперед и назад по вашей базе данных.
(DBNavigator поддерживает дополнительные операции, такие как перевод набора данных в режим редактирования, размещение и отмену изменений, но только если связанный с ним набор данных разрешает эти операции).
Прежде чем перейти к последнему компоненту - TDataSource, составляющему основную поддержку Delphi для развития приложений баз данных, уместно сделать такой комментарий по элементам управления данными.
Некоторые разработчики Delphi не одобряют использование этих элементов управления, предпочитая вручную производить чтение и запись данных через интерфейс пользователя и наборы данных.
Я не хочу здесь подробно вдаваться в аргументы за и против обоих этих подходов.
Вместо этого я просто скажу, что элементы управления данными в Delphi легки в использовании и обеспечивают много функций, необходимых в большинстве ваших основных пользовательских интерфейсов. Но если вы хотите нечто большее, чем предлагают эти элементы управления, то вы можете свободно использовать широкий спектр альтернативных методик.
TDataSource
Последний компонент в этой триаде - это не набор компонентов, а лишь один компонент: TDataSource. TDataSource выполняет две основные функции. Первая, самая очевидная - взаимосвязь между набором данных и элементом управления данными. В самом деле, элементы управления данными получают свои данные от TDataSource. Вот как это работает. TDataSource цепляется к определённому набору данных через своё свойство Dataset типа TDataset, что означает, что это свойство может указывать на любой из широкого спектра потомков TDataSet. Элементы управления данными, в свою очередь, указывают на компонент TDataSource через их свойства DataSource. Для тех элементов управления, которые ссылаются на конкретное поле набора данных, название этого поля заносится в их свойство DataField. Когда набор данных, к которому прицеплен DataSource, меняет своё состояние, например, становится активным или переходит на новую запись
(новый набор полей данных),
TDataSource сообщает об изменении состояния набора данных связанным с ним элементам управления данными, и они реагируют, изменяя свой внешний вид. Например, если TDataset становится активным и указывает на данные(не указывая на пустой набор данных),
элементы управления будут отображать данные, содержащиеся в TDataSet. Аналогично, если TDataset обновляется, отображая новую запись(или иной набор полей),
элементы управления реагируют, перерисовывая себя и выводя эти новые данные.Важно отметить, что это взаимодействие между TDataSource и элементами управления идет в обоих направлениях. Например, если вы попытаетесь ввести данные в DBGrid, и основной набор данных не находится в режиме редактирования, TDataSource "попросит" TDataset переключиться в режим редактирования.
Если TDataset "согласится", DBGrid позволит ввести данные. Но если он настроен в режим "только для чтения", он отклонит запрос перевода в режим редактирования, и DBGrid не разрешит ввод данных. Рисунок 5 изображает отношения между TDatasets, TDataSource, и элементами управления данными в BDE.
Вторая роль, которую играет TDataSource - участие во взаимодействии между двумя или более наборами данных. Во многих отношениях это похоже на роль, которую он играет при взаимодействии с элементами управления, но разница в том, что здесь нет элементов пользовательского интерфейса. Я сейчас больше не буду больше говорить об этой второй роли, но я хотел бы, чтобы вы, по меньшей мере, знали, что она существует.
(6) Резюме
В этой первой статье большой серии по разработке баз данных в Delphi я начал с самых основных моментов. Статья началась с общего взгляда на базы данных, с краткого обсуждения наиболее распространенных типов баз данных, поддерживаемых Delphi. Она продолжилась общим обзором компонентов Delphi, связанных с базами данных.
В следующей статье этой серии мы рассмотрим различные типы структур данных, содержащихся в базах данных, включая таблицы, индексы, представления и хранимые процедуры. Затем я покажу вам, как использовать компоненты Delphi для работы с этими типами данных.
Об авторе
Кэри Дженсен (Cary Jensen) главный технический директор Jensen Data Systems, компании, которая занимается консалтингом, обучением, разработкой, документацией и системами помощи. С 1988 года строил и разворачивал приложения баз данных в различных отраслях промышленности. Кроме того, Кэри является самым продаваемым автором более чем 20 книг по разработке программного обеспечения и победителем награды Choice Award for Best Training в 2002 и 2003 от Delphi Informant Reader. Часто выступает на конференциях, семинарах, симпозиумах в разных частях света, уважаем за его скромный юмор и практический подход к сложным вопросам. Кэри имеет степень доктора философии Университета Райса в области психологии человеческого фактора, специализируется на взаимодействии человека с компьютером.
| < Предыдущая | Следующая > |
|---|
