Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Внешние ключи и соотнощение многие ко многим / 9 сообщений из 9, страница 1 из 1
09.07.2005, 13:17
    #33157980
Igor Pavlenko
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
Скажите пожалуйста,
есть такие таблицы:

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
|-----------------|    |-----------------|     |------------------|    |----------------|
|languages        |    |branches         |     |users_in_branches |    |users           |
|-----------------|1   |-----------------|     |------------------|   1|----------------|
|language_id (PK) |-|  |id (PK)          |*    |id (PK)           | |->|linking_id (PK) |
|language         | |  |branch_id (FK)   |<-|  |linking_id (FK)   |-|  |user_name       |
|-----------------| |  |branch_name      |  |->|branch_id (FK)    |*   |...             |
                    |->|language_id (FK) |    *|------------------|    |----------------|
                      *|-----------------|

Суть такая:
таблица languages содержит список языков на которых могут быть поля в др. таблицах, т.е. есть 2 языка: (1)англ. и рус.(2), значит в таблице branches поле branch_name будет и на англ. и на рус.:

branches:
id = 1
branch_id = 1
branch_name = "Engl. name"
language_id = 1
+
id = 2
branch_id = 1
branch_name = "Рус. назв."
language_id = 2

Получается что branch_id не подходит для того чтобы быть (PK). В таблице users_in_branches список пользователей, которые входят в определнные "branches". Могут входить сразу в несколько, следовательно linking_id (PK для табл. users) не может и здесь быть (PK), вводим новый (PK) id.

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



Правильной ли является такая структура БД? Может ли внешний ключ (не PK) ссылаться на поле др. таблицы (FK), который не является первичным ключом?



P.S. Собственно БД уже работает, и менять ее нет возможности. Но я пытался создать модель ее в UML (Enterprise Architect) и там у меня не получается показать связь ключей branch_id<->branch_id. Это и вызвало у меня вопрос о правильности структуры. Или может я просто не понял как нужно это сделать в Enterprise Architect?
...
Рейтинг: 0 / 0
09.07.2005, 13:23
    #33157983
Urri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
Как я понимаю, users_in_branches - это таблица, обеспечивающая связь m-m users и branches. Тогда поле branch_id должно быть pk в branches.
А какая нужда, собственно, заставляет вас думать о нем в этой таблице, как о FK? Может, еще какой-то сущности не хватает? Можно то же посмотреть в виде бизнес-модели?
...
Рейтинг: 0 / 0
09.07.2005, 13:36
    #33157997
Igor Pavlenko
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
UrriКак я понимаю, users_in_branches - это таблица, обеспечивающая связь m-m users и branches. Тогда поле branch_id должно быть pk в branches.
А какая нужда, собственно, заставляет вас думать о нем в этой таблице, как о FK? Может, еще какой-то сущности не хватает? Можно то же посмотреть в виде бизнес-модели?

Если убрать таблицу languages, то уйдет ключ language_id из таблицы branches и ключ branch_id автоматически станет PK, НО идея была в том, чтобы была многоязыковость, т.е. чтобы названия "branches" хранились на нескольких языках. Суть в том, что есть Категория (branch), назовем ее "Marketing", вот, но нам нужно ее название на нескольких языках, для этого и присваиваем ей не первичный ключ, branch_id, который одинаков для всех языков (скажем = 1) но для англ. версии ключ language_id=1, для рус. = 2. Когда добавляем запись о том что пользователь принадлежит к какомуту "бранчу" то указываем именно branch_id (который одинаков для всех языков), если бы мы указали PK, то привязались бы к названию на каком-то определенном языке...

Собственно... Возможно ли такое? Или это ошибка?

Спасибо.
...
Рейтинг: 0 / 0
09.07.2005, 16:09
    #33158052
Pappet
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
В таблице branches делаешь составной PK из branch_id и language_id. Вместе с этим, language_id будет FK. Следовательно, branch_id и language_id пойдут в таблицу users_in_branches в качестве FK. в эту же таблицу как FK пойдет linking_id из таблицы users. Поля branch_id, language_id и linking_id будут составным PK в таблице users_in_branches. Отдельный PK в описанной ситуации там делать незачем.
...
Рейтинг: 0 / 0
09.07.2005, 16:31
    #33158059
Urri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
Так. Плюс в users поместить поле типа user_language. Понятно для чего?
...
Рейтинг: 0 / 0
09.07.2005, 16:32
    #33158060
Urri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
Не типа в смысле "типа", а в смысле "назвать его, например, так" ;-)))
...
Рейтинг: 0 / 0
09.07.2005, 16:59
    #33158066
Igor Pavlenko
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
UrriНе типа в смысле "типа", а в смысле "назвать его, например, так" ;-)))
Это поле есть, просто я его не показал, чтобы не загромождать схемку.
Спасибо.
...
Рейтинг: 0 / 0
10.07.2005, 00:11
    #33158162
Urri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
А если еще правильнее, то должна быть связь m-m между branches и languages.
Так что заводим таблицу branches_to_language, и именно туда относим поле branch_name. А не зависимые от языка поля оставляем в branches. Вот и все.
...
Рейтинг: 0 / 0
11.07.2005, 12:25
    #33159157
ModelR
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Внешние ключи и соотнощение многие ко многим
Igor Pavlenko P.S. Собственно БД уже работает, и менять ее нет возможности. Но я пытался создать модель ее в UML (Enterprise Architect) и там у меня не получается показать связь ключей branch_id<->branch_id. Это и вызвало у меня вопрос о правильности структуры. Или может я просто не понял как нужно это сделать в Enterprise Architect?
Скорее всего и реализована эта связь не декларативным, а программным путем типа проверки что в branches существует по крайней мере одна запись про users_in_branches.branch_id. Аналогично, удаление branches также становится нетривиальной задачей - нужно удалить все упоминания на всех языках. В общем программный код должен классически демонстрировать все аномалии при нарушении нормализации.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Внешние ключи и соотнощение многие ко многим / 9 сообщений из 9, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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