Павел Дубнов - Access 2002: Самоучитель

• Название: Access 2002: Самоучитель
• Автор: Павел Дубнов
• Жанр: Программы

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

Подробно описывается методика проектирования объектов базы данных (таблицы, формы, отчеты, страницы доступа к данным, запросы, модули).

Детально обсуждаются вопросы создания интегрированной базы данных в единой среде Access 2002: формирование БД с нуля, конвертирование в программную среду баз данных, созданных в ином программном окружении – Clarion, FoxPro.

Особое внимание уделяется формированию разнообразных запросов к интегрированной базе данных Access 2002 с использованием языков программирования SQL, VBA и макросов.

Приводятся общие сведения о возможностях языка обмена данными между различными компьютерами и приложениями (XML). Описываются возможности использования гиперссылок, связывающих базу данных с другими программными продуктами. Объясняется, как можно работать с базой данных Access 2002 без установки ее на компьютер, используя технологию ODBC (Open Data Base Connectivity). В приложениях приводятся количественные параметры Access 2002 и связанная с этой СУБД терминология.

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

---

Из сказанного ясно, зачем нужна предварительная структуризация информации пользователям, работающим с конкретной базой данных в определенной предметной области. Им необходима возможность формировать по единым правилам разнообразные запросы и получать на них ответы. (Примеры таких запросов и ответов будут приведены в главе 9.) Отсюда, между прочим, следует, что структуризация данных имеет свои разумные пределы. Разработчик банка данных, разбив исходную информацию на ряд категорий-реквизитов, уверен, что дальше делить данный реквизит не имеет смысла, потому что такие запросы пользователя маловероятны. Можно и остановиться. Однако, если впоследствии пользователю действительно потребуется задать специфический запрос, сделать это будет гораздо сложнее. Подобные варианты тоже будут рассмотрены ниже. Поэтому искусство разработчика состоит, в частности, в том, чтобы определить требуемую «золотую середину».

Необходимость структуризации

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

• по телефону из соответствующих региональных структур (телефонограммы). В этом случае информация вручную вводится в БД;

• по телефонному каналу связи, когда информация автоматически вводится в БД;

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

• по почте. Данные вводятся в БД вручную.

Информация поступает в самой различной форме, например в таком произвольном виде (реальное сообщение): «На ж/д станции Ангасолка ВосточноСибирской железной дороги (ВСЖД) в ночь с 23 на 24 марта 1999 г. допущен сход двух нефтеналивных цистерн по 60 тонн каждая, с разливом сырой нефти в одной из цистерн от 30 до 40 тонн. Произошло самовоспламенение. Основная часть нефти разлилась на северной части балластной призмы в кювете счетной стороны, примыкающей к горе, и в кармане водоотводной канавы объемом 3x4x3,5 м. Кроме того, разлитая нефть выгорела на ж/д полотне площадью 230x9 м. На другой стороне ж/д полотна (на откосе) площадью 30x50 м происходило сжигание нефти под контролем пожарного надзора ВСЖД. Нефть застыла на снежном покрове двумя рукавами длиной по 100 метров и шириной 0,5 до 1 метра. Дополнительно выявлено еще два очага загрязнения площадью 5x2 и 5x10 м. К очистке рельефа местности от нефти привлечено 70 человек. Выдано предписание о ликвидации загрязнения с решением вопроса утилизации нефти. После проведения работ по зачистке загрязненной территории провести ее обследование комиссионно». (Имеется в виду, что обследование должно проводиться комиссией.)

Можно включать подобные сведения в БД в том виде, в каком они пришли. Такое решение вполне приемлемо, но только на начальном этапе. Рано или поздно поступившую информацию придется обрабатывать, а иметь дело с такими «сырыми» данными довольно трудно.

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

Технология структуризации

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

• П – процесс – основное наименование деятельности органа управления (операция, состояние). Это суть показателя (расход, остатки, поставка, капитальные вложения, мощность, ущерб и т. д.);

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

• О – объект, предмет операции; то, над чем она выполняется (материалы, изделия, полуфабрикаты, строительная продукция и т. д.);

• Е – единица измерения;

• С – субъект (тот, кто производит действия над объектом). Если, например, объект (О) – продукция, а основное наименование деятельности (П) – производство, то в роли субъекта (С) может выступать, например, предприятие, отрасль и т. д.;

• В – время (дата, период);

• Ф – функция управления (проектное, прогнозное или фактическое значение, норматив и т. п.).

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

• где – в этом случае список уточнений характеризует место действия;

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

• какой – список уточнений характеризует свойство.

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

Эти соображения, как уже говорилось, определяют ту границу, до которой имеет смысл проводить структуризацию. Если выясняется, что какие-то словосочетания слишком индивидуальны, уникальны и не поддаются классификации, их не следует включать в словари. В приведенном выше сообщении это формулировки типа «на северной части балластной призмы в кювете с четной стороны, примыкающей к горе, и в кармане водоотводной канавы»; «на другой стороне ж/д полотна (на откосе)». Для таких данных надо использовать специальные поля примечаний, прикрепленных к соответствующей конкретной записи.

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

Пример структуризации данных

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

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

• О (объект) – название прибора;

• У (уточнение сведений об объекте) – номер модели. Если при анализе сообщения возникает необходимость в нескольких уточнениях, то им можно присвоить номера;

• У (уточнение сведений об объекте) – год выпуска прибора;

• У (уточнение сведений об объекте) – номер прибора по каталогу;

• У (уточнение сведений об объекте) – характеристика прибора, содержащая данные о его функциях, портативности, технических особенностях, весе, точности, способе питания, диапазоне измерений, совместимости с другими приборами;

• С (субъект) – название фирмы, производящей прибор;

• У (уточнение сведений о субъекте) – страна, в которой находится фирма;

• У (уточнение сведений о субъекте) – адрес фирмы;