Что такое справочник в базе данных
Справочники
Справочники — это прикладные объекты конфигурации. Они позволяют хранить в информационной базе данные, имеющие одинаковую структуру и списочный характер. Это может быть, например, список сотрудников, перечень товаров, список поставщиков или покупателей.
Структура справочника
Каждый элемент справочника характеризуется кодом и наименованием. Система поддерживает режим автоматической нумерации элементов, при котором она самостоятельно может генерировать код для нового элемента справочника. Кроме этого система позволяет осуществлять контроль уникальности кодов справочника, не разрешая создавать элементы с одинаковыми кодами:
Помимо кода и наименования, каждый элемент справочника, как правило, содержит некоторую дополнительную информацию, которая подробно описывает этот элемент. Например, для товара это может быть информация об артикуле, упаковке и т. п. Набор такой информации является одинаковым для всех элементов конкретного справочника, и для ее хранения служат реквизиты справочника:
Кроме этого, каждый элемент справочника может содержать некоторый набор информации, которая одинакова по своей структуре, но различна по количеству, для разных элементов справочника. Например, для каждого сотрудника в справочнике Физические лица это может быть контактная информация или информация о составе семьи, образовании. Для хранения подобных данных служат табличные части справочника:
Справочники могут поддерживать иерархическое расположение элементов. Например, в справочнике Номенклатура могут быть созданы группы: Бытовая техника, Обувь, Продукты и т. д., в которых располагаются элементы, относящиеся к этим группам. Кроме того группы справочника могут включать в себя и другие группы, создавая тем самым многоуровневую иерархическую структуру.
В справочниках возможен и другой вид иерархии, при котором элементы справочника будут относиться не к группам, а к другим элементам этого же справочника. Такой вид иерархии может использоваться, например, при создании справочника Задачи, где одна задача может включать в себя несколько других задач.
Разные справочники могут находиться в состоянии подчинения, т. е. элементы одного справочника могут быть подчинены элементам или группам другого справочника. Например, справочник Кассы может быть подчинен справочнику Организации. Тогда при оформлении кассовых документов для некоторой организации можно будет выбрать кассу не среди всех имеющихся в программе касс, а среди касс, существующих только в этой организации:
Справочники допускают также создание предопределенных элементов, которые существуют в справочнике всегда, вне зависимости от действий пользователя. Такие элементы справочника создаются разработчиком при разработке прикладного решения и не могут быть удалены или перемещены пользователем.
Например, если в основном прикладное решение будет внедряться на предприятиях одного государства, России, в справочник Страны мира сразу же можно добавить предопределенный элемент Россия, поскольку он понадобится подавляющему большинству пользователей.
Формы справочника
Для того чтобы пользователь мог просматривать и изменять данные, содержащиеся в справочнике, система поддерживает несколько форм представления справочника. Система может автоматически генерировать все нужные формы справочника. Наряду с этим разработчик имеет возможность создать собственные формы, которые система будет использовать вместо форм по умолчанию:
Форма списка
Для просмотра данных, содержащихся в справочнике, используется форма списка. Она позволяет выполнять навигацию по справочнику, добавлять, помечать на удаление и удалять элементы и группы справочника, перемещать элементы и группы. Форма списка может представлять данные в иерархическом и не иерархическом виде и позволяет выполнять сортировку и отбор отображаемой информации по нескольким критериям:
Форма элемента
Для просмотра и изменения данных отдельных элементов справочника используется форма элемента. Как правило, она представляет данные в удобном для восприятия и редактирования виде:
Форма группы
Система поддерживает отдельный вид формы для групп справочника. Это связано с тем, что, как правило, состав информации, относящейся к группе справочника, намного меньше, чем состав данных, имеющих отношение к отдельным элементам справочника:
Форма выбора, форма выбора группы
При различных действиях пользователя в прикладном решении возникает необходимость выбора конкретных элементов справочников. Это может потребоваться, например, при создании приходной накладной, в которой должны быть перечислены определенные товары. В этом случае система использует форму выбора справочника, которая, обычно, содержит минимальный набор информации, необходимой для выбора того, или иного элемента:
Кроме всех перечисленных форм, система поддерживает еще форму выбора группы справочника, предназначенную для выбора только среди групп, содержащихся в справочнике.
Макеты
Справочнику могут быть сопоставлены несколько макетов, содержащих данные, необходимые для обеспечения работы справочника:
Макеты могут использоваться для формирования печатных форм справочника или для отображения дополнительной информации, имеющей отношение к справочнику.
БД. Справочники. Примеры на MUMPS (Caché Object Script)
На хабре часто можно встретить различные статьи о том как сделано то или то, с непосредственной реализацией, кодом, примерами, обоснованиями (пусть даже спорными). Кто-то выкладывает пример контролла, кто-то даёт практические советы по яваскрипту. Однако я не видел, чтобы кто-нибудь, рассказывал об организации структуры БД. Дальше каких-то школьных примеров это не заходит (если ошибаюсь поправьте и дайте ссылки). Нет, холивары SQL vs NoSQL меня не интересуют. По моему скромному убеждению — СУБД вторична в вопросах организации БД. Вопросы производительности конкретных СУБД становятся актуальными далеко не сразу. Какая бы ни была выбрана СУБД, под определённую задачу, к производительности предъявляется всего одно требование — производительность должна быть достаточной. А вот пути достижения этой самой достаточности, способы удобно и красиво разместить данные — чтобы быстро и легко их извлекать, организация справочников и индексов, ввода и вывода, способы масштабирования и/или изменения структуры БД в течении жизни, используемые методики, решённые и нерешённые проблемы, полезные рецепты и советы — это всё то, о чём я хочу поговорить.
Разработка структур БД очень интересный и нетривиальный процесс. В этой обширной области встречается мало живых примеров, которые можно посмотреть, обсудить. Неужели вам, разработчики БД, всегда всё ясно что и как делать? Давайте делиться знаниями, давайте спрашивать, рассказывать, обсуждать, узнавать. Какая разница таблица или объект или глобал — важно какой смысл вкладывается, какие связи выстраиваются, какими средствами эти связи реализовываются.
Пару дней назад был опубликован перевод, в котором мой подход, к программированию БД, называли экстремальным — я с этим не совсем согласен. В комментариях, было как минимум три человека (@Ogoun uaoleg 4dmonster), которые сказали, что им было бы интересно посмотреть на живое использование MUMPS и узнать почему не надо бояться глобалов. Для этих людей и всех тех, кому интересно обсудить затронутые мной темы, я и пишу данную статью.
Определение:
Требования:
Быстро получить название элемента справочника — означает не искать. То есть просто прочитать в известном месте и выдать. Это говорит о том, что, к медленно меняющейся информации обращаются часто. Ответ надо выдавать быстро. Как это делается в Caché я покажу далее. Если какой-то там специализированный поиск (найти все города на букву А удалённые от города N не более чем на x км) — ещё может себе позволить кушать процессорное время — то выдача названия элемента справочника — нет.
Изменение названия элемента справочника в одном месте означает что операция updateName по сложности и времени выполнения, аналогична операции retrieve, за исключением случаев, когда требуется проверка на допустимость нового имени. Но даже в этом случае никакая перестройка и переиндексация больших наборов данных, в которых используется данный элемент справочника, не требуется. Это логично вытекает из одной простой особенности любых справочников и вообще данных — в названиях могут быть ошибки. То есть вы можете спроектировать разработать и запустить систему, любой степени сложности и нужности, а через какое-то время, окажется, что допущена ошибка в названии. Вам надо эту ошибку исправить. Вы не хотите проверять и долго переиндексировать всю, или большую часть, вашей системы для исправления этой ошибки. Вы не хотите чтобы старые/новые аналитические/оперативные отчёты или статистика — перестали согласовываться друг с другом из-за изменения одного названия. Вы не хотите заново генерировать seo и прочие шаблоны страниц вашего сайта. Вы хотите изменить одно название в одном месте и забыть об этом. Конечно, большинству разработчиков БД, наверное, это моё требование, покажется очевидным, и не заслуживающим такого большого количества букв. Но оказалось, на практике, оно выполняется значительно реже, чем можно себе представить.
Дополнительные требования предоставляемые к справочнику:
Хранение истории изменений элементов справочника — функциональность, которая требуется не всегда, реализовывается она чуть сложнее, чем многоязычность или изменение имени. Эта функциональность влечёт за собой увеличение времени, требуемого на изменение элемента справочника. Однако, при грамотной реализации, это время увеличивается незначительно. Также, исходя из того, что справочник, это медленно меняющаяся информация, ничего страшного в более длительном изменении элемента нет.
Реализация
Давайте внимательно посмотрим на то что мы вывели. Итак мы распечатали все элементы справочника TransmissionType онтологии Vehicle. Как видно в данном справочнике всего два элемента с идентификаторами 1 и 2. Также очевидно, раз 4й индекс — только 0 — то все элементы этого справочника актуальны, и после добавления ни разу не изменялись (истории нет). У каждого элемента справочника есть всего два свойства: UpdateTime (дата и время обновления в формате Caché) и uid (идентификатор пользователя сделавшего изменение). Ещё раз обратите внимание на практически полное отсутствие служебных слов и символов в команде и результате.
Как видим в нашем справочнике не хватает чего-то важного — а именно названий. Пусть названия всех элементов всех справочников на всех языках хранятся в глобале ^NameDictionaryElement
Как видим оба элемента имеют названия на двух языках ru — русский, partUri — используется в урле. Также видим что названия после добавления не изменялись — истории нет (есть только нулевая текущая версия).
Retrieve
Теперь напишем простейшую программу Dictionary и добавим в неё функцию(метод) retrieve — которая будет возвращать название элемента справочника на требуемом языке и требуемой версии (код из живого проекта):
q — сокращённое написание команды quit — (аля return)
$g — сокращённое написание команды $get — то есть безопасное обращение к переменной, если по заданным индексам не будет значения — вернётся умолчание заданное после запятой, в нашем случае пустая строка «»
Конечно эти примеры, не далеко ушли от «школьных». В дальнейшем я планирую рассказать как устроены глобалы индексов, как создавать глобалы правил и программы работающие с этими правилами. Справочники будут иметь более сложные структуры. Но имена этих глобалов останутся прежними (будут просто добавлятся новые) — они действительно используются в живом проекте, и метод retrieve тоже. Обо всём этом в следующих статьях.
Тема 1.4 Справочники
Дата добавления: 2013-12-24 ; просмотров: 2254 ; Нарушение авторских прав
Контрольные вопросы
1. Что такое подсистема?
2. Роль подсистемы в интерфейсе пользователя?
3. Где в древе объектов находится структура подсистем?
4. Для чего существует Имя подсистемы и Синоним подсистемы?
5. Как редактируется порядок разделов?
Сегодня Вы узнаете, что такое Справочник и как он используется, какова его структура и какими основными свойствами он обладает.
Кроме того, Вы узнаете еще об объекте конфигурации Форма. Узнаете ее виды и в каких ситуациях она используется.
Объект конфигурации Справочник используется для работы со списками данных. В любой работе фирмы используются различные списки: сотрудников, товаров, клиентов, поставщиков и т.д. Свойства и структура этих списков описывается в объектах конфигурации Справочник, на основе которых платформа создает в базе таблицы для хранения информации из этих справочников.
Справочник состоит из элементов. Например, для справочника Сотрудники элементом является сотрудник, для справочника товаров – товар и т.д. Пользователь может в процессе работы добавлять новые элементы в справочник, т.е. пополнить список сотрудников или товаров.
В БД каждый элемент справочника представляет собой отдельную запись в основной таблице, хранящей информацию из этого справочника.
Каждый элемент справочника имеет дополнительную информацию, которая подробнее описывает этот элемент. Например, товар может содержать информацию о производителе, сроке годности, условиях поставки т.п. Набор такой информации является одинаковым для всех элементов и для их описания используются Реквизиты – объект конфигурации Справочник, который так же является объектом конфигурации.
Поскольку эти объекты конфигурации логически связаны с объектом Справочник, они называются подчиненными этому объекту.
Большинство реквизитов разработчик создает самостоятельно, однако у каждого объекта конфигурации Справочник по умолчанию существует набор стандартных реквизитов: Код, Наименование и т.д. Причем доступность каждых реквизитов зависит от свойств справочника.
Например, если справочник иерархический, то у него будет доступен стандартный реквизит Родитель. Если справочник подчинен другому объекту конфигурации, то доступен реквизит Владелец. Если у стандартного реквизита Код выставить длину 0, то у справочника он будет недоступен. То же самое и к реквизиту Наименование. Однако или Код или Наименование должны присутствовать обязательно иначе справочник не имеет смысла.
Отсюда следует, что справочник в БД хранится в виде таблицы, в строках которой расположены элементы списка, а каждому реквизиту (Стандартному или разработанному) в этой таблице соответствует отдельный столбец, а в ячейках таблицы хранится информация конкретного реквизита для конкретного элемента справочника.
Каждый элемент справочника может содержать некоторый набор информации, которая одинакова по все структуре, но различна по количеству и предназначена для разных элементов справочника.
Например, каждый элемент справочника Сотрудники может содержать информацию о составе семьи сотрудника, для одного сотрудника это будет только супруга, а для другого супруга, сын, для третьего – супруга, дочь старшая, дочь младшая и т.д.
Для описания подобной информации могут быть использованы табличные части объекта конфигурации Справочник, являющиеся подчиненными ему объектами конфигурации. В этом случае в БД будут созданы дополнительные таблицы для хранения табличных частей, подчиненных конкретному элементу справочника.
Система при этом «скрывает» от разработчика всю техническую часть связанную с хранением данных: в БД для справочника создаются несколько таблиц, эти таблицы связываются по уникальному полю (Ссылка), поля таблиц имеют определенные типы и т.д. Все это система делает сама. Нужно только добавить в объект конфигурации Справочник подчиненный ему объект Табличная часть.
Для удобства использования элементы справочника могут быть сгруппированы пользователем по какому-либо принципу.
Например, в справочнике Товары могут быть созданы следующие группы: молочные продукты, консервы, бытовая химия, кондитерские изделия и т.д. Возможность создания таких групп в справочнике задается свойством «Иерархический» объекта конфигурации Справочник. В этом случае элемент справочника, представляющий собой группу, будет является Родителем для всех элементов и групп, входящих в эту группу. Этот вид иерархии называется Иерархия групп и элементов.
Есть и другой вид иерархии – Иерархия элементов. В этом случае в качестве родителя выступает не группа элементов справочника, а непосредственно один из его элементов. Например, Подразделения, когда одно подразделение является родителем других, входящих в его состав.
Иногда возникают ситуации, когда необходимо, чтобы в справочнике некоторые элементы существовали всегда, независимо от действий пользователя. Например, последовательность действий на предприятии такова, что все товары поступают на основной склад, а затем по мере необходимости перемещаются на другие склады. В этом случае в справочнике Склады всегда должен существовать склад Основной, иначе приходование товаров будет выполнено неправильно. Объект конфигурации Справочник позволяет описать любое количество этих элементов справочника, они называются предопределенными элементами справочника. Эти элементы отличаются от обычных остальных тем, что они создаются в конфигураторе и что пользователь не может их удалить, все остальные действия с ними пользователь может делать, в том числе и переименовывать.
В зависимости от того, какие действия мы хотим выполнить со справочником, нам требуется изображать справочник в разном виде, т.е. форме.
Система может самостоятельно сгенерировать все формы, которые нужны для представления данных, содержавшихся в справочнике. Причем система «знает», какие именно формы нужно использовать в каких ситуациях.
Строго говоря, для отображения справочника в различных ситуациях требуется максимум 5 форм для справочника.
Справочники в Access
Создание таблиц
Идею статьи подсказало следующее сообщение:
«Подскажите, как правильно разработать структуру базы для реализации почтовой базы. Интересует правильная связь таблиц: Страна, Регион, Город, Улица.»
Начинающий разработчик имел в виду, как правильно установить связи между справочными таблицами и основной, в которую вставляются данные из справочников.
Поле в связанной таблице
Возможно, что кому то покажется ненужным объяснение вроде бы очевидного, но мне не раз приходилось сталкиваться с базами начинающих (обычно студентов), в таблицах которых вообще не было ключевых полей. Поэтому поясню все подробно.
Как видно, в справочниках только два поля: ключевое и обозначение. А основная таблица состоит в основном из числовых полей, кроме поля «Улица». Вот здесь то и проявляется основная особенность построения реляционных баз данных:
вместо того, чтобы хранить в таблице «Адресат» наименования стран, регионов, городов в виде текста, сохраним их лучше в виде чисел (значений ключевых полей справочников).
Хотя согласно Help, имя может включать любую комбинацию букв, цифр, и специальных знаков за исключением точки (.), восклицательного знака (!), надстрочного знака (`) и квадратных скобок ([ ]), но желательно не использовать в именах полей таблицы никаких символов, кроме букв и цифр. Дело в том, что например имя поля таблицы типа «Улица№» в проекте mdb скорей всего не вызовет никаких конфликтов, а вот при переносе базы на SQL Server, мастер переноса просто «выкинет» его из таблицы.
Теперь осталось только установить связи между таблицами. Жмем в окне проекта на кнопку «Схема данных» или правой кнопкой мыши, и в контекстном меню выбираем «Схема данных». Появилась диалоговое окно «Добавление таблицы». Щелкаем дважды по всем названиям таблиц и закрываем окно.
Флажок «Обеспечение целостности данных»
Флажок «Каскадное обновление связанных полей»
В данном случае можно было бы и не ставить. Дело в том, что ситуация, когда нужно обновлять связанные поля, здесь вряд ли произойдет, ведь ключевое поле в справочной таблице изменить можно только программно. Тем не менее, в нашем случае хуже от этого не будет.
Остановлюсь еще на одном моменте: многим наверное приходилось сталкиваться с ошибкой «Слишком большое число». Если не хотите иметь с этим проблем, возьмите себе за правило не делать поля со списками в таблице (начинающие обычно для этого используют мастер подстановок). Дело в том, что из за несоответствия форматов единиц измерения ширины столбцов в разных версиях Access, эта самая ширина может вместо стандартной 2,54см стать … 57,2 см (слишком большим). Поэтому список лучше сделать на форме, а в таблице оставьте просто поле.
Ссылка таблицы на саму себя (Пример1. Вариант1)
Впрочем, пробелы можно победить например так:
а за неправильность ввода бить по рукам. К тому же, если в список заводятся например номера домов в виде чисел, то этот способ в принципе заслуживает внимания. Чтобы отличить число от текста можно воспользоваться например такой процедурой:
Добавление отсутствующего значение в список значений (Пример1. Вариант2)
Достоинства: не нужны справочные таблицы.
Недостатки: новые данные в справочном списке, увы, не сохраняются. То есть, если в список добавилось новое значение, то при закрытии формы оно исчезнет. Все потому, что список значений можно заполнять только в конструкторе форм (в примере список не заполняется, а просто контролу временно «подсовывается» новый источник строк). Однако такой способ может оказаться полезным, когда именно это и требуется: например в списке присутствуют стандартные значения, но требуется ввести не стандартное, причем не один раз, и чтобы все разы одинаково, а в справочную таблицу заносить новые данные по каким либо причинам не следует. Ситуация довольно странная, но при работе с базами данных случается и не такое.
Добавление отсутствующего значение в список значений (Пример1. Вариант3)
Создадим функцию AppendLookupTable и поместим в общий модуль, чтобы ее можно было вызывать из разных форм, для разных полей со списками, а не только для конкретного.
Для работы с таблицей программно (через DAO), сначала необходимо объявить объектную переменную и присвоить ей источник данных (Recordset):
Вызывать функцию будем аналогично предыдущему примеру:
Мы получили простейшую форму справочник. Осталось придумать, как же ее вызывать? Обычно применяют два способа:
Осталось сделать еще одну важную вещь: обновить список при закрытии справочника. Ведь если мы внесли туда новые данные (или удалили) изменения желательно тут же отобразить в списке.
2. Создадим на главной форме список с именами справочников, и будем их открывать двойным щелчком по нужному названию.
Для организации подобного интерфейса нам понадобится служебная таблица «ФормыПараметры» и функция fOpenForm. В этом примере для разнообразия применим другой вид формы.
А теперь самое интересное: я сделал только одну подобную форму справочник (основная форма «Справочник», починенная табличная «SubFrm»), а в списке их у меня две: Страны, Регионы. И в базе вы не найдете форм «Справочник страны», «Справочник регионы». Откуда же они берутся? Все очень просто. Рассмотрим функцию «fOpenForm».
Здесь мы видим процедуру присвоения значений трем переменным: strFormName, strTextFormName, strTableName. А теперь посмотрим на самый верх модуля «Module1». Там мы увидим
Здесь мы подошли к такому важному понятию, как область видимости переменных. Раз эти три переменных объявлены в разделе General общего модуля с ключевым словом Public, то они становятся видимыми для всех модулей приложения. Например, их «увидят» процедуры модуля формы «Справочник» для того чтобы присвоить форме соответсвующие параметры. Рассмотрим их.
как видно, значения берутся из полей служебной таблицы «ФормыПараметры». А затем команда на открытие формы DoCmd.OpenForm strFormName
Теперь заглянем в модуль формы «Справочник». Рассмотрим процедуру, происходящую при открытии формы:
Открытие формы происходит после присвоения значения глобальным переменным. Свое обозначение и источник данных форма получает при открытии.
В результате получился макет формы. При запуске форме присваивается текстовое обозначение и цепляется источник строк при помощи глобальных переменных, значения для которых берутся из служебной таблицы. Таким образом, становится возможным используя всего один макет формы «создавать» множество однотипных справочников. Для этого достаточно лишь заполнить необходимыми данными служебную таблицу. Единственное условие: во всех справочных таблицах должно быть два поля, называться они должны одинаково: id, Обозначение. Это накладывает ограничение на возможные варианты справочников, но ведь речь идет о простых справочных формах.
А теперь, попробуйте сами: «создайте» справочник «Города», заполнив соответствующими данными таблицу «ФормыПараметры».
До сих пор мы рассматривали только простейшие справочники. Но представьте: в каждой стране десятки регионов, в каждом регионе десятки городов. Для страны городов получится не одна сотня. Не удобно выбирать из списка с несколькими сотнями записей. Было бы лучше, если выбрав регион, в списке городов отобразились бы только соответствующие ему города. Для этого потребуются специального вида справочники: многоуровневые (зависимые).
Многоуровневые справочники.
Для создания подобного рода справочников потребуется немного другая структура базы данных. Ведь как уже говорилось, подобные справочники создают для облегчения выбора значения из списка с большим количеством записей, которые фильтруются по выбранному значению (параметру) в другом списке. А это значит, что потребуется связать две справочные таблицы, организовав из них составной справочник.