реляционное VS параметризованное моделирование данных при построении семантических веб-приложений?

Question

Вот краткое изложение моего вопроса, затем я опишу его более подробно:

Я читал об использовании метода моделирования параметризованных данных вместо использования стандартного моделирования реляционных данных при создании семантического веб-приложения.Я думаю, что мы потеряем 90% нормализации, если мы будем использовать этот метод. Если я хочу создать базу данных моего семантического веб-приложения, должен ли я использовать этот способ?Какова практическая ценность?

---

Более подробно:

Я прочитал много статей на эту тему в этой книге «Программирование семантической сети - Тоби Сегаран, Колин Эванс»и Джейми Тейлор "на странице 14 они говорят нам использовать параметризованное моделирование данных для получения семантических отношений вместо стандартной реляционной базы данных, описанной в этом примере:

в стандартной реляционной базе данных:

Место: [ID (PK), Имя, Адрес]

Ресторан: [ID (PK), VenueID (FK), CuisineID]

Бар: [ID (PK), VenueID (FK), DJ ?, Специальность]

Часы: [VenueID (FK), День, Открыть, Закрыть]

Для семантических отношений: только одна таблица !!!Полностью параметризованные объекты

Свойства: [VenueID, Field, Value] Пример:

VenueID _ Поле ____ Значение

1_ _ Кухня _ _Deli

1_ _ Цена __ $

1_ _ Имя _ _Дели Лама

1_ _ Адрес _ _Peachtree Rd

2_ _ Кухня _ _Chinese

2_ _ Цена __ $$$

2_ _ Фирменный коктейль __ Чаша скорпиона

2_ _ DJ? _ _No

2_ _ Имя __ Peking Inn

2_ _ Адрес Озеро St

3_ _ Живая музыка? __ Да

3_ _ Музыкальный жанр __ Джаз

3_ _ Имя __ Тайский Таник

3_ _ Адрес _ _BranchДоктор

Тогда авторы говорят:

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

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

Answer 1

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

Ваша первая таблица предназначена только для определения сущностей, о которых вы хотите хранить информацию, и ключа для поиска, какие виды информации будут храниться:

entity_id | entity_type
---------------------------
        1 | lawn mower
        2 | toothbrush
        3 | bicycle
        4 | restaurant
        5 | person

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

entity_type | attribute
------------------------
lawn mower  | horsepower
lawn mower  | retail price
lawn mower  | gas_or_electric
lawn mower  | ...etc
toothbrush  | bristle stiffness
toothbrush  | weight
toothbrush  | head size
toothbrush  | retail price
toothbrush  | ...etc
person      | name
person      | email
person      | birth date
person      | ...etc

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

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

Между тем, в противоположность предыдущему пункту, полезно сделать общие и однозначные атрибуты (такие как «вес в граммах» или «розничная цена в долларах США» доступными для повторного использования для нескольких типов объектов. Чтобы справиться с этим, добавьте уровень абстракции между атрибутами и типами сущностей. Составьте таблицу «наборов атрибутов», каждый из которых связан с атрибутами 1..n. Тогда каждый тип сущности в приведенной выше таблице будет связан не непосредственно с атрибутами, а с одним или несколькими атрибутами. наборы.

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

Итак, на этом этапе поиск конкретной сущности происходит следующим образом. Из идентификатора объекта мы получаем тип объекта. Из типа сущности мы получаем наборы атрибутов 1..n, которые дают результирующий набор атрибутов, который содержится в сущности. Наконец, есть большая таблица с фактическими данными в ней:

entity_id | attribute_id | value
---------------------------------------
      923 |      1049272 | green
      923 |      1049273 | 206.55
      924 |      1049274 | 843-219-2862
      924 |      1049275 | Smith
      929 |      1049276 | soft
      929 |      1049277 | ...etc

Как и во всех этих таблицах, эта имеет первичный ключ, в данном случае состоящий из столбцов entity_id и attribute_id. Значения хранятся в текстовом столбце без единиц измерения. Единицы хранятся в отдельной таблице, связывающей атрибуты с единицами. Можно создать больше таблиц, если вам нужно более детально это определить; Вы можете установить дополнительные уровни абстракции, чтобы создать систему «типа атрибута», аналогичную системе типов сущностей, описанной выше.

При необходимости вы можете зайти так далеко, чтобы сохранить отношения, такие как «атрибут X численно преобразуется в атрибут Y по следующей формуле», для числовых атрибутов. Или для нечисловых атрибутов вы можете создать таблицы эквивалентности для управления альтернативным написанием или форматами для допустимых значений атрибута.

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

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

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

Answer 2

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

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

Table: users_relational 
+---------+----------+------------------+----------+
| user_id | username | email            | password | 
+---------+----------+------------------+----------+
|       1 | Sam      | sam@example.com  | ******** |
|       2 | John     | john@example.com | ******** |
|       3 | Jane     | jane@example.com | ******** |
+---------+----------+------------------+----------+

Table: users_parametrized
+---------+----------+------------------+
| user_id | field    | value            |
+---------+----------+------------------+
|       1 | username | Sam              |
|       1 | email    | sam@example.com  |
|       1 | password | ********         |
|       2 | username | John             |
|       2 | email    | john@example.com |
|       2 | password | ********         |
|       3 | username | Jane             |
|       3 | email    | jane@example.com |
|       3 | password | ********         |
+---------+----------+------------------+

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

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

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

SELECT username, email FROM users_relational WHERE user_id = 2

Мы должны получить один результат с двумя столбцами. Теперь для параметризованной таблицы:

SELECT field, value FROM users_parametrized WHERE user_id = 2 AND field IN('username','email')

Это немного более многословно и станет менее читабельным, чем первое, особенно если вы начнете брать все больше и больше полей для выбора.

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

Это подводит меня к последней реальной разнице (насколько ваша СУБД это видит). В параметризованном первичном ключе нет никакого, что (как вы видели выше) может быть проблемой производительности, особенно если у вас уже есть значительное количество записей. Для чего-то вроде таблицы пользователей, в которой вы можете иметь тысячи записей, количество ваших записей будет равно этому числу 3 (так как у нас есть три поля не user_id) только в этом случае. Это много данных для базы данных для поиска.

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