Модель реляционной базы данных с реляционными таблицами?

Question

У меня возникла следующая проблема.

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

Таблица пользователя

idUser | email  | otherColumns 
    ------ | ----------- | ------------ 
     1 | a@gmail.com | .... 

Таблица Билл

idBill | value | otherColumns 
    ------ | ------| ------------ 
     1 | 100$ | .... 

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

реляционная таблица Билл Пользователь

id  | idUser | idBill 
    ------ | ------ | ------------ 
    1  | 1  | 1 

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

Наконец, я хочу знать, существует ли какой-либо стандарт для создания этих отношений.

Спасибо.

Answer 1

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

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

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

A счет идентифицирован синтетическим первичным ключом, имеет значение, имеет валюта, имеет xyz.

законопроект имеет ровно одинпользователя.

(или)

законопроект имеет один или болеепользователи.

(или)

Счет имеет ровно одинпользователя и что отношение имеет атрибуты х, у и г.

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

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

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

Answer 2

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

колонка Add «iduser» в «таблицы Билле», так вы можете легко присоединиться к billtable и клиентов таблицы:

таблица Билл

idBill | value  | otherColumns | iduser 
------ | ------ | ......  | .... 
1   |  100$  |    | 1 

Answer 3

Речь идет о вашем дизайне. Допустим, согласно нашему дизайну, one пользователь может иметь n счета и one счет должен принадлежать только one пользователям. Это означает, что мы должны иметь отношения 1-n. Представление этого в виде виртуальных таблиц зависит от того, какой тип отношений у вас есть. Для 1-n мы можем сделать это нравится:

Таблица Пользователь

idUser(PK) | email  | otherColumns 
------  | ------ | ------------ 
1    | a@gmail.com | .... 

Таблица Билл

idBill(PK) | value  | otherColumns | idUser(FK) 
------  | ------ | ------------ | ------ 
1    |  100$  | ....   | 1 
2    |  10$  | ....   | 1 

TableUser.isUser является PK и Unique. TableBill.idUser не входит в состав PK и not unique. Я предпочитаю, чтобы этот способ представлял 1-n, потому что не нужна еще одна таблица (еще одна операция join в запросах).

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

Таблица Пользователь

idUser(PK) | email  | otherColumns 
------  | ------ | ------------ 
1    | a@gmail.com | .... 

Таблица Билл

idBill(PK) | value  | otherColumns 
------  | ------ | ------------ 
1    |  100$  | ....   
2    |  10$  | ....   

реляционная таблица Билл Пользователь

idUser(FK)  |  idBill(FK) 
------   | ------------ 
1    |  1 
1    |  2 

В реляционной таблице idUser поле not unique, потому что мы должны позволить дублировать userid s (1-n). idBill должен быть unique, потому что один счет должен иметь только одного владельца. Также вы можете внести некоторые изменения в соответствии с вашими требованиями к дизайну относительно отношений identifying или нет.

Типы отношений: careerride

О конструкции выпуска (ER диаграммы): tutorialspoint

ER в таблицах: tutorialcup