Текст книги "Access 2002. Самоучитель"

Таким образом выделена особо важная информация, примечания, предупреждения.

Глава 1 Постановка проблемы

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

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

Режимы функционирования банка данных в производственных условиях

Как правило, имеются в виду следующие режимы функционирования банка данных:

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

• режим корректировки, в котором осуществляется обновление, добавление и удаление информации, находящейся в банке данных;

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

– только выдачу пользователю информации о тех или иных параметрах процесса. Эта информация в требуемом формате содержится в банке данных;

– решение поставленной задачи с использованием сведений, находящихся в банке данных;

• режим реорганизации и анализа, в котором выполняются операции, непосредственно связанные с поддержанием банка данных в рабочем состоянии:

– реорганизация структур БД;

– копирование и восстановление БД;

– анализ статистических данных, связанных с функционированием информационного фонда.

Пользовательские запросы к банку данных

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

Конечно, нельзя заранее предусмотреть все возможные варианты запросов. Назовем лишь самые характерные типы запросов пользователя к банку данных в порядке возрастания сложности:

• запросы на обработку данных, связанных с одной таблицей (выборка, удаление, корректировка и ввод данных);

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

• запросы, при которых условием отбора записи является полное значение поля;

• запросы, при которых условием отбора записи является неполное значение поля;

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

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

• запросы с заданием параметров;

• запросы на создание объединенной выборки из нескольких разнородных таблиц и т. д.

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

Проблемы, связанные с выбором СУБД

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

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

• история использования компьютерных банков данных в СССР и в постсоветской России насчитывает более 35 лет, за этот период сменилось несколько поколений СУБД. Можно увлеченно спорить о том, насколько рациональным был этот процесс и какова эффективность той или иной конкретной СУБД. Однако важнее другое – хороши или плохи были эти системы, но в них аккумулировано значительное количество информации, которая используется в практических целях. Ясно, что с каждым годом объем таких данных возрастает.

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

Названным условиям удовлетворяет СУБД Access, входящая в состав комплексного программного продукта Microsoft Office. Последней версией этой системы на сегодняшний день является Access 2002, или Access ХР. Именно эта версия рассматривается в настоящем издании в качестве основной. Поэтому в дальнейшем мы не будем указывать индекс рядом с названием, говоря просто Access. Если же подразумевается какая-либо другая версия, например Access 97 или Access 2000, то она указывается с соответствующим индексом. Правда, на современном рынке много и других программных продуктов, успешно используемых в качестве платформы для банка данных. Поэтому сформулируем те критерии, на основании которых следует выбирать СУБД, и оценки Access по этим показателям [2] :

• количество ключевых (дескрипторных) полей, поддерживаемых в СУБД.

В Access ограничения на эту величину отсутствуют;

• ограничение на длину поля.

В Access данное ограничение составляет 255 байт для текстовых полей и до 255 байт – для числовых, в зависимости от типа поля;

• разнообразие типов обрабатываемых полей.

В Access имеются поля, содержащие текстовый и числовой типы данных. Эти типы, в свою очередь, представлены разными вариантами;

• дизайнерские возможности системы.

Наличие в Access мастеров и конструкторов позволяет достаточно быстро создавать таблицы, формы, отчеты, запросы. Добавление диаграмм в формы и отчеты, быстрая настройка программы и анализ ее быстродействия, использование архивариуса, возможность импорта и экспорта файлов, работа с гиперссылками и применение технологии OLE внутри пакета Microsoft Office;

• требования к уровню подготовки проектировщика и пользователя БД. Минимальные. Некоторые программные навыки нужны лишь в том случае, если придется использовать Visual Basic;

• язык программирования, операционная среда, сетевые возможности, требуемые ресурсы.

Язык запросов SQL, Visual Basic, операционная система Windows 98 или выше, а также Windows NT. При полной установке потребуется 26–30 Мбайт оперативной памяти и около 120 Мбайт памяти на жестком диске. Однако Access, как правило, устанавливается в составе программного комплекса Microsoft Office, и тогда требуется около 200 Мбайт памяти на жестком диске. Система Access обладает всеми современными сетевыми возможностями;

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

Имеются;

• поддерживаемые структуры и форматы данных.

В Access поддерживаются реляционные структуры данных;

• простота освоения системы, наличие русской версии документации.

Первичное освоение займет всего несколько дней. Имеется русифицированная версия Access в составе пакета Microsoft Office, а также русифицированная документация для пользователей различных уровней подготовки;

• поддерживаемый системой математический аппарат.

В Access он достаточно развит и включает операторы, функции, логические выражения и т. д. Более того, статус Access как органической составной части Microsoft Office позволяет легко пользоваться математическим аппаратом Excel;

• поддерживаемые системой возможности обработки и представления графической информации.

В Access поддерживаются операции с диаграммами. Поскольку эта СУБД встроена в пакет Microsoft Office, то пользователь может работать и с другими графическими объектами, входящими в состав данного пакета;

• возможности взаимодействия с другими пакетами прикладных программ (текстовыми редакторами, электронными таблицами, геоинформационными системами (ГИС) и др.).

В рамках пакета Microsoft Office можно работать с Word и Excel;

• возможности корректировки файлов, содержащих данные.

В Access это очень просто сделать;

• наличие русифицированной и достаточно подробной справочной системы, а также файлов Help (Помощь).

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

• разнообразие и гибкость формируемых запросов на предоставление данных.

Система Access отвечает этому условию.

Наверное, приведенные выше оценки не дают оснований утверждать, что Access – идеальная СУБД. Однако безупречных СУБД вообще не существует. Сравним, к примеру, Access с такой системой, как Oracle. Последняя – СУБД гораздо более высокого класса, значительно превосходящая Access по своим возможностям. Но такие преимущества имеют и оборотную сторону: Oracle громоздка, сложна в освоении и требует для нормального функционирования специальные и очень мощные технические средства. Область применения Oracle – создание очень больших централизованных информационных систем. По-видимому, время их массового использования в России еще не наступило.

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

Вопросы, рассмотренные в настоящей книге

Приведенные выше оценки относятся к версии Access 97. Как уже было сказано, на рынке появилась очередная версия этой СУБД – Access 2002 (Access ХР), обладающая более широкими возможностями. Поэтому при изложении материала автор учитывал:

• наличие в версии Access 2002 новых элементов по сравнению с Access 97;

• особенности, обусловленные использованием разнородных баз данных.

В той или иной степени специфика разных версий Access проявляется на всех этапах работы: от создания первичных таблиц до формирования запросов и использования элементов программирования. Можно было или сосредоточиться на том, чем отличаются друг от друга два варианта баз данных и программ (тогда материал неизбежно был бы изложен отрывочно и непоследовательно), или рассматривать весь процесс создания и использования банка данных от начала до конца в каждой из версий, по ходу описания комментируя различия между ними. Хотя во втором случае неизбежны повторы и в какой-то мере дублирование уже имеющейся литературы, для читателя такой вариант удобнее. Все необходимые сведения приводятся в одной книге, и пользователю не придется, забыв какую-то мелочь, «буксовать» из-за этого в повседневной работе.

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

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

В книге описывается процесс создания новых баз данных в программной среде Access 2002. Отличия этой версии от предыдущих версий специально оговариваются.

Что касается конвертирования БД, созданных в других программных средах, то сначала речь пойдет о «переводе» в Access 97, а затем в Access 2002. Кроме того, будут подробно рассмотрены те дополнительные возможности конвертации, которые появились в Access 2002 по сравнению с Access 97.

Резюме

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

2. В качестве базовой СУБД для интеграции разнородных СУБД в такой банк данных на сегодняшнем этапе предлагается Access 2002 (Access ХР).

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

Глава 2 Предпроектная структуризация информации

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

В настоящей книге будут рассматриваться в основном примеры из определенной предметной области – тематической сферы, к которой относится обрабатываемая информация. Речь пойдет о чрезвычайных ситуациях (ЧС), происходивших в действительности; о работах, связанных с ликвидацией последствий ЧС, и, в частности, об используемых при этом контрольно-измерительных приборах. Автор опирался на информацию, которая содержится в банках данных Министерства РФ по делам гражданской обороны, чрезвычайных ситуаций и ликвидации последствий стихийных бедствий (впоследствии – Министерства природных ресурсов России), бывшего Госкомитета РФ по охране окружающей среды (Госкомэкологии России) и бывшего Федерального агентства правительственной связи и информации (ФАПСИ). Создание объединенного банка таких данных не завершено, и состав включаемых в него БД в дальнейшем должен расширяться. Полученная информация используется преимущественно в аналитических целях: сбор статистических сведений, выявление тенденций, оценка последствий ЧС, выработка рекомендаций по их предотвращению и т. д.

Состав информации

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

• непосредственные сведения о ЧС (вид ЧС, дата и место происшествия, объект, на котором произошла катастрофа);

• характеристика ЧС;

• количество пострадавших, в том числе погибших;

• предварительные оценки материального ущерба в стоимостном и натуральном выражении;

• влияние ЧС на жизнедеятельность местного населения, на окружающую среду и функционирование отраслей народного хозяйства;

• возможность или невозможность ликвидации последствий ЧС на месте, ориентировочные сроки такой ликвидации;

• типы и количество единиц оборудования, число специалистов, необходимых для ликвидации последствий ЧС;

• характер и примерные объемы выполняемых работ.

Менее динамичная часть информации – данные о контрольно-измерительных приборах, которые используются при ликвидации последствий ЧС.

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

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

• база данных, разрабатываемая в среде СУБД Access 2002;

• база данных, разработанная ранее в среде Clarion 3.0;

• база данных, разработанная ранее в среде FoxPro 2.5.

Две последние БД конвертируются в Access 2002, и дальнейшая работа с ними рассматривается именно в этой единой программной среде.

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

Что понимать под структуризацией информации

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

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

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

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

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

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

Показатели

Рассмотрим утверждение, которое, согласно нашей классификации, принадлежит к классу фактографической информации. Например, «объем капитальных вложений равен 2,5 млн. руб.» или «стоимость „Мерседеса“ больше, чем стоимость „Жигулей“». Для этого класса данных под показателем понимается единица информации, которая включает ряд реквизитов-признаков и единственный реквизит-основание. Каждый реквизит-признак является мельчайшей неделимой информационной единицей и отражает какой-либо атрибут (свойство) объекта. Например, в энергетике такими реквизитами-признаками являются мощности, электростанции, линии электропередач, организации, расход топлива и т. д. Любой объект характеризуется перечнем свойств, которые выражаются через реквизиты.

Реквизит состоит из имени и значения. Именем реквизита будет название какой-либо качественной (наименование, местонахождение) или количественной характеристики объекта, явления, процесса (объем, размер и т. д.).

Значение реквизита представляет собой элемент данных, например: мощность (реквизит) – 500 МВт (его значение), электростанция (реквизит) – Красноярская ГЭС (значение), линия электропередач (реквизит) – Экибастуз-Центр (значение), расход топлива (реквизит) – 350 тонн (значение).

Совокупность реквизитов-признаков образует наименование показателя, а реквизит-основание представляет количественное или логическое значение показателя. Например, для приведенного выше показателя (мощность Красноярской ГЭС) реквизит-основание – 500 МВт. Очевидно, каждый реквизит-основание описывается одной фразой. В данном случае эта фраза выглядит так: «установленная мощность Красноярской ГЭС в 1998 году равна 500 МВт». (Это не значит, что вся база данных состоит из единственного предложения – такой случай представляется исключительным упрощением!) В следующем разделе будет показано, что реквизиты-признаки, в свою очередь, делятся на ряд категорий.

В общем случае ни один из реквизитов-признаков не может считаться обязательным. Характерной особенностью показателя является то, что он содержит определенный минимум информации, достаточный для создания документа. Ни один из перечисленных выше реквизитов, взятый в отдельности, не позволяет сформировать документ, а вот показатель может быть выдан в качестве справки при ответе на какой-либо запрос – скажем, о мощности Красноярской ГЭС. Верно и обратное – информационную совокупность любой сложности (отчет и т. д.) можно представить как определенную группу различных показателей.