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

Обратите внимание, что по сегодняшнему состоянию (с 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)Код рубрикиРубрика только одна

Если же он может быть отнесен к нескольким рубрикам (например, жанр фильма), то можно сделать промежуточную таблицу соответствия.

НаименованиеПоле  ПримечаниеКомментарий
obj_idI(4)Код объектаОн может (будет) повторяться во многих записях
rubr_idI(4)Код рубрикиРубрика опять одна, но для нескольких записей с одним obj_id мы получим массив

Может получиться, в определенном смысле, перечень ключевых слов, характеризующих объект. Естественно, что решение об этом нужно принимать на этапе разработки структуры.

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

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

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


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