Глава 7. СПРАВОЧНИКИ

Классы, атрибуты, наследование

Каждый регистр счетов привязан к одному справочнику объектов, например , «Товары». Допустим, что мы автоматизируем работу компании, торгующей металлическими изделиями (винтами и т. п.) и обувью. Очевидно, что разные товары могут иметь разные атрибуты. Атрибутами винтов могут быть « Металл», «Диаметр» и «Длина». Атрибутами обуви - «Материал», «Изделие», «Размер », «Цвет» и «Вид». Кроме винтов , возможно, нам понадобится в справочниках хранить разные другие металлические изделия, характеризующиеся «Металлом» и «Наименованием ». К тому же неплохо бы иметь в качестве общего атрибута «Внутренний номер объекта» (ID), чтобы использовать этот атрибут в других таблицах для ссылки на объекты справочной системы. С учетом сказанного, нам необходимы минимум три таблицы для хранения «Товаров»:

«Обувь»

«Винты»

«Разный крепеж»

Как легко заметить, некоторые таблицы имеют общие по смыслу поля. Например, все три таблицы имеют поле ID . Винты и разный крепеж имеют общее поле «Металл ». Напрашивается мысль о том, чтобы хранить однородную информацию в одном месте, а не в разных таблицах. И действительно, если мы введем понятия «Товар вообще » и «Крепеж вообще», то задача намного упростится . Атрибут ID характеризует любой «Товар вообще», а атрибут «Металл» характеризует любой «Крепеж вообще». Можно даже сказать, что классы «Винты» и «Разный крепеж» наследуют атрибут «Металл» от класса «Крепеж вообще». Что же у нас получилось ? Фактически это справочная система с некоторыми объектно-ориентированными свойствами. Все объекты у нас разделены на классы. Собственно, каждый конкретный справочник и есть класс. Классы образуют дерево с наследованием атрибутов старших классов младшими классами. Каждый класс, таким образом, имеет собственные атрибуты и атрибуты, унаследованные от класса-предка. Каждому классу соответствует одна физическая таблица в базе данных, в этой таблице класс хранит только собственные атрибуты. Для полной сборки любого справочника наша программа автоматически производит объединение всех таблиц классов -предков с таблицей класса справочника по полю «Номер объекта» (ID).

Например, если мы хотим создать классы «Товары», «Крепеж», «Винты», «Другой крепеж», «Обувь», то выглядит это примерно так:

Таким образом, для строгого хранения данных, они разносятся по нескольким таблицам. И каждый объект одновременно хранится в разных таблицах. Часть атрибутов справочника «Винты» хранится в таблице класса «Крепеж». Поэтому для того, чтобы отобразить все атрибуты «винтов», как собственные, так и унаследованные от классов-предков, необходима « сборка данных» (по одной строке из разных таблиц ). Например, для сборки справочника «Винты» будут объединены таблицы: «Товары», «Крепеж» и «Винты» по полю ID. А для сборки справочника «Разный крепеж» будут объединены таблицы «Товары », «Крепеж», «Разный крепеж».

К счастью, язык структурированных запросов SQL позволяет делать такие объединения таблиц достаточно быстро. Наша программа устроена так, что сборка справочников происходит автоматически путем генерации текстов SQL- запросов. Ничего программировать не нужно.

Атрибутом класса может быть число, строка, дата, мемо-поле, картинка или ссылка на объект другого класса. В приведенном нами примере, например, поля Материал, Изделие, Цвет и Вид в действительности следует организовать в виде ссылок на отдельные мелкие справочники:

«Материалы для обуви»

«Обувные изделия»

«Цвета»

«Виды обуви»

Итак, в реальности в таблице класса «Обувь» в основном хранятся ссылки:

«Обувь»

Разрешение ссылок (превращение ID в краткие наименования) программа осуществляет автоматически, присоединяя при сборке справочника еще и специальную таблицу наименований, так что пользователь видит нормальную таблицу, содержащую в колонках соответствующие названия, а не внутренние номера , которые реально хранятся в базе. Все объекты справочной системы имеют уникальные внутренние ID, которые поставляет генератор OBJECT _ID_GEN.

Такая организация справочной системы позволяет одновременно решить ряд проблем:

• Регистру счетов достаточно присвоить базовый класс какого-то дерева классов справочной системы и тот сможет работать одновременно со всеми объектами классов-потомков, какой бы атрибутикой те не обладали. А это означает для программиста, конфигурирующего систему под задачу пользователя, возможность быстрого и корректного анализа бухгалтерских данных по любому атрибуту каждого отдельно взятого класса.

• Декларативная ссылочная целостность (на основе ключей foreign keys) пронизывает всю систему ссылок и не позволяет, с одной стороны, случайно удалить ни один объект, используемый в других справочниках или документах, а с другой стороны предельно повышает скорость объединения таблиц при сборке справочников. Важно и другое - сообщение о невозможности удаления объекта пользователь получает мгновенно .

• Ссылочная природа справочников позволяет автоматически подчинять два справочника друг другу , для чего окно справочника делится пополам. В этом режиме в нижней части окна отображаются закладки всех справочников, которые могут быть подчинены справочнику, отображаемому в верхней части . Остается лишь выбрать нужную закладку. Например, перебирая «обувные изделия», можно тут же видеть всю обувь , отфильтрованную по данному признаку. Или, выбрав « Фирму», автоматически видеть все ее реквизиты. И все это без потери скорости, благодаря индексам.

• Всегда можно добавить новый атрибут в класс и его автоматически приобретут все объекты классов-потомков.

• Способ хранения данных соответствует самым строгим требованиям теории реляционной баз данных (степень нормализации 3…5), что значительно упрощает использование данных в SQL-запросах и повышает непротиворечивость хранимой информации и устойчивость данных к изменению структуры справочников.