Базы данных: рубрикаторы
Обратите внимание, что по сегодняшнему состоянию (с 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) | Код рубрики | Рубрика только одна |
Если же он может быть отнесен к нескольким рубрикам (например, жанр фильма), то можно сделать промежуточную таблицу соответствия.
| Наименование | Поле | Примечание | Комментарий |
| obj_id | I(4) | Код объекта | Он может (будет) повторяться во многих записях |
| rubr_id | I(4) | Код рубрики | Рубрика опять одна, но для нескольких записей с одним obj_id мы получим массив |
Может получиться, в определенном смысле, перечень ключевых слов, характеризующих объект. Естественно, что решение об этом нужно принимать на этапе разработки структуры.
С точки зрения пользователя, он увидит информацию из рубрикатора так, как это сделает программист интерфейса.
- В виде упорядоченного списка рубрики первого уровня (не имеющего родительского), при выборе которого выводится дочерний и т.д. Естественно, что при этом возникает упомянутая проблема ограничения выводимых уровней, но она частично решается динамическим программированием.
- В виде упорядоченного полного списка (без разделения на подрубрики), в котором можно проводить зрительный или программный поиск. Последнее нужно очень часто!
- В виде дерева (иерархической структуры) так, как вы могли видеть это во многих программах, начиная от отображения структуры файлов на диске.
- В обычной табличной форме (1|2|3) или объединив уровни через заданный разделитель (1-2-3).
- Список может позволять множественный выбор. Как простой, так и с переносом в новый список, что сложнее программировать :), но удобнее для большого перечня.
Одна из типовых ошибок подобного заполнения возникает, когда вводятся родительская и дочерняя рубрики с одним и тем же названием. Либо две одинаковых дочерних рубрики в разных разделах. Да, в жизни так бывает. Но это создает либо неясность, либо необходимость отнесения сразу к нескольким рубрикам (а надо бы программно!), обычно порождающие недостоверность (неполноту) информации.
Сложность разработки рубрикаторов заключается в том, что эта работа лежит в плоскости сугубо профессионального анализа. Далеко не каждый профессионал в предметной области способен ее выполнить.
Copyright © 1993–2020 Мацкявичюс Д.А. Все права защищены.
Никакая часть сайта не может быть воспроизведена никаким способом без письменного разрешения правообладателя и явной ссылки на данный ресурс.
