Реквизит состоит из имени и значения. Именем реквизита будет название какой-либо качественной (наименование, местонахождение) или количественной характеристики объекта, явления, процесса (объем, размер и т. д.).
Значение реквизита представляет собой элемент данных, например: мощность (реквизит) – 500 МВт (его значение), электростанция (реквизит) – Красноярская ГЭС (значение), линия электропередач (реквизит) – Экибастуз-Центр (значение), расход топлива (реквизит) – 350 тонн (значение).
Совокупность реквизитов-признаков образует наименование показателя, а реквизит-основание представляет количественное или логическое значение показателя. Например, для приведенного выше показателя (мощность Красноярской ГЭС) реквизит-основание – 500 МВт. Очевидно, каждый реквизит-основание описывается одной фразой. В данном случае эта фраза выглядит так: «установленная мощность Красноярской ГЭС в 1998 году равна 500 МВт». (Это не значит, что вся база данных состоит из единственного предложения – такой случай представляется исключительным упрощением!) В следующем разделе будет показано, что реквизиты-признаки, в свою очередь, делятся на ряд категорий.
В общем случае ни один из реквизитов-признаков не может считаться обязательным. Характерной особенностью показателя является то, что он содержит определенный минимум информации, достаточный для создания документа. Ни один из перечисленных выше реквизитов, взятый в отдельности, не позволяет сформировать документ, а вот показатель может быть выдан в качестве справки при ответе на какой-либо запрос – скажем, о мощности Красноярской ГЭС. Верно и обратное – информационную совокупность любой сложности (отчет и т. д.) можно представить как определенную группу различных показателей.
Из сказанного ясно, зачем нужна предварительная структуризация информации пользователям, работающим с конкретной базой данных в определенной предметной области. Им необходима возможность формировать по единым правилам разнообразные запросы и получать на них ответы. (Примеры таких запросов и ответов будут приведены в главе 9.) Отсюда, между прочим, следует, что структуризация данных имеет свои разумные пределы. Разработчик банка данных, разбив исходную информацию на ряд категорий-реквизитов, уверен, что дальше делить данный реквизит не имеет смысла, потому что такие запросы пользователя маловероятны. Можно и остановиться. Однако, если впоследствии пользователю действительно потребуется задать специфический запрос, сделать это будет гораздо сложнее. Подобные варианты тоже будут рассмотрены ниже. Поэтому искусство разработчика состоит, в частности, в том, чтобы определить требуемую «золотую середину».
Необходимость структуризации
В качестве примера в книге рассматривается информация о фактически происшедших ЧС. Эти сведения могут поступать в виде сообщений по различным информационным каналам:
• по телефону из соответствующих региональных структур (телефонограммы). В этом случае информация вручную вводится в БД;
• по телефонному каналу связи, когда информация автоматически вводится в БД;
• по электронной почте, когда информация, при необходимости, может быть переформирована в памяти компьютера перед вводом в БД;