В той или иной степени специфика разных версий 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 МВт". (Это не значит, что вся база данных состоит из единственного предложения – такой случай представляется исключительным упрощением!) В следующем разделе будет показано, что реквизиты-признаки, в свою очередь, делятся на ряд категорий.
В общем случае ни один из реквизитов-признаков не может считаться обязательным. Характерной особенностью показателя является то, что он содержит определенный минимум информации, достаточный для создания документа. Ни один из перечисленных выше реквизитов, взятый в отдельности, не позволяет сформировать документ, а вот показатель может быть выдан в качестве справки при ответе на какой-либо запрос – скажем, о мощности Красноярской ГЭС. Верно и обратное – информационную совокупность любой сложности (отчет и т. д.) можно представить как определенную группу различных показателей.
Из сказанного ясно, зачем нужна предварительная структуризация информации пользователям, работающим с конкретной базой данных в определенной предметной области. Им необходима возможность формировать по единым правилам разнообразные запросы и получать на них ответы. (Примеры таких запросов и ответов будут приведены в главе 9.) Отсюда, между прочим, следует, что структуризация данных имеет свои разумные пределы. Разработчик банка данных, разбив исходную информацию на ряд категорий-реквизитов, уверен, что дальше делить данный реквизит не имеет смысла, потому что такие запросы пользователя маловероятны. Можно и остановиться. Однако, если впоследствии пользователю действительно потребуется задать специфический запрос, сделать это будет гораздо сложнее. Подобные варианты тоже будут рассмотрены ниже. Поэтому искусство разработчика состоит, в частности, в том, чтобы определить требуемую "золотую середину".
Необходимость структуризации
В качестве примера в книге рассматривается информация о фактически происшедших ЧС. Эти сведения могут поступать в виде сообщений по различным информационным каналам:
• по телефону из соответствующих региональных структур (телефонограммы). В этом случае информация вручную вводится в БД;
• по телефонному каналу связи, когда информация автоматически вводится в БД;
• по электронной почте, когда информация, при необходимости, может быть переформирована в памяти компьютера перед вводом в БД;
• по почте. Данные вводятся в БД вручную.
Информация поступает в самой различной форме, например в таком произвольном виде (реальное сообщение): "На ж/д станции Ангасолка ВосточноСибирской железной дороги (ВСЖД) в ночь с 23 на 24 марта 1999 г. допущен сход двух нефтеналивных цистерн по 60 тонн каждая, с разливом сырой нефти в одной из цистерн от 30 до 40 тонн. Произошло самовоспламенение. Основная часть нефти разлилась на северной части балластной призмы в кювете счетной стороны, примыкающей к горе, и в кармане водоотводной канавы объемом 3x4x3,5 м. Кроме того, разлитая нефть выгорела на ж/д полотне площадью 230x9 м. На другой стороне ж/д полотна (на откосе) площадью 30x50 м происходило сжигание нефти под контролем пожарного надзора ВСЖД. Нефть застыла на снежном покрове двумя рукавами длиной по 100 метров и шириной 0,5 до 1 метра. Дополнительно выявлено еще два очага загрязнения площадью 5x2 и 5x10 м. К очистке рельефа местности от нефти привлечено 70 человек. Выдано предписание о ликвидации загрязнения с решением вопроса утилизации нефти. После проведения работ по зачистке загрязненной территории провести ее обследование комиссионно". (Имеется в виду, что обследование должно проводиться комиссией.)
Можно включать подобные сведения в БД в том виде, в каком они пришли. Такое решение вполне приемлемо, но только на начальном этапе. Рано или поздно поступившую информацию придется обрабатывать, а иметь дело с такими "сырыми" данными довольно трудно.
Конечно, можно регламентировать форму входных сообщений так, чтобы содержащиеся в них сведения были структурированы. Этот способ используется довольно широко, но он не гарантирует четкой формализации исходных данных. Дело в том, что первичное заполнение стандартных бланков производят рядовые сотрудники на местах, поэтому неизбежна значительная доля субъективизма. Это приводит к необходимости централизованной структуризации показателей при разработке и формировании банка данных.
Технология структуризации
Проведенные исследования показали, что обычно в обязательный минимум реквизитов-признаков входят следующие:
• П – процесс – основное наименование деятельности органа управления (операция, состояние). Это суть показателя (расход, остатки, поставка, капитальные вложения, мощность, ущерб и т. д.);
• Ф – формальная характеристика, то есть выраженный в наименовании способ расчета показателя (доля, темп роста, отклонение, сумма, прирост, среднее и средневзвешенное значения и т. п.), который может быть как относительным, так и абсолютным и тесно связан с процессом (иногда задан в нем неявно);
• О – объект, предмет операции; то, над чем она выполняется (материалы, изделия, полуфабрикаты, строительная продукция и т. д.);
• Е – единица измерения;
• С – субъект (тот, кто производит действия над объектом). Если, например, объект (О) – продукция, а основное наименование деятельности (П) – производство, то в роли субъекта (С) может выступать, например, предприятие, отрасль и т. д.;
• В – время (дата, период);
• Ф – функция управления (проектное, прогнозное или фактическое значение, норматив и т. п.).
Естественно, все многообразие реальных признаков не укладывается в приведенный краткий перечень. Поэтому каждый из названных реквизитов допускает практически неограниченное количество любых категорий-уточнений, которые должны удовлетворять единственному условию – представлять собой списки, состоящие из однородных терминов. Обычно уточняются следующие вопросы:
• где – в этом случае список уточнений характеризует место действия;
• как – список уточнений характеризует обстоятельства действия;
• какой – список уточнений характеризует свойство.
Сформированные таким образом списки при проектировании банка данных рассматриваются как словари. По сути, цель структуризации – создание словарей. При последующей разработке логической структуры БД они служат как бы осями координат, по которым организуется, "раскладывается" реальная информация.
Эти соображения, как уже говорилось, определяют ту границу, до которой имеет смысл проводить структуризацию. Если выясняется, что какие-то словосочетания слишком индивидуальны, уникальны и не поддаются классификации, их не следует включать в словари. В приведенном выше сообщении это формулировки типа "на северной части балластной призмы в кювете с четной стороны, примыкающей к горе, и в кармане водоотводной канавы"; "на другой стороне ж/д полотна (на откосе)". Для таких данных надо использовать специальные поля примечаний, прикрепленных к соответствующей конкретной записи.
При простой структуре исходной информации первый этап структуризации – выделение основных реквизитов-признаков – можно пропустить и сразу формировать словари. Однако учтите, что о простоте или сложности структуры исходной информации нельзя говорить вообще – это понятие имеет смысл только с одной точки зрения: легко ли будет пользователю получать ответы на запросы к БД. Поэтому прежде чем приступать к анализу первичной информации, подумайте: кто будет работать с проектируемой базой данных, какие сведения понадобятся пользователю и какими будут его запросы. В этом требовании нет ничего нового – это одно из классических положений проектирования баз данных. Но уже на начальных стадиях, при введении некоторой формализации в структуры данных, вы убедитесь, насколько важно следовать этому правилу.
Пример структуризации данных
Рассмотрим практический пример. Вы занимаетесь структуризацией информации при проектировании базы данных по контрольно-измерительным приборам, которые выпускаются различными фирмами. Это довольно простая БД, и каждая запись в ней выглядит так: "Прибор (название), с номером модели (номер), произведенный в (год) году фирмой (название), которая находится в стране (название) по адресу (приводится адрес) и имеет филиал по адресу (приводится адрес), предназначенный для (целевое назначение), имеющий характеристики (перечень технических характеристик), включенный в каталог под номером (номер в каталоге) и обслуживаемый менеджером (данные о менеджере), имеет цену (приводится цена)". Конечно, фраза громоздкая и не слишком гладкая. Поэтому ее стоит разбить на более простые фрагменты. Любой пользователь, заказчик или разработчик базы данных легко может внести в нее необходимые изменения. Ниже будет показано, как это делается.
Итак, информация о приборах включает следующие пункты:
• О (объект) – название прибора;
• У (уточнение сведений об объекте) – номер модели. Если при анализе сообщения возникает необходимость в нескольких уточнениях, то им можно присвоить номера;
• У (уточнение сведений об объекте) – год выпуска прибора;
• У (уточнение сведений об объекте) – номер прибора по каталогу;
• У (уточнение сведений об объекте) – характеристика прибора, содержащая данные о его функциях, портативности, технических особенностях, весе, точности, способе питания, диапазоне измерений, совместимости с другими приборами;
• С (субъект) – название фирмы, производящей прибор;
• У (уточнение сведений о субъекте) – страна, в которой находится фирма;
• У (уточнение сведений о субъекте) – адрес фирмы;
• У (уточнение сведений о субъекте) – адрес филиала или дочерней фирмы, если такая есть;