Access 2002. Самоучитель

Дубнов Павел Юрьевич

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

При простой структуре исходной информации первый этап структуризации – выделение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Р (реквизит-основание) – цена прибора.

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

Тогда приведенная выше фраза-описание будет содержать две однородные фразы с параллельными реквизитами-основаниями – цена и вес.

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

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

• название прибора;

• название фирмы, производящей прибор;

• страна, в которой находится фирма;

• адрес фирмы;

• адрес филиала или дочерней фирмы;

• данные о менеджерах фирмы – фамилия, имя, отчество и адрес;

• номер модели;

• год выпуска прибора;

• номер прибора по каталогу;

• цена прибора;

• функциональное назначение прибора;

• вес прибора;

• категория прибора (переносной, портативный и т. п.);

• характеристика прибора.

Параметры, которые для пользователя второстепенны, остаются в общем тексте раздела.

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

• П (показатели) – «выявлено», «выдано», «сжигание» и др.;

• О1 (объект) – источники загрязнения (нефтеналивные цистерны);

• О2 (объект) – загрязняющие вещества (нефть);

• О3 (объект) – объекты загрязнения (рельеф местности);

• О4 (объект) – документы (предписание о ликвидации последствий аварии);

• У1 (уточнение места действия 1) – железнодорожные станции (Ангасолка);

• У2 (уточнение места действия 2) – железные дороги (Восточно-Сибирская);

• У3 (обстоятельство действия 1) – под контролем комиссии;

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

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

Проектирование логической структуры базы данных

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