Как определить структуру в организации на основе тегов?

Question

[прежнее название: есть ли способ навязать структуру отношений на основе организационной методологии на основе тегов?]

У меня есть несколько сущностей, и у них есть ряд атрибутов. Некоторые из атрибутов влияют на то, какие другие атрибуты могут быть у сущности, многие атрибуты организованы в группы, и иногда от сущностей требуется иметь определенное количество атрибутов из определенных групп или, возможно, диапазон атрибутов из определенных групп.

Есть ли способ моделировать такие виды отношений тегов к тегам, как требования, группировки, исключения и т. Д., Используя базу данных, или это возможно только с помощью запрограммированных «бизнес-правил»? В идеале я хотел бы, чтобы возможные теги и их отношения были легко конфигурируемыми и, следовательно, очень гибкими.

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

Итак, возможно ли это более строго, и если да, то как бы я вообще начал это делать?

Answer 1

edit : Ваше описание переменных атрибутов, которые применяются только в зависимости от значений в других атрибутах, представляет собой нереляционный ненормализованный дизайн. СУБД может быть не лучшим решением для хранения данных такого рода. Вероятно, RDF будет хорошим решением для данных, требующих такого уровня гибкости.

Мой предыдущий ответ, касающийся решений СУБД, приведен ниже:

---

Некоторые люди моделируют гибкие атрибуты с дизайном Entity-Attribute-Value , но это часто слишком неструктурировано, и в итоге вы сталкиваетесь с проблемами целостности данных. Используйте это, только если вам нужно практически неограниченное количество подтипов сущностей.

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

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

CREATE TABLE Vehicles (
  vehicle_id INT PRIMARY KEY
  ...attributes common to all vehicles...
);

CREATE TABLE Automobiles (
  vehicle_id INT PRIMARY KEY,
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id) REFERENCES Vehicles(vehicle_id)
);

Вы также можете обеспечить немного большую целостность данных, кодируя подтип в первичном ключе родительской таблицы. Это означает, что строка в Automobiles не может ссылаться на мотоцикл в Vehicles.

CREATE TABLE Vehicles (
  vehicle_id INT,
  vehicle_type VARCHAR(10),
  ...attributes common to all vehicles...
  PRIMARY KEY (vehicle_id, vehicle_type),
  FOREIGN KEY (vehicle_type) REFERENCES VehicleTypes (vehicle_type)
);

CREATE TABLE Automobiles (
  vehicle_id INT,
  vehicle_type VARCHAR(10) CHECK (vehicle_type = 'Automobile'),
  ...attributes specific to autos...
  FOREIGN KEY (vehicle_id, vehicle_type) 
    REFERENCES Vehicles(vehicle_id, vehicle_type)
);

Конечно, вам нужно создавать новую зависимую таблицу каждый раз, когда вы определяете новый подтип, но этот дизайн дает вам гораздо больше структуры для обеспечения целостности данных, атрибутов NOT NULL и так далее.

Единственная часть, которую необходимо применить в логике приложения, - это создание строки в Automobiles для каждой строки в Vehicles с vehicle_type = 'Automobile'.

Answer 2

Нет никакой разницы между использованием баз данных для обеспечения соблюдения ваших правил или использованием исходного кода в другом месте. Код это данные. Это эзотерический ответ на Лисп.

Реальный вопрос, который вы задаете, заключается в том, проще ли это в реляционной базе данных или (я полагаю) в языке семьи Алгол. Вы не указали RDBMS, поэтому я собираюсь принять ANSI. Это делает это трудно.

Кстати, это легко в Прологе. Но это ни здесь, ни там.

Я бы сказал, чтобы использовать ограничения проверки для всего. Ментальный сдвиг, необходимый для этого подхода, заключается в том, чтобы понять, что вашему пользовательскому интерфейсу потребуется способ определения этих отношений тегов. Традиционно вы должны выдавать операторы CRUD из пользовательского интерфейса в БД. Вместо этого вам нужно ввести операторы ALTER TABLE для проверочных ограничений CRUD.

У этого подхода есть две проблемы:

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

Если бы вы могли уточнить свой вопрос с помощью конкретной СУБД, то мы можем дать вам лучший ответ.