powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Непостоянная транзитивная взаимосвязь
18 сообщений из 18, страница 1 из 1
Непостоянная транзитивная взаимосвязь
    #36226329
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Работаю над структурой части БД, складывается следующая ситуация:

1) Есть таблица с участками производства Sections;
2) В таблице Terminals хранятся данные о терминалах, расположенных на производстве; на каждом участке расположено несколько терминалов (ОДИН ко МНОГИМ): Sections -> Terminals;
3) В таблице Profiles хранятся профили терминалов, профили также соотносятся с секциями Sections -> Profiles (профили специфичны для участков и должны быть к ним привязаны);

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

В принципе, можно все оставить как есть, но думаю, нет ли какого-то более элегантного решения?


________________________________________________________
Глюк - это высокоорганизованная система не поддающихся определению частиц
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36226554
aston
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Как мне кажется, вам необходима сущность "Виды профилей" (ProfileType).
Для каждого вида будут описаны сами "Профили" - Profiles.

Тогда получается следующее:
Sections
ProfileType
Terminals: FK Section, FK ProfileType
Profiles: PK(FK Section, FK ProfileType)
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36226973
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
aston,

Решение конечно возможное, но дело в том, что каждый профиль органично принадлежит своему участку и особого физического смысла ProfileTypes иметь не будет.
Пока я остановился на решении, когда триггер проверяет связь Profiles->Terminals, чтобы треугольник связей в итоге сходился.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36227168
muk07
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Проблема типовая. Я действовал также как Вы. Не знаю, есть ли другие рецепты.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36228165
seforsource
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Не знаю как насчет типизации, я вот подобную схему уже пару раз реализовывал по принципу регистров в 1С:
Как видно на рисунке схема 1 избыточна, схема 2 не подходит (хотя опять таки зависит от понятий вложенных в сущности), попробуйте схему 3, которая содержит в себе специфику связи Секций(S), терминалов (T) и профилей (P) отражающейся в сущности template. Например, перемещая профиль (P) в секции (S), достаточно добавить запись для терминала (T) [можно подойти глобальнее и вообще при создании связки SPT регистрировать общие для них данные, что конечно приведет к более продуманным действиям во время проектирования]. Если посмотреть чисто геометрически, то никак не избежать "транзитивности" там, где она задумана. Подумайте по-поводу размножения специфик вводя N сущностей template1 ... templateN.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36228301
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seforsourceНе знаю как насчет типизации, я вот подобную схему уже пару раз реализовывал по принципу регистров в 1С:
Как видно на рисунке схема 1 избыточна, схема 2 не подходит (хотя опять таки зависит от понятий вложенных в сущности), попробуйте схему 3, которая содержит в себе специфику связи Секций(S), терминалов (T) и профилей (P) отражающейся в сущности template. Например, перемещая профиль (P) в секции (S), достаточно добавить запись для терминала (T) [можно подойти глобальнее и вообще при создании связки SPT регистрировать общие для них данные, что конечно приведет к более продуманным действиям во время проектирования]. Если посмотреть чисто геометрически, то никак не избежать "транзитивности" там, где она задумана. Подумайте по-поводу размножения специфик вводя N сущностей template1 ... templateN.

Интересный вариант, стоит подумать.
Правда нужно тогда заводить частично определенные сущности - для терминалов, которым временно профиль не назначен и профилей, которые не сопоставлены ни одному терминалу.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230250
seforsource
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Я вот тут от Маяковской до Юго-Западной 2 раза думал о Вашей схеме, и вот до чего додумался:

S - сущность однозначно определяющая Sections, без зависимостей от P и T;
P - сущность однозначно определяющая Terminals, без зависимостей от S и T;
T - сущность однозначно определяющая Profiles, без зависимостей от P и S;

тогда, если ввести понятие периода в сущность template, то получится картина типа этой:

templateID_SID_PID_TНастройкаS+PНастройкаT+PПериод Ссылка на техдокуметацию ПО_Terminals_Profiles Монтаж110341134004x-e=@erЛ70025/05/09Пакет ТД№44win7 Иванов210741934003x-e=@er1Л70025/05/09Пакет ТД№43win7 Иванов
Ну, типа того. И вот Вы сменили 4003 терминал на 4005 26/10/09 с использованием настройки Л701, тогда будет:
templateID_SID_PID_TНастройкаS+PНастройкаT+PПериод Ссылка на техдокуметацию ПО_Terminals_Profiles Монтаж110341134004x-e=@erЛ70025/05/09Пакет ТД№44win7 Иванов210741934003x-e=@er1Л70025/05/09Пакет ТД№43win7 Иванов310741934005x-e=@er1Л70126/10/09Пакет ТД№115win7 Сидоров
Я к чему все это - сущность template отображает уникальность SPT, не имея в себе смысла без отношений S -> template P -> template T -> template. Но может получиться так, что одной сущности template будет недостаточно, или конфигурация в одном отношении поменялась, а в другом отношении осталась прежней, например, при поломке оборудования или при начале монтажа, когда настройка вроде уже есть, а процедура еще не функционирет, тогда придется вводить еще какое-то конечное количество template-ов... Таким Макаром Вы убиваете нескольких зайцев: заяц А - регистр об изменении информации во времени; заяц Б - нет необходимости создавать сущность типовых связок SPT (назовем их Шаблоны SPT), просто копируйте прежние; заяц В - можно получить интересную паутину местоположения и т.п. приблуд, если ввести координаты местоположения в S, то положения (во времени и по координатам S) T и P можно отследить составив 1 SQL с 1 вложенным SQL.

А про LelikkПравда нужно тогда заводить частично определенные сущности - для терминалов, которым временно профиль не назначен и профилей, которые не сопоставлены ни одному терминалу.
Это правда, но в этом же и прикол ;) Типа "нормальная форма" по "Коду" или как-там... Не знаю я этого, сам не читал.

Опять таки это ИМХО. Я институтов не "кончал", поэтому не претендую на похвалы и критику... Я фрезеровщик 3го разряда. Хотя и имею свою контору, клиентов и разработки...
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230443
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seforsource,

Я поразмышлял вчера над вашей структурой - то, что вы предлагаете, фактически является связью многие-ко-многим между тремя таблицами. То есть разреженный трехмерный массив.
Но проблема просто перетекает в другую плоскость: таблица не будет в 3-ей нормальной форме, так как факт принадлежности Профиля "С1" Секции "С" будет продублирован во всех записях о терминалах, которым назначен профиль "С1"

Sections Profiles TerminalsС C1 nullC C1 27C C1 28C C1 32

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

В общем, теоретическая нормализация дело Бойса и Кодда :) А на практике приходится выбирать наиболее подходящее нарушение.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230595
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Lelikkтаблица не будет в 3-ей нормальной форме, так как факт принадлежности Профиля "С1" Секции "С" будет продублирован во всех записях о терминалах, которым назначен профиль "С1"

Sections Profiles TerminalsС C1 nullC C1 27C C1 28C C1 32

Тут очень трудно будет поддерживать целостность данных, потому что она должна быть обеспечена определенным сочетанием записей. Так что я пока оставлю структуру треугольничком с триггерной проверкой.Если считать ключом комбинацию (Sections, Profiles, Terminals), то никакого нарушения 3НФ нет. Точнее, есть, но оно в наличие NULL в поле Terminals. С теоретической точки зрения считается(Дейт), что в таком случае вообще нельзя говорить о реляционной модели. С практической, если допустим только один NULL на комбинацию (Sections, Profiles), как и любого другого значения Terminal, то можно говорить об уникальном ограничении, которое можно считать каким-никаким, но ключом, так как только одна строка имеет такую комбинацию атрибутов. С другой стороны, можно вводить виртуальный терминал с определённым идентификатором, например, 0 или -1, т.е., фиксированным значением, которое не может принадлежать или быть присвоено ни одному реальному терминалу. Теоретически, не совсем честный ход, появляются так называемые magical values, которые должны учитываться при программировании, практически - почему нет ? Иногда может оказаться очень удобным заменить неопределённое определённым, дабы избежать использование NULL и трёхзначной логики.
По стартовому топику не совсем понятна суть проблемы, ибо предметная область напрочь не знакома. И дальнейшее обсуждение ситуации не прояснило. Что такое профиль ? Терминала ? Участка ? Хотя бы вкратце, на уровне понятий. Также хотелось бы увидеть более-менее полный перечень бизнес-правил, если так можно выразиться. Включая возможности существования: терминала вне участков, без профиля; участка без профиля, без терминалов; профиля без участка и терминала. Тогда можно было бы поговорить более конкретно.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230597
Фотография NextMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Lelikk, может быть, обеспечить "неприкосновенность" связи "терминал-секция" при изменениях связи "профиль-терминал" просто физически, введением составного внешнего ключа?

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
CREATE TABLE PROFILE (
    ID INTEGER NOT NULL,
    SECTION_ID INTEGER NOT NULL);


CREATE TABLE SECTION (
    ID INTEGER NOT NULL);


CREATE TABLE TERMINAL (
    ID INTEGER NOT NULL,
    PROFILE_ID INTEGER NOT NULL,
    SECTION_ID INTEGER);

/********/


ALTER TABLE PROFILE ADD CONSTRAINT PK_PROFILE PRIMARY KEY (ID);
ALTER TABLE SECTION ADD CONSTRAINT PK_SECTION PRIMARY KEY (ID);
ALTER TABLE TERMINAL ADD CONSTRAINT PK_TERMINAL PRIMARY KEY (ID);

/********/


ALTER TABLE PROFILE ADD CONSTRAINT FK_PROFILE_TERMINAL FOREIGN KEY (SECTION_ID) REFERENCES SECTION (ID);
ALTER TABLE TERMINAL ADD CONSTRAINT FK_TERMINAL_PROFILE FOREIGN KEY (PROFILE_ID, SECTION_ID) REFERENCES PROFILE (ID, SECTION_ID);

...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230648
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NextMan

Код: plaintext
1.
ALTER TABLE TERMINAL ADD CONSTRAINT FK_TERMINAL_PROFILE FOREIGN KEY (PROFILE_ID, SECTION_ID) REFERENCES PROFILE (ID, SECTION_ID);


Спасибо за совет. Внешними составными ключами получается лучше, чем явная реализация триггерами.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230651
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA,

Никакой особенной предметной области нет. Бизнес-правила в отношении этиз 3-х сущностей (Секция, Терминал, Конфигурационные Профили) следующие:
1) Каждый терминал принадлежит одной и только одной секции;
2) Каждый профиль принадлежит одной и только одной секции;
3) Каждый профиль сопоставлен N-му количеству терминалов (N=0..n);
4) Каждый терминал имеет профиль;
5) Если терминал принадлежит секции K, то профиль тоже должен принадлежать секции K.
6) Участок может быть пуст (временно, вырожденный случай);
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230761
Фотография NextMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA, имхо, по-моему, схож с моим , тогда Вы и толкнули меня в сторону композитного FK...
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36230840
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
NextManChA, имхо, по-моему, схож с моим , тогда Вы и толкнули меня в сторону композитного FK...

Такие у меня тоже есть :)
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36231151
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
LelikkНикакой особенной предметной области нет."Варкалось. Хливкие шорьки. Пырялись по наве,..."© Ничего особенного, правда ведь ? :)
LelikkБизнес-правила в отношении этиз 3-х сущностей (Секция, Терминал, Конфигурационные Профили) следующие:
1) Каждый терминал принадлежит одной и только одной секции;
2) Каждый профиль принадлежит одной и только одной секции;
3) Каждый профиль сопоставлен N-му количеству терминалов (N=0..n);
4) Каждый терминал имеет профиль;
5) Если терминал принадлежит секции K, то профиль тоже должен принадлежать секции K.
6) Участок может быть пуст (временно, вырожденный случай)
Непонятна ситуация с 4 и 5 пунктами. Т.е., в чём разница между профилями терминала и секции ? Терминал всегда имеет профиль секции или может иметь собственный профиль, который не имеет никакого отношения к секции ? Или профиль секции добавляется к профилю терминала ? Или новому терминалу автоматически присваивается профиль секции, а дальше он может стать индивидуальным, присущим данному терминалу. В общем, чем отличается профиль секции от профиля терминала ?
Пока создалось впечатление, что профиль терминала всегда соответствует профилю секции и для определения профиля терминала достаточно знать, к какой секции он относится. Соответственно, никакой прямой связи между терминалом и профилем не надо вообще.

P.S. Участок(п.6) - синоним секции ?NextManтогда Вы и толкнули меня в сторону композитного FK..."...в пороки впал и гнусность возлюбил..."© ? :)
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36231155
Фотография NextMan
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChA...NextManтогда Вы и толкнули меня в сторону композитного FK..."...в пороки впал и гнусность возлюбил..."© ? :)
В общем, Бармаглот таки изменил ТЗ, позволив обойтись без излишеств и непотребств.
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36231287
Фотография Lelikk
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ChALelikkНикакой особенной предметной области нет."Варкалось. Хливкие шорьки. Пырялись по наве,..."© Ничего особенного, правда ведь ? :)
LelikkБизнес-правила в отношении этиз 3-х сущностей (Секция, Терминал, Конфигурационные Профили) следующие:
1) Каждый терминал принадлежит одной и только одной секции;
2) Каждый профиль принадлежит одной и только одной секции;
3) Каждый профиль сопоставлен N-му количеству терминалов (N=0..n);
4) Каждый терминал имеет профиль;
5) Если терминал принадлежит секции K, то профиль тоже должен принадлежать секции K.
6) Участок может быть пуст (временно, вырожденный случай)
Непонятна ситуация с 4 и 5 пунктами. Т.е., в чём разница между профилями терминала и секции ? Терминал всегда имеет профиль секции или может иметь собственный профиль, который не имеет никакого отношения к секции ? Или профиль секции добавляется к профилю терминала ? Или новому терминалу автоматически присваивается профиль секции, а дальше он может стать индивидуальным, присущим данному терминалу. В общем, чем отличается профиль секции от профиля терминала ?
Пока создалось впечатление, что профиль терминала всегда соответствует профилю секции и для определения профиля терминала достаточно знать, к какой секции он относится. Соответственно, никакой прямой связи между терминалом и профилем не надо вообще.

P.S. Участок(п.6) - синоним секции ?NextManтогда Вы и толкнули меня в сторону композитного FK..."...в пороки впал и гнусность возлюбил..."© ? :)

1) Участок - синоним секции;
2) Секции профилей НЕ имеют, они лишь содержат внутри профили терминалов;
3) Сопоставляются всегда терминалы и их профили;
...
Рейтинг: 0 / 0
Непостоянная транзитивная взаимосвязь
    #36231857
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Lelikk2) Секции профилей НЕ имеют, они лишь содержат внутри профили терминаловСобственно, принадлежность профиля и подразумевалась. В общем, если правильно понял, то вырисовывается следующая картина:

Код: plaintext
Есть множество секции(0,..., S)

Каждой секции соответсвует множество профилей(0,..., P s )

Каждому профилю соотвествует множество терминалов(0,..., T Ps )

Терминал обязательно имеет профиль

Терминал обязательно принадлежит секции

Профиль обязательно принадлежит секции
Если всё обстоит именно так, то схема, предложенная NextMan, близка, но есть нюансы. Прилагается слегка поправленный вариант
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
CREATE TABLE "SECTION" (
	"ID" integer NOT NULL PRIMARY KEY
)
CREATE TABLE "PROFILE" (
	"SECTION_ID" integer NOT NULL REFERENCES "SECTION" ("ID")
	, "ID" integer NOT NULL
	, PRIMARY KEY("SECTION_ID", "ID")
)
CREATE TABLE "TERMINAL" (
	"ID" integer NOT NULL PRIMARY KEY
	, "PROFILE_ID" integer NOT NULL
	, "SECTION_ID" integer NOT NULL
	, FOREIGN KEY ("SECTION_ID", "PROFILE_ID") REFERENCES "PROFILE" ("SECTION_ID", "ID")
)
При условии, что профиль - вещь полностью зависимая от секции и никак не разделяема с другими секциями. Тогда поле "ID" в описании таблицы "PROFILE" представляет собой некий условный уникальный номер только относительно секции, в абсоютной уникальности смысл, в общем-то, отсутствует.
В противном случае, если подразумевается полная независимость профиля с потенциальной возможностью принадлежать нескольким секциям одновременно, то было бы правильнее вообще всё переиграть иначе
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
CREATE TABLE "SECTION" (
	"ID" integer NOT NULL PRIMARY KEY
)
CREATE TABLE "PROFILE" (
	"ID" integer NOT NULL PRIMARY KEY
)
CREATE TABLE "SECTION-PROFILE" (
	"SECTION_ID" integer NOT NULL REFERENCES "SECTION" ("ID")
	, "PROFILE_ID" integer NOT NULL REFERENCES "PROFILE" ("ID")
	, PRIMARY KEY("SECTION_ID", "PROFILE_ID")
)
CREATE TABLE "TERMINAL" (
	"ID" integer NOT NULL PRIMARY KEY
	, "PROFILE_ID" integer NOT NULL
	, "SECTION_ID" integer NOT NULL
	, FOREIGN KEY ("SECTION_ID", "PROFILE_ID") REFERENCES "SECTION-PROFILE" ("SECTION_ID", "PROFILE_ID")
)
...
Рейтинг: 0 / 0
18 сообщений из 18, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Непостоянная транзитивная взаимосвязь
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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