ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Отношение многие-ко-многим с иерархией
9 сообщений из 9, страница 1 из 1
Отношение многие-ко-многим с иерархией
    #38322233
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Здравствуйте!

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

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

Есть 3 способа представить эти отношения (см. рисунок):
1) 3 отдельных отношения.
2) Одно объединенное отношение
3) Одно отношение с абстрактным участником

У 1-го и 2-го вариантов есть ещё по 2 подварианта:
а) Если в регламенте указан сервис, то в нем уже не может быть указана ни система, ни организация, к которой принадлежит сервис. Если указана система, то не могут быть указаны ни один из её сервисов, ни организация. Если указана организация, то не могут быть указаны её системы и сервисы.
б) Наоборот, если указан сервис или система, то указываются и их родители. Проще запросы, но сложнее поддерживать целостность.

Какой вариант лучше? :)
...
Рейтинг: 0 / 0
05.07.2013, 16:51
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38322235
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Хотя, и у 3-го варианта эти подварианты тоже могут быть.
...
Рейтинг: 0 / 0
05.07.2013, 16:52
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38322237
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Что-то мне подсказывает, что вариант 2а лучший...
...
Рейтинг: 0 / 0
05.07.2013, 16:55
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38322239
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
ой, т.е. 2б - лучший вариант )
...
Рейтинг: 0 / 0
05.07.2013, 16:55
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38322251
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Кот Матроскин
Участник
У схемы варианта 2 наличествуют ФЗ в таблице ReglamentUsage.

Мне лично больше нравится вариант 3 - единственно я бы в party добавил бы поле type с 3 возможными значениями.
...
Рейтинг: 0 / 0
05.07.2013, 17:05
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38323431
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
Кот Матроскин,

В варианте 2б проще всего искать связи между участниками по регламентам:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
WITH [ReglamentUsage] AS
(
SELECT [ReglamentId]
      ,[OrganizationId]
      ,[SystemId]
      ,[ServiceId]
      ,COALESCE([ServiceId], [SystemId], [OrganizationId]) [PartyId]
  FROM [dbo].[ReglamentUsage]
)
SELECT *
  FROM [ReglamentUsage] src
  INNER JOIN [ReglamentUsage] dst ON src.[ReglamentId] = dst.[ReglamentId] AND src.[PartyId] <> dst.[PartyId]


Вариант 1а сводится к 2б достаточно заморочено:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
SELECT [ReglamentId]
      ,[OrganizationId]
      ,[SystemId]
      ,[ServiceId]
      ,[ServiceId] [PartyId]
  FROM [dbo].[ServiceReglament]
  LEFT JOIN [dbo].[Service] ON [Service].[Id] = [ServiceId]
  LEFT JOIN [dbo].[System] ON [System].[Id] = [SystemId]
UNION ALL
SELECT [ReglamentId]
      ,[OrganizationId]
      ,[SystemId]
      ,NULL [ServiceId]
      ,[SystemId] [PartyId]
  FROM [dbo].[SystemReglament]
  LEFT JOIN [dbo].[System] ON [System].[Id] = [SystemId]
UNION ALL
SELECT [ReglamentId]
      ,[OrganizationId]
      ,NULL [SystemId]
      ,NULL [ServiceId]
      ,[OrganizationId] [PartyId]
  FROM [dbo].[OrganizationReglament]


3а - немного проще:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
SELECT [ReglamentId]
      ,[Organization].[Id] [OrganizationId]
      ,[System].[Id] [SystemId]
      ,[Service].[Id] [ServiceId]
      ,[PartyId]
  FROM [dbo].[ReglamentUsage2]
  LEFT JOIN [dbo].[Service] ON [Service].[Id] = [ReglamentUsage2].[PartyId]
  LEFT JOIN [dbo].[System] ON [System].[Id] IN ([ReglamentUsage2].[PartyId], [Service].[SystemId])
  LEFT JOIN [dbo].[Organization] ON [Organization].[Id] IN ([ReglamentUsage2].[PartyId], [System].[OrganizationId])


1б и 3б - вообще не варианты.

Согласен, 3ий вариант лучше всего, спасибо!
...
Рейтинг: 0 / 0
07.07.2013, 23:21
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38323557
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
А какие доводы можно привести в пользу 3-го варианта?

Вариант 2а не очень нормализованный, но можно сделать ограничение, чтобы не нулевым был только один столбец из OrganizationId, SystemId, ServiceId, и никаких аномалий не будет.

В варианте 2б ограничения будут более сложными, но зато существенный выигрыш в производительности выборок. Этот вариант не очень сложный с точки зрения программистов (им легко при добавлении в регламент сервиса указать ещё и систему, организацию).

В 3-ем варианте проще добавлять новые виды сущностей, но их и не будет.
...
Рейтинг: 0 / 0
08.07.2013, 04:35
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38323558
deblogger
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
deblogger
Участник
Ares_ekbЕсть иерархия: организация - система - сервис (назовем их всех участниками). И есть регламенты, в которых могут быть задействованы произвольные участники.

Причем, если в регламенте задействован сервис, то это означает, что в этом регламенте задействована и система, к которой он относится, и организация, к которой относится эта система.

Параграф мой. Не вижу иерархии. Система-организация-сервис - это параллель, или как там - коаксиал. Хоть стопицот агентов можно повесить на этот кабель. Регламент - это уровень. Скажем типа тикет. Следовательно нужна еще таблица - список тикетов, или форум.

Ну я и думаю, чего тут изобретать. :)
...
Рейтинг: 0 / 0
08.07.2013, 04:37
| Ответить | Цитировать | Написать  
Отношение многие-ко-многим с иерархией
    #38323609
Ares_ekb
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ares_ekb
Участник
deblogger,

не, я всё-таки думаю, что это иерархия, с фиксированным количеством уровней. Таблица для регламентов уже есть на схеме...
...
Рейтинг: 0 / 0
08.07.2013, 07:49
| Ответить | Цитировать | Написать  
9 сообщений из 9, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Отношение многие-ко-многим с иерархией
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=32&msg=38323557&tid=1541180]:
 0ms
get settings:
 12ms
get forum list:
 14ms
check forum access:
 5ms
check topic access:
 5ms
track hit:
 162ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 45ms
get tp. blocked users:
 1ms
others: 15ms
total:  273ms
созд. / загр.: 273ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]