Базы данных: рубрикаторы
Обратите внимание, что по сегодняшнему состоянию (с 2010 по 2020 г.) именно эта тема взята в качестве экзаменационной (ЕГЭ) для баз данных и реализована на родственных отношениях. Прадед будет находится последовательно через код родителя, коды его родителей (деды/бабки) и т.д. Стандартная ошибка, конечно реализована: у каждого человека родителей двое, а создание для этого двух записей нерационально и пригодно только для «псевдоэкзаменовки». Отсутствие данных о родителях — недостаток ввода, сбора данных, «дыры» для затыкания и все, что угодно, но не ошибка структуры БД. Включая ситуацию, когда в графе отца стоит прочерк, что также является информацией.
Доступ к этим материалам предоставляется только зарегистрированным пользователям!
По сути дела, тема рубрикации возникает как отдельная в связи с условным недостатком реляционных баз данных. Точнее говоря, с нестыковкой привычных, возникших естественным путем способов рационального представления данных в виде иерархической структуры и табличной основы работы этого вида СУБД.
Одним из возможных решений является создание идентичных таблиц-справочников для 1-го, 2-го и т.д. уровней. Но такой подход имеет серьезные дополнительные недостатки.
Первым из них станет жесткость уровневой структуры. То есть, мы предусматриваем три уровня и всё. Пользователь не сможет вмешаться и добавить таблицу. В противном случае гарантирован хаос. Единственное возражение, которое здесь можно привести, это то, что если разложение не описывается пятиуровневым рубрикатором, то, скорее всего, он разработан и используется неправильно.
Затем неизбежно встанет тема поиска рубрики. Ведь ее нужно провести в трех таблицах, а потом объединить.
....
Таблица рубрик (справочник)
| Наименование | Поле | Примечание | Комментарий |
| rubr_id | I(4) | Код рубрики | Рубрик может быть много |
| rubr_name | C(??) | Наименование рубрики | Желательно делать кратким |
| rubr_parent | I(4) | Родительская рубрика | Будет «пустой» для верхнего уровня (прародитель). Для остальных содержит rubr_id родителя (верхнего уровня) |
| sub_rubr | I(2) | Количество подрубрик | Вопрос удобства. Да, можно сосчитать, но при частом выводе информации это будет тормозить работу, а редактирование поля автоматизируется в момент добавления/удаления подрубрик. Это — классический пример денормализации |
| rubr_note | M(10) | Примечание | Поле может содержать полное название рубрики или просто необходимые комментарии |
Для отнесения объекта к рубрике, в описывающей его таблице можно создать соответствующее поле:
| Наименование | Поле | Примечание | Комментарий |
| obj_id | I(4) | Код объекта | |
| obj_name | C(??) | Наименование объекта | |
| rubr_id | I(4) | Код рубрики | Рубрика только одна |
Доступ к этим материалам предоставляется только зарегистрированным пользователям!
С точки зрения пользователя, он увидит информацию из рубрикатора так, как это сделает программист интерфейса.
- В виде упорядоченного списка рубрики первого уровня (не имеющего родительского), при выборе которого выводится дочерний и т.д. Естественно, что при этом возникает упомянутая проблема ограничения выводимых уровней, но она частично решается динамическим программированием.
- В виде упорядоченного полного списка (без разделения на подрубрики), в котором можно проводить зрительный или программный поиск. Последнее нужно очень часто!
- В виде дерева (иерархической структуры) так, как вы могли видеть это во многих программах, начиная от отображения структуры файлов на диске.
- В обычной табличной форме (1|2|3) или объединив уровни через заданный разделитель (1-2-3).
- Список может позволять множественный выбор. Как простой, так и с переносом в новый список, что сложнее программировать :), но удобнее для большого перечня.
....
Одна из типовых ошибок подобного заполнения возникает, когда вводятся родительская и дочерняя рубрики с одним и тем же названием. Либо две одинаковых дочерних рубрики в разных разделах. Да, в жизни так бывает. Но это создает либо неясность, либо необходимость отнесения сразу к нескольким рубрикам (а надо бы программно!), обычно порождающие недостоверность (неполноту) информации.
Сложность разработки рубрикаторов заключается в том, что эта работа лежит в плоскости сугубо профессионального анализа. Далеко не каждый профессионал в предметной области способен ее выполнить. Но делать это приходится разработчику, понимающему в тематике намного меньше, но потенциально способному найти узкие места.
....
Возможные запросы к множественному рубрикатору
Здесь речь идет о понимании того, «как оно работает». Обратным следствием должно быть формирование восприятия причин именно обсуждаемых структур БД.
Доступ к этим материалам предоставляется только зарегистрированным пользователям!
Следует понимать, что приведенные варианты являются достаточно типичными. Многие из обозначенных трудностей в связи с этим решаются на уровне ядра СУБД путем оптимизации. Описание по ряду позиций существенно примитизировано выхолащиванием языка запросов, разбиением на последовательности. Но оно ориентировано только на понимание принципов.
Для серьезных работ обязательно необходимо детальное знание языка запросов, чтобы предсказывать возможность реализации поиска оптимальными алгоритмами.
Из перечисленного можно сделать вывод, что непосредственное обращение к промежуточной таблице не осуществляется никогда. Она служит именно для связывания, экономно расходуя память для хранения сложной информации.
Copyright © 1993–2021 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.
