Анализ среды программирования Delphi

программирование delphi визуальный редактор.

Объектом исследования в дипломном проекте являются создание реляционных баз данных, среда объектно-ориентированного программирования Delphi 5, как среда разработки приложений баз данных и построения интерфейса компьютер — человек.

Цель работы — систематизировать учебную документцию и построить пользовательский интерфейс обеспечивающий удобный доступ и целостность данных.

В ходе работы на основе исходных данных построена концептуальная и реляционная модели и создано приложение, осуществляющее работу с полученной реляционной базой данных. Также исследованы приемы построения приложений баз данных в среде Delphi 5, выявлены особенности в работе данной среды.

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

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

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

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

Другие фирмы идут по пути создания мощных по своим возможностям инструментальных оболочек, с помощью которых можно в довольно сжатые сроки создать большое количество электронных учебников, наполняя «пустую» оболочку текстовыми и графическими материалами. Современные оболочки предусматривают возможность доступа к внешним ресурсам Интернет (выход в поисковые системы и базы данных, работу с тематическими сайтами), участия в телеконференциях и чатах с преподавателями. Значительное место в подобных учебниках занимает тестирование. Очень важным является то, что при использовании инструментальных оболочек удается организовать одновременную работу с ними большого количества обучаемых, что является затруднительным при использовании WWW-технологий. В настоящее время подобные инструментальные оболочки создаются практически в каждом российском университете, занимающемся развитием системы дистанционного обучения с использованием Интернет-технологий (например, в известном Московском государтвенном университете экономики, статистики и информатики, МЭСИ). Также созданием подобных инструментальных оболочек-программ занимаются уже несколько лет такие известные фирмы-разработчики программного обеспечения как Oracle, Lotus, IBM, Maris Multimedia и др.

1. Основные идеи положенные в основу программы.

Основанием для разработки программы послужила идея создания некоторого гибрида между просмотрщиком (BROWSERом) документов и базой данных для их структурированного хранения, поиска необходимой информации по тематическим разделам и ключевым словам. Также было признано необходимым включить в просмотрщик особый элемент интерфейса облегчающий навигацию внутри документа. В качестве такого элемента решено использовать иерархическое дерево заголовков — пунктов документов. Пример подобного дерева можно увидеть в стандартном «проводнике» операционной системы Windows (рис. 1.1), где оно используется для навигации по дискам и директориям компьютера.

Рис. 1.1 Проводник Windows.

Интерфейс программы было решено разделить на две части:

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

Языком программирования, на котором реализовано приложение, выбран продукт фирмы Borland — Delphi 5 обоснование выбора и описание языка приведены в главе 2. СРЕДА ПРОГРАММИРОВАНИЯ DELPHI.

Посредником между приложением и базой данных используется стандартный процессоре баз данных Borland Database Engine 4 описание которого приведено в главе 4. ПРОЦЕССОР БАЗ ДАННЫХ ФИРМЫ BORLAND.

Полученное в результате разработки приложение и связанная с ним база данных описаны в главе 5. ОПИСАНИЕ ПРОГРАММЫ.

2. Среда программирования Delphi.

Delphi — это греческий город, где жил дельфийский оракул. И этим именем был назван новый программный продукт с феноменальными характеристиками.

2.1 Основные характеристики продукта.

Delphi — это комбинация нескольких важнейших технологий:

Высокопроизводительный компилятор в машинный код Объектно-ориентированная модель компонент Визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов Масштабируемые средства для построения баз данных Компилятор в машинный код Компилятор, встроенный в Delphi, обеспечивает высокую производительность, необходимую для построения приложений в архитектуре «клиент-сервер». Этот компилятор в настоящее время является самым быстрым в мире, его скорость компиляции составляет свыше 120 тысяч строк в минуту на компьютере 486DX33. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).

В процессе построения приложения разработчик выбирает из палитры компонент готовые компоненты как художник, делающий крупные мазки кистью. Еще до компиляции он видит результаты своей работы — после подключения к источнику данных их можно видеть отображенными на форме, можно перемещаться по данным, представлять их в том или ином виде. В этом смысле проектирование в Delphi мало чем отличается от проектирования в интерпретирующей среде, однако после выполнения компиляции мы получаем код, который исполняется в 10−20 раз быстрее, чем-то же самое, сделанное при помощи интерпретатора. Кроме того, компилятор компилятору рознь, в Delphi компиляция производится непосредственно в родной машинный код, в то время как существуют компиляторы, превращающие программу в так называемый p-код, который затем интерпретируется виртуальной p-машиной. Это не может не сказаться на фактическом быстродействии готового приложения.

2.2 Объектно-ориентированная модель программных компонент.

Основной упор этой модели в Delphi делается на максимальном реиспользовании кода. Это позволяет разработчикам строить приложения весьма быстро из заранее подготовленных объектов, а также дает им возможность создавать свои собственные объекты для среды Delphi. Никаких ограничений по типам объектов, которые могут создавать разработчики, не существует. Действительно, все в Delphi написано на нем же, поэтому разработчики имеют доступ к тем же объектам и инструментам, которые использовались для создания среды разработки. В результате нет никакой разницы между объектами, поставляемыми Borland или третьими фирмами, и объектами, которые мы можем создать.

В стандартную поставку Delphi входят основные объекты, которые образуют удачно подобранную иерархию из 270 базовых классов. Для начала — неплохо. Но если возникнет необходимость в решении какой-то специфической проблемы на Delphi, прежде чем попытаться начинать решать проблему «с нуля», желательно просмотреть список свободно распространяемых или коммерческих компонент, разработанных третьими фирмами, количество этих фирм в настоящее время превышает число 250, хотя, я не обо всех знаю. Скептики, возможно, не поверят мне, когда я скажу, что на Delphi можно одинаково хорошо писать как приложения к корпоративным базам данных, так и, Например, игровые программы. Тем не менее, это так. Во многом это объясняется тем, что традиционно в среде Windows было достаточно сложно реализовывать пользовательский интерфейс. Событийная модель в Windows всегда была сложна для понимания и отладки. Но именно разработка интерфейса в Delphi является самой простой задачей для программиста.

2.3 Быстрая разработка работающего приложения из прототипов.

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

Cреда Delphi включает в себя полный набор визуальных инструментов для скоростной разработки приложений (RAD — rapid application development), поддерживающей разработку пользовательского интерфейса и подключение к корпоративным базам данных. VCL — библиотека визуальных компонент, включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE. Единственное, что можно поставить в вину Delphi, это то, что готовых компонент, поставляемых Borland, могло бы быть и больше. Однако, разработки других фирм, а также свободно распространяемые программистами компоненты уже восполнили этот недостаток. Подобное было в Visual Basic.

Соответствующий стандарт компонент назывался VBX. И этот стандарт так же поддерживается в Delphi. Однако, визуальные компоненты в Delphi обладают большей гибкостью. Вспомним, в чем была проблема в VB. Прикладной программист программировал, вообще говоря, в среде языка бэйсик. А компоненты в стандарте VBX готовили ему коллеги — профессиональные программисты на языке С++.

VBX-компоненты поставлялись, «как есть», и ни исправить, ни добавить ничего было нельзя.

Для изготовления VBX надо было осваивать язык C++. В Delphi визуальные компоненты пишутся на Object Pascal, на том же «паскале», на котором пишется алгоритмическая часть приложения. И визуальные компоненты Delphi получаются открытыми для надстройки и переписывания.

2.4 Масштабируемые средства для построения баз данных.

Объекты баз данных (БД) в Delphi основаны на языке SQL и включают в себя полную мощь Borland Database Engine. В состав Delphi также включен Borland SQL Link, поэтому доступ к системам управления базами данных (СУБД) Oracle, Sybase, Informix и InterBase происходит с высокой эффективностью. Кроме того, Delphi включает в себя локальный сервер Interbase для того, чтобы можно было разработать расширяемые на любые внешние SQL-сервера приложения в офлайновом режиме (т.е. в режиме без использования сети). Разработчик в среде Delphi, проектирующий информационную систему для локальной машины (Например, небольшую систему учета медицинских карточек для одного компьютера), может использовать для хранения информации файлы формата .dbf (как в dBase или Clipper) или .db (Paradox). Если же он будет использовать локальный InterBase for Windows 4.0 (это локальный SQL-сервер, входящий в поставку), то его приложение безо всяких изменений будет работать и в составе большой системы с архитектурой клиент-сервер.

Вот она — масштабируемость на практике — одно и то же приложение можно использовать как для локального, так и для более серьезного клиент-серверного вариантов.

2.5 Delphi — два варианта поставки.

Теперь можно перейти к описанию собственно продукта. Что лежит внутри в коробке, и чем может воспользоваться программист при разработке прикладной системы? Выпущены две версии Delphi — одна (Delphi Client-Server) адресована для разработчиков приложений в архитектуре «клиент-сервер», а другая (Delphi for Windows) предназначена для остальных программистов. Приложения, разработанные при помощи Delphi, можно использовать без выплаты процентов и без оплаты лицензий.

2.5.1 Клиент-серверная версия Delphi.

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

Клиент-серверная версия включает в себя следующие особенности:

SQL Links: специально написанные драйвера для доступа к Oracle, Sybase, Informix, InterBase.

Локальный сервер InterBase: SQL-сервер для Windows 3.1. СУБД для разработки в корпоративных приложений на компьютере, не подключенном к локальной сети.

ReportSmith Client/server Edition: генератор отчетов для SQL-серверов.

Team Development Support: предоставляет версионный контроль при помощи PVCS компании Intersolve (приобретается отдельно) или при помощи других программных продуктов версионного контроля.

Visual Query Builder — это средство визуального построения SQL-запросов исходные тексты всех визуальных компонент.

2.5.2 Delphi для Windows.

Delphi для Windows представляет из себя подмножество Delphi Client-Server и предназначен для разработчиков высокопроизводительных персональных приложений, работающих с локальными СУБД типа dBase и Paradox. Delphi Desktop Edition предлагает такую же среду для быстрой разработки и первоклассный компилятор как и клиент-серверная версия (Client/Server Edition). Эта среда позволяет разработчику быстро изготавливать персональные приложения, работающие с персональными СУБД типа dBase и Paradox. Delphi позволяет также создавать разработчику DLL, которая может быть вызвана из Paradox, dBase, C++ или каких-нибудь других готовых программ.

В Delphi for Windows, как и в Delphi Client-Server, входят:

компилятор Object Pascal (этот язык является расширением языка Borland Pascal 7.0).

среда визуального построителя приложений библиотека визуальных компонент Локальный сервер InterBase.

В этом обзоре стоит упомянуть еще один продукт, выпущенный компанией Borland для Delphi. Это учебник по Object Pascal, интерактивный отладчик самой последней версии, Borland Visual Solutions Pack (набор VBX для реализации редакторов, электронных таблиц, коммуникационные VBX, VBX с деловой графикой и т. п.), Resource WorkShop для работы с ресурсами Borland Pascal 7.0, а также дельфийский эксперт для преобразования ресурсов BP 7.0 в формы Delphi.

2.6 Для кого предназначен Delphi.

В первую очередь Delphi предназначен для профессионалов-разработчиков корпоративных информационных систем. Может быть, здесь следует пояснить, что конкретно имеется в виду. Не секрет, что некоторые удачные продукты, предназначенные для скоростной разработки приложений (RAD — rapid application development) прекрасно работают при изготовлении достаточно простых приложений, однако, разработчик сталкивается с непредвиденными сложностями, когда пытается сделать что-то действительно сложное. Бывает, что в продукте вскрываются присущие ему ограничения только по прошествии некоторого времени.

Delphi такие ограничения не присущи. Хорошее доказательство тому — это тот факт, что сам Delphi разработан на Delphi. Однако Delphi предназначен не только для программистов-профессионалов.

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

2.7 Некоторые особенности Delphi.

2.7.1 Локальный сервер InterBase.

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

2.7.2 Team Development Support.

Средство поддержки разработки проекта в группе. Позволяет существенно облегчить управление крупными проектами.

Высокопроизводительный компилятор в машинный код. В отличие от большинства Pascalкомпиляторов, транслирующих в p-код, в Delphi программный текст компилируется непосредственно в машинный код, в результате чего Delphiприложения исполняются в 10−20 раз быстрее (особенно приложения, использующие математические функции). Готовое приложение может быть изготовлено либо в виде исполняемого модуля, либо в виде динамической библиотеки, которую можно использовать в приложениях, написанных на других языках программирования.

2.7.3 Открытая компонентная архитектура.

Благодаря такой архитектуре приложения, изготовленные при помощи Delphi, работают надежно и устойчиво. Delphi поддерживает использование уже существующих объектов, включая DLL, написанные на С и С++, OLE сервера, VBX, объекты, созданные при помощи Delphi. Из готовых компонент работающие приложения собираются очень быстро. Кроме того, поскольку Delphi имеет полностью объектную ориентацию, разработчики могут создавать свои повторно используемые объекты для того, чтобы уменьшить затраты на разработку.

Delphi предлагает разработчикам — как в составе команды, так и индивидуальным — открытую архитектуру, позволяющую добавлять компоненты, где бы они ни были изготовлены, и оперировать этими вновь введенными компонентами в визуальном построителе.

2.7.4 Two-way tools.

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

Визуальный построитель интерфейсов (Visual User-interface builder) дает возможность быстро создавать клиент-серверные приложения визуально, просто выбирая компоненты из соответствующей палитры.

2.7.5 Библиотека визуальных компонентов.

Эта библиотека объектов включает в себя стандартные объекты построения пользовательского интерфейса, объекты управления данными, графические объекты, объекты мультимедиа, диалоги и объекты управления файлами, управление DDE и OLE.

2.7.6 Структурное объектно-ориентированное программирование.

Delphi использует структурный объектно-ориентированный язык (Object Pascal), который сочетает с одной стороны выразительную мощь и простоту программирования, характерную для языков 4GL, а с другой стороны эффективность языка 3GL. Программисты немедленно могут начать производить работающие приложения, и им не придется для этого изучать особенности программирования событий в Windows. Delphi полностью поддерживает передовые программные концепции включая инкапсуляцию, наследование, полиморфизм и управление событиями.

2.8 Delphi: настраиваемая среда разработчика.

2.8.1 Палитра компонент.

После запуска Delphi в верхнем окне горизонтально располагаются иконки палитры компонент. Если курсор задерживается на одной из иконок, под ней в желтом прямоугольнике появляется подсказка (рис. 2.1).

Палитра компонент.

Рис. 2.1.

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

Понятно все эти компоненты имеют свое графическое представление в поле форм для того, чтобы можно было бы ими соответствующим образом оперировать. Но для работающей программы видимыми остаются только визуальные компоненты. Компоненты сгруппированы на страницах палитры по своим функциям. Например, компоненты, представляющие исполняемые диалоги Windows все размещены на странице палитры с названием «Dialogs» .

Delphi позволяет разработчикам настроить среду для максимального удобства. Можно легко изменить палитру компонент, инструментальную линейку, а также настраивать выделение синтаксиса цветом.

Заметим, что в Delphi можно определить свою группу компонент и разместить ее на странице палитры, а если возникнет необходимость, перегруппировать компоненты или удалить неиспользуемые.

2.8.2 Интеллектуальный редактор.

Delphi обладает мощнейшим, встроенным в редактор графическим отладчиком, позволяющим находить и устранять ошибки в коде. Можно установить точки останова, проверить и изменить переменные, при помощи пошагового выполнения в точности понять поведение программы. Если же требуются возможности более тонкой отладки, можно использовав Turbo Debugger, проверить ассемблерные инструкции и регистры процессора.(рис. 2.2 и рис. 2.3).

Редактор кода.

Рис. 2.2.

Рис. 2.3. Turbo Debugger.

2.8.3 Инспектор объектов.

Этот инструмент представляет собой отдельное окно, где мы можем в период проектирования программы устанавливать значения свойств и событий объектов (рис. 2.4).

Рис. 2.4. Инспектор объектов.

2.8.4 Менеджер проектов.

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

Менеджер проектов показывает имена файлов, время/дату выбранных форм и пр. (рис. 2.5).

Рис. 2.5 Менеджер проектов Можно немедленно попасть в текст или форму, просто щелкнув мышкой на соответствующее имя.

2.8.5 Эксперты.

Это набор инструментальных программ, облегчающих проектирование и настройку Ваших приложений.

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

Включает в себя:

Эксперт форм, работающих с базами данных Эксперт стилей и шаблонов приложений Эксперт шаблонов форм.

2.9 Написание кода программы.

Информация о формах хранится в двух типах файлов — .dfm и .pas, причем первый тип файла — двоичный — хранит образ формы и ее свойства, второй тип описывает функционирование обработчиков событий и поведение компонент. Оба файла автоматически синхронизируются Delphi, так что если добавить новую форму в ваш проект, связанный с ним файл .pas автоматически будет создан, и его имя будет добавлено в проект.

Такая синхронизация и делает Delphi two-way-инструментом, обеспечивая полное соответствие между кодом и визуальным представлением. Как только мы добавим новый объект или код, Delphi устанавливает т.н. «кодовую синхронизацию» между визуальными элементами и соответствующими им кодовыми представлениями.

Например, необходимо добавить обработчик событий, чтобы показывать окно сообщения по нажатию кнопки. Описание обработчика появляется, если дважды щелкнуть мышкой непосредственно на объект Button в форме или дважды щелкнуть мышью на строчку OnClick на странице Events в Инспекторе объектов. В любом случае Delphi создаст процедуру или заголовок метода, куда можно добавить код.

procedure TForm1. Button1Click (Sender: TObject);

begin.

end;

Cоздавая этот код, Delphi автоматически формирует декларацию объекта TForm1, которая содержит процедуру ButtonClick, представляющую из себя собственно обработчик события.

TForm1 = class (TForm).

Button1: Tbutton;

procedureButton1Click (Sender: TObject);

Конечно, можно решить после получения этого кода, что автоматически созданные имена нас не устраивают, и заменить их. Например, Button1 на Warning. Это можно сделать, изменив свойство Name для Button1 при помощи Инспектора объектов. Как только мы нажмем Enter, Delphi автоматически произведет соответствующую синхронизацию в коде. Так как объект TForm1 существует в коде, мы свободно можем добавлять любые другие поля, процедуры и функции. Например, мы можем дописать в коде свою собственную процедуру, обрабатывающую событие, а не делать это визуальным методом.

Следующий пример показывает, как это можно сделать. Обработчик принимает аргумент типа TObject, который позволяет нам определить, если необходимо, кто инициировал событие. Это полезно в случае, когда несколько кнопок вызывают общую процедуру для обработки.

TForm1 = class (TForm).

Warning: TButton;

Button1: TButton;

procedure WarningClick (Sender: TObject);

procedure NewHandler (Sender: TObject);

private.

{ Private declarations }.

public.

{ Public declarations }.

end;

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

2.9.1 Добавление новых объектов.

Delphi — это прежде всего среда разработки, базирующаяся на использовании компонент. Поэтому мы можем добавлять совершенно новые компоненты в палитру компонент.

Последовательность введения новой компоненты состоит из трех шагов:

наследование из уже существующего типа компоненты определение новых полей, свойств и методов регистрация компоненты Это все делается через меню Install Components.

2.9.2 Делегирование.

Под делегированием понимается то, что некий объект может предоставить другому объекту отвечать на некоторые события.

Такая модель в некоторых случаях значительно упрощает программирование. Например, когда мы добавляем кнопку в форму и прикрепляете код, обрабатывающий нажатие, вы фактически используете делегирование кода для ассоциирования кода с событием OnClick. Такая ассоциация происходит для вас автоматически. Если проверить страницу Events в Инспекторе объектов для вашего приложения, можно увидеть ассоциированные с событиями процедуры.

2.9.3 Ссылки на классы.

Ссылки на классы придают дополнительный уровень гибкости, так, когда вы хотите динамически создавать объекты, чьи типы могут быть известны только во время выполнения кода. Например, ссылки на классы используются при формировании пользователем документа из разного типа объектов, где пользователь набирает нужные объекты из меню или палитры. Собственно, эта технология использовалась и при построении Delphi.

2.9.4 Обработка исключительных ситуаций.

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

В Delphi это устроено в стиле С++. Исключения представлены в виде объектов, содержащих специфическую информацию о соответствующей ошибке (тип и местонахождение ошибки). Разработчик может оставить обработку ошибки, существовавшую по умолчанию, или написать свой собственный обработчик.

Обработка исключений реализована в виде exception-handling blocks (также еще называется protected blocks), которые устанавливаются ключевыми словами try и end. Существуют два типа таких блоков: try… except и try… finally.

Общая конструкция выглядит примерно так:

try.

{ выполняемые операторы }.

except.

on exception1 do statement1;

{ реакция на ситуации }.

on exception2 do statement2;

else.

{ операторы по умолчанию }.

end;

Конструкция try… finally предназначена для того, чтобы разработчик мог быть полностью уверен в том, что, что бы ни случилось, перед обработкой исключительной ситуации всегда будет выполнен некоторый код (например, освобождение ресурсов).

try.

{ выполняемые операторы }.

finally.

{ операторы, выполняемые безусловно }.

end;

2.10 О составе Delphi.

В составе Delphi входит 5 интерактивных обучающих систем, документация в электронном виде и около 10 Мб справочной информации:

Документация.

Руководство пользователя Руководство по написанию компонент Построение приложений, работающих с базами данных Руководство по генератору отчетов ReportSmith.

Руководство по SQL Links.

3. Базы данных.

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

Мы будем рассматривать только реляционные базы данных: во-первых, реляционные базы получили наибольшее распространение в мире; во-вторых, они наиболее «продвинуты» в научном плане; а в-третьих, ядро баз данных Borland Database Engine, на основе которого работают все последние продукты компании Borland, предназначено именно для работы с реляционными базами данных.

Жизненный цикл любого программного продукта, в том числе и системы управления базой данных, состоит из стадий проектирования, реализации и эксплуатации.

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

3.1 Требования к базам данных.

Итак, хорошо спроектированная база данных:

Удовлетворяет всем требованиям пользователей к содержимому базы данных. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.

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

Обеспечивает естественное, легкое для восприятия структурирование информации. Качественное построение базы позволяет делать запросы к базе более «прозрачными» и легкими для понимания; следовательно, снижается вероятность внесения некорректных данных и улучшается качество сопровождения базы.

Удовлетворяет требованиям пользователей к производительности базы данных. При больших объемах информации вопросы сохранения производительности начинают играть главную роль, сразу «высвечивая» все недочеты этапа проектирования.

Следующие пункты представляют основные шаги проектирования базы данных:

Определить информационные потребности базы данных.

Проанализировать объекты реального мира, которые необходимо смоделировать в базе данных. Сформировать из этих объектов сущности и характеристики этих сущностей (например, для сущности «деталь» характеристиками могут быть «название», «цвет», «вес» и т. п.) и сформировать их список:

Поставить в соответствие сущностям и характеристикам — таблицы и столбцы (поля) в нотации выбранной СУБД.

Определить атрибуты, которые уникальным образом идентифицируют каждый объект.

Установить связи между объектами (таблицами и столбцами), провести нормализацию таблиц.

Спланировать вопросы надежности данных и, при необходимости, сохранения секретности информации.

3.2 Основные концепции реляционных баз данных.

В реляционной теории одним из главных является понятие отношения. Математически отношение определяется следующим образом. Пусть даны n-множеств D1, D2,…, Dn. Тогда R есть отношение над этими множествами, если R есть множество упорядоченных наборов вида, где d1 — элемент из D1, d2 — элемент из D2, …, dn — элемент из Dn. При этом наборы вида называются кортежами, а множества D1, D2,…, Dn — доменами. Каждый кортеж состоит из элементов, выбираемых из своих доменов. Эти элементы называются атрибутами, а их значения — значениями атрибутов (рис. 3.1).

Рис. 3.1. Отношение.

Легко заметить, что отношение является отражением некоторой сущности реального мира (в данном случае — сущности «деталь») и с точки зрения обработки данных представляет собой таблицу. Поскольку в локальных базах данных каждая таблица размещается в отдельном файле, то с точки зрения размещения данных для локальных баз данных отношение можно отождествлять с файлом. Кортеж представляет собой строку в таблице (запись). Атрибут же является полем в записи. Домен же представляется неким обобщенным типом, столбцом таблицы, который для типов полей в записи. Таким образом, следующие тройки терминов являются эквивалентными:

отношение, таблица, файл (для локальных баз данных) кортеж, строка, запись атрибут, столбец, поле.

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

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

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

Для поддержания ссылочной целостности данных во многих СУБД имеется механизм так называемых внешних ключей. Смысл этого механизма состоит в том, что некоему атрибуту (или группе атрибутов) одного отношения назначается ссылка на первичный ключ другого отношения; тем самым закрепляются связи подчиненности между этими отношениями. При этом отношение, на первичный ключ которого ссылается внешний ключ другого отношения, называется master-отношением, или главным отношением; а отношение, от которого исходит ссылка, называется detail-отношением, или подчиненным отношением. После назначения такой ссылки СУБД имеет возможность автоматически отслеживать вопросы «ненарушения» связей между отношениями, а именно:

если попытаться вставить в подчиненную таблицу запись, для внешнего ключа которой не существует соответствия в главной таблице (например, там нет еще записи с таким первичным ключом), СУБД сгенерирует ошибку;

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

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

Существует два подхода к удалению и изменению записей из главной таблицы:

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

Распространить всякие изменения в первичном ключе главной таблицы на подчиненную таблицу, а именно:

если в главной таблице удалена запись, то в подчиненной таблице должны быть удалены все записи, ссылающиеся на удаляемую;

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

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

3.3 Шаги проектирования базы данных.

3.3.1 Определение информационных потребностей базы данных.

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

сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системой;

какие данные используются разными приложениями; смогут ли приложения совместно использовать какие-либо из этих данных;

кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные;

достаточно ли будет для предметной области одной базы или потребуется несколько баз данных с различными структурами;

какая информация является наиболее чувствительной к скорости ее извлечения и изменения.

3.3.2 Анализ объектов реального мира.

Анализируются объекты, которые необходимо смоделировать в базе данных.

Формирование концептуальной модели базы данных включает в себя:

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

идентификацию объектов, которые осуществляют эту функциональную деятельность, и формирование из их операций последовательности событий, которые помогут Вам идентифицировать все сущности и взаимосвязи между ними. Например, процесс «ведение учета работающих» идентифицирует такие сущности как РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ.

идентификацию характеристик этих сущностей. Например, сущность РАБОТНИК может включать такие характеристики как Идентификатор Работника, Фамилия, Имя, Отчество, Профессия, Зарплата.

идентификацию взаимосвязей между сущностями. Например, каким образом сущности РАБОТНИК, ПРОФЕССИЯ, ОТДЕЛ взаимодействуют друг с другом? Работник имеет одну профессию (для простоты!) и значится в одном отделе, в то время как в одном отделе может находиться много работников.

3.3.3 Создание таблиц базы данных.

Установление соответствия между сущностями и характеристиками предметной области; отношениями и атрибутами в нотации, выбранной СУБД. Поскольку каждая сущность реального мира обладает некими характеристиками, в совокупности образующими полную картину ее проявления, можно поставить им в соответствие набор отношений (таблиц) и их атрибутов (полей).

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

3.3.4 Определение первичных ключей.

Определяются атрибуты, которые уникальным образом идентифицируют каждый объект. Это необходимо для того, чтобы система могла получить любую единичную строку таблицы. Мы должны определить первичный ключ для каждого из отношений. Если нет возможности идентифицировать кортеж с помощью одного атрибута, то первичный ключ нужно сделать составным — из нескольких атрибутов. Хорошим примером может быть первичный ключ в таблице работников, состоящий из фамилии, имени и отчества. Первичный ключ гарантирует, что в таблице не будет содержаться двух одинаковых строк. Во многих СУБД имеется возможность помимо первичного определять еще ряд уникальных ключей. Отличие уникального ключа от первичного состоит в том, что уникальный ключ не является главным идентифицирующим фактором записи и на него не может ссылаться внешний ключ другой таблицы. Его главная задача — гарантировать уникальность значения поля.

3.3.5 Выработка правил поддерживающих целостность данных.

Будучи определенными, такие правила в клиент-серверных СУБД поддерживаются автоматически — сервером баз данных; в локальных же СУБД их поддержание приходится возлагать на пользовательское приложение.

Эти правила включают:

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

3.3.6 Установление связи между таблицами и столбцами.

Каждый из различных типов связей должен быть смоделирован в базе данных.

Существует несколько типов связей:

связь «один-к-одному».

связь «один-ко-многим».

связь «многие-ко-многим».

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

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

Связь «многие-ко-многим» в явном виде в реляционных базах данных не поддерживается. Однако имеется ряд способов косвенной реализации такой связи, которые с успехом возмещают ее отсутствие. Один из наиболее распространенных способов заключается во введении дополнительной таблицы, строки которой состоят из внешних ключей, ссылающихся на первичные ключи двух таблиц. Например, имеются две таблицы: КЛИЕНТ и ГРУППА_ИНТЕРЕСОВ. Один человек может быть включен в различные группы, в то время как группа может объединять различных людей. Для реализации такой связи «многие-ко-многим» вводится дополнительная таблица, назовем ее КЛИЕНТЫ_В_ГРУППЕ, строка которой будет иметь два внешних ключа: один будет ссылаться на первичный ключ в таблице КЛИЕНТ, а другой — на первичный ключ в таблице ГРУППА_ИНТЕРЕСОВ. Таким образом, в таблицу КЛИЕНТЫ_В_ГРУППЕ можно записывать любое количество людей и любое количество групп.

Очень важная операция для исключения избыточности данных — нормализация таблиц. После определения таблиц, полей, индексов и связей между таблицами следует посмотреть на проектируемую базу данных в целом и проанализировать ее, используя правила нормализации, с целью устранения логических ошибок. Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные «по природе». Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений.

После применения правил нормализации логические группы данных располагаются не более чем в одной таблице. Это дает следующие преимущества:

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

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ), нормальная форма Бойса-Кодда (НФБК), четвертая нормальная форма (4НФ), пятая нормальная форма (5НФ). С практической точки зрения, достаточно трех первых форм — следует учитывать время, необходимое системе для «соединения» таблиц при отображении их на экране. Этот процесс включает:

устранение повторяющихся групп (приведение к 1НФ) удаление частично зависимых атрибутов (приведение к 2НФ) удаление транзитивно зависимых атрибутов (приведение к 3НФ).

Рассмотрим каждый из этих процессов подробней.

3.3.7 Приведение к первой нормальной форме.

Когда поле в данной записи содержит более одного значения для каждого вхождения первичного ключа, такие группы данных называются повторяющимися группами. 1НФ не допускает наличия таких многозначных полей. Рассмотрим пример базы данных предприятия, содержащей таблицу ОТДЕЛ (табл. 3.1) со следующими значениями (атрибут «Номер_отдела» является первичным ключом):

Таблица 3.1.

Для приведения этой таблицы к 1НФ мы должны устранить атрибут (поле) «Расположение» из таблицы ОТДЕЛ и создать новую таблицу РАСПОЛОЖЕНИЕ_ОТДЕЛОВ (табл. 3.2), в которой определить первичный ключ, являющийся комбинацией номера отдела и его расположения (Номер_отдела+Расположение). Теперь для каждого расположения отдела существуют различные строки; тем самым мы устранили повторяющиеся группы.

Таблица 3.2.

3.3.8 Приведение ко второй нормальной форме.

Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми. Неключевые атрибуты заключают в себе информацию о данной сущности предметной области, но не идентифицируют ее уникальным образом. Например, предположим, что мы хотим распределить работников по проектам, ведущимся на предприятии. Для этого создадим таблицу ПРОЕКТ (табл.3.3)с составным первичным ключом, включающим номер работника и идентификатор проекта (Номер_работника+ИД_проекта).

Таблица 3.3.

В этой таблице возникает следующая проблема. Атрибуты Назв_проекта, Описание_проекта и Продукт относятся к проекту как сущности и, следовательно, зависят от атрибута ИД_проекта (являющегося частью первичного ключа), но не от атрибута Номер_работника. Следовательно, они являются частично зависимыми от составного первичного ключа. То же самое можно сказать и об атрибуте Фамилия, который зависит от атрибута Номер_работника, но не зависит от атрибута ИД_проекта. Для нормализации этой таблицы (приведения ее в 2НФ) удалим из нее атрибуты Номер_работника и Фамилия и создадим другую таблицу (назовем ее РАБОТНИК_В_ПРОЕКТЕ), которая будет содержать только эти два атрибута, и они же будут составлять ее первичный ключ.

3.3.9 Приведение к третьей нормальной форме.

Третий этап процесса приведения таблиц к нормальной форме состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом. Предположим, например, что мы добавили поля Номер_руководителя и Телефон в таблицу ПРОЕКТ, находящуюся в 2НФ (первичным ключом является поле ИД_проекта). Атрибут Телефон логически связан с атрибутом Номер_руководителя, неключевым полем, но не с атрибутом ИД_проекта, являющимся первичным ключом (табл.3.4).

Таблица 3.4.

Для нормализации этой таблицы (приведения ее в 3НФ) удалим атрибут Телефон, изменим Номер_руководителя на Руководитель и сделаем атрибут Руководитель внешним ключом, ссылающимся на атрибут Номер_работника (первичный ключ) в таблице РАБОТНИКИ. После этого таблицы ПРОЕКТ и РАБОТНИКИ будут выглядеть следующим образом (табл. 3.5 и табл. 3.6 соответственно).

Таблица 3.5.