Базы данных: рубрикаторы

Обратите внимание, что по сегодняшнему состоянию (с 2010 по 2020 г.) именно эта тема взята в качестве экзаменационной (ЕГЭ) для баз данных и реализована на родственных отношениях. Прадед будет находится последовательно через код родителя, коды его родителей (деды/бабки) и т.д. Стандартная ошибка, конечно реализована: у каждого человека родителей двое, а создание для этого двух записей нерационально и пригодно только для «псевдоэкзаменовки». Отсутствие данных о родителях — недостаток ввода, сбора данных, «дыры» для затыкания и все, что угодно, но не ошибка структуры БД. Включая ситуацию, когда в графе отца стоит прочерк, что также является информацией.


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


По сути дела, тема рубрикации возникает как отдельная в связи с условным недостатком реляционных баз данных. Точнее говоря, с нестыковкой привычных, возникших естественным путем способов рационального представления данных в виде иерархической структуры и табличной основы работы этого вида СУБД.

Одним из возможных решений является создание идентичных таблиц-справочников для 1-го, 2-го и т.д. уровней. Но такой подход имеет серьезные дополнительные недостатки.

Первым из них станет жесткость уровневой структуры. То есть, мы предусматриваем три уровня и всё. Пользователь не сможет вмешаться и добавить таблицу. В противном случае гарантирован хаос. Единственное возражение, которое здесь можно привести, это то, что если разложение не описывается пятиуровневым рубрикатором, то, скорее всего, он разработан и используется неправильно.

Затем неизбежно встанет тема поиска рубрики. Ведь ее нужно провести в трех таблицах, а потом объединить.

....

Таблица рубрик (справочник)
НаименованиеПоле  ПримечаниеКомментарий
rubr_idI(4)Код рубрикиРубрик может быть много
rubr_nameC(??)Наименование рубрикиЖелательно делать кратким
rubr_parentI(4)Родительская рубрикаБудет «пустой» для верхнего уровня (прародитель). Для остальных содержит rubr_id родителя (верхнего уровня)
sub_rubrI(2)Количество подрубрикВопрос удобства. Да, можно сосчитать, но при частом выводе информации это будет тормозить работу, а редактирование поля автоматизируется в момент добавления/удаления подрубрик. Это — классический пример денормализации
rubr_noteM(10)ПримечаниеПоле может содержать полное название рубрики или просто необходимые комментарии

Для отнесения объекта к рубрике, в описывающей его таблице можно создать соответствующее поле:

НаименованиеПоле  ПримечаниеКомментарий
obj_idI(4)Код объекта
obj_nameC(??)Наименование объекта
rubr_idI(4)Код рубрикиРубрика только одна

Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


С точки зрения пользователя, он увидит информацию из рубрикатора так, как это сделает программист интерфейса.

....

Одна из типовых ошибок подобного заполнения возникает, когда вводятся родительская и дочерняя рубрики с одним и тем же названием. Либо две одинаковых дочерних рубрики в разных разделах. Да, в жизни так бывает. Но это создает либо неясность, либо необходимость отнесения сразу к нескольким рубрикам (а надо бы программно!), обычно порождающие недостоверность (неполноту) информации.

Сложность разработки рубрикаторов заключается в том, что эта работа лежит в плоскости сугубо профес­сионального анализа. Далеко не каждый профессионал в предметной области способен ее выполнить. Но делать это приходится разработчику, понимающему в тематике намного меньше, но потенциально способному найти узкие места.

....

Возможные запросы к множественному рубрикатору

Здесь речь идет о понимании того, «как оно работает». Обратным следствием должно быть формирование восприятия причин именно обсуждаемых структур БД.


Доступ к этим материалам предоставляется только зарегистри­рован­ным пользователям!


Следует понимать, что приведенные варианты являются достаточно типичными. Многие из обозначенных труд­ностей в связи с этим решаются на уровне ядра СУБД путем оптимизации. Описание по ряду позиций существенно примитизировано выхолащиванием языка запросов, разбиением на последовательности. Но оно ориенти­ровано только на понимание принципов.

Для серьезных работ обязательно необходимо детальное знание языка запросов, чтобы предсказывать возможность реализации поиска оптимальными алгоритмами.

Из перечисленного можно сделать вывод, что непосредственное обращение к промежуточной таблице не осущест­вляется никогда. Она служит именно для связывания, экономно расходуя память для хранения сложной информации.


Copyright © 1993–2021 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.