Вы думаете о «отношениях» неправильно. Хотя верно, что ботаника не связана с базами данных (за исключением некоторых очень, очень редких угловых случаев), вы смотрите на data , а не на вещь .
Как вы смоделируете это, зависит от того, как вы просматриваете эти ключевые слова. Являются ли это строгими отношениями с одним родителем, когда ключевое слово child может никогда иметь дочерние, а ключевые слова принципиально отличаются от родительских (другими словами, родители служат только в качестве механизма классификации и сами по себе не являются , ключевые слова)? Или вы могли бы «глубоко» вложить эти ключевые слова и использовать их в качестве ключевых слов на любом уровне (другими словами, у «ботаники» могут быть дети, а «НАУКА» - такое же ключевое слово, как и «ботаника»)?
Если это первое, вам нужно смоделировать его примерно так:
Category
----------
CategoryID (PK)
Name
Keyword
---------
KeywordID (PK)
CategoryID (FK)
Name
Если это второе, вы бы смоделировали его примерно так:
Keyword
---------
KeywordID (PK)
ParentKeywordID (FK)
Name
Где ParentKeywordID - это внешний ключ, допускающий значение NULL, обратно к Keyword. Вы создали таблицу, которая ссылается на себя, и подобные структуры определяют древовидную структуру с узлами, которые могут быть вложены на любом уровне.
примечание
Многие скажут вам, что хранить значения null в базе данных - плохая идея, и я согласен с этими людьми в целом. Если вы действительно хотите перейти к полностью нормализованному формату хранения (в любом случае нормализованному до 5NF), вам придется сделать это следующим образом:
Keyword
-----------
KeywordID (PK)
Name
KeywordParent
-------------
KeywordID (PK, FK)
ParentKeywordID (FK)
Тогда ваши ключевые слова верхнего уровня просто не будут иметь строк в KeywordParent.
Этот вид проектирования обычно рассматривается как «лучший» с точки зрения проектирования базы данных, хотя это немного усложнит ваши запросы (только по своей конструкции; они не будут работать хуже и могут на самом деле выполнять лучше без обнуляемых столбцов).