Access 2002. Самоучитель
Шрифт:
Эти соображения, как уже говорилось, определяют ту границу, до которой имеет смысл проводить структуризацию. Если выясняется, что какие-то словосочетания слишком индивидуальны, уникальны и не поддаются классификации, их не следует включать в словари. В приведенном выше сообщении это формулировки типа «на северной части балластной призмы в кювете с четной стороны, примыкающей к горе, и в кармане водоотводной канавы»; «на другой стороне ж/д полотна (на откосе)». Для таких данных надо использовать специальные поля примечаний, прикрепленных к соответствующей конкретной записи.
При простой структуре исходной информации первый этап структуризации – выделение
Пример структуризации данных
Рассмотрим практический пример. Вы занимаетесь структуризацией информации при проектировании базы данных по контрольно-измерительным приборам, которые выпускаются различными фирмами. Это довольно простая БД, и каждая запись в ней выглядит так: «Прибор (название), с номером модели (номер), произведенный в (год) году фирмой (название), которая находится в стране (название) по адресу (приводится адрес) и имеет филиал по адресу (приводится адрес), предназначенный для (целевое назначение), имеющий характеристики (перечень технических характеристик), включенный в каталог под номером (номер в каталоге) и обслуживаемый менеджером (данные о менеджере), имеет цену (приводится цена)». Конечно, фраза громоздкая и не слишком гладкая. Поэтому ее стоит разбить на более простые фрагменты. Любой пользователь, заказчик или разработчик базы данных легко может внести в нее необходимые изменения. Ниже будет показано, как это делается.
Итак, информация о приборах включает следующие пункты:
• О (объект) – название прибора;
• У (уточнение сведений об объекте) – номер модели. Если при анализе сообщения возникает необходимость в нескольких уточнениях, то им можно присвоить номера;
• У (уточнение сведений об объекте) – год выпуска прибора;
• У (уточнение сведений об объекте) – номер прибора по каталогу;
• У (уточнение сведений об объекте) – характеристика прибора, содержащая данные о его функциях, портативности, технических особенностях, весе, точности, способе питания, диапазоне измерений, совместимости с другими приборами;
• С (субъект) – название фирмы, производящей прибор;
• У (уточнение сведений о субъекте) – страна, в которой находится фирма;
• У (уточнение сведений о субъекте) – адрес фирмы;
• У (уточнение сведений о субъекте) – адрес филиала или дочерней фирмы, если такая есть;
• У (уточнение сведений о субъекте) – данные о менеджерах фирмы (фамилия, имя, отчество и адрес);
• Р (реквизит-основание) – цена прибора.
Предположим, пользователя в первую очередь интересует не только цена, но и вес прибора. Этот параметр можно выделить из общего массива «характеристика» и придать ему статус еще одного реквизита-основания. Тогда приведенная выше фраза-описание будет содержать две однородные фразы с параллельными реквизитами-основаниями – цена и вес.
В рассмотренном примере структура информации достаточно проста, и нужные словари могут быть сформированы практически сразу, на первом этапе проектирования. Создавая их и уточняя перечень основных реквизитов-признаков, руководствуйтесь следующим критерием: часто ли у пользователя будет необходимость запрашивать информацию по данному признаку. Если да, то имеет смысл выделить его как отдельный реквизит и сформировать соответствующий словарь. Такой признак называется ключевым значением, или дескриптором. В базе данных ему лучше выделить отдельный файл или поле в файле; этим вы существенно облегчите работу будущему пользователю. Конечно, если какой-либо признак «спрятан» в общем тексте, по нему тоже можно сделать запрос, но сформировать последний в этом случае сложнее.
В нашем примере можно сразу выделить те признаки, по которым следует ожидать частого обращения к базе данных:
• название прибора;
• название фирмы, производящей прибор;
• страна, в которой находится фирма;
• адрес фирмы;
• адрес филиала или дочерней фирмы;
• данные о менеджерах фирмы – фамилия, имя, отчество и адрес;
• номер модели;
• год выпуска прибора;
• номер прибора по каталогу;
• цена прибора;
• функциональное назначение прибора;
• вес прибора;
• категория прибора (переносной, портативный и т. п.);
• характеристика прибора.
Параметры, которые для пользователя второстепенны, остаются в общем тексте раздела.
Возьмем пример посложнее, который представлен в разделе «Необходимость структуризации». Здесь описание включает не одну, а несколько фраз, и анализ, подобный предыдущему, надо провести отдельно для каждой из них. В результате мы получим следующий набор признаков:
• П (показатели) – «выявлено», «выдано», «сжигание» и др.;
• О1 (объект) – источники загрязнения (нефтеналивные цистерны);
• О2 (объект) – загрязняющие вещества (нефть);
• О3 (объект) – объекты загрязнения (рельеф местности);
• О4 (объект) – документы (предписание о ликвидации последствий аварии);
• У1 (уточнение места действия 1) – железнодорожные станции (Ангасолка);
• У2 (уточнение места действия 2) – железные дороги (Восточно-Сибирская);
• У3 (обстоятельство действия 1) – под контролем комиссии;
• П (примечания) – как уже говорилось, в этих полях должны содержаться данные – уточнения, специфичные для конкретных сообщений.
Таким образом, по мере накопления новых сообщений будут появляться и новые реквизиты, а количество параметров, указанных в скобках, тоже будет расти.
Проектирование логической структуры базы данных
Итак, мы определили состав дескрипторов, то есть ключевых полей для поиска, по которым чаще всего (по нашему прогнозу) будут формироваться запросы к базе данных. Теперь начнем разработку логической структуры БД. Под логической структурой понимается та совокупность файлов, содержащихся в них полей и связей между файлами, которую «видит» пользовательская программа, обрабатывающая базу данных.