|
|
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Уважаемы гуру SQL! Прошу помочь правильно определится с ключами и связью таблиц. ER-диаграмму приложил. Преподаватель говорит что делаю неправильно, надеюсь на вашу помощь. Сделал такой скрипт: CREATE TABLE payment_type ( payment_type_id INTEGER NOT NULL PRIMARY KEY, name VARCHAR(15), price_area NUMERIC(7,2), price_people NUMERIC(7,2) ); CREATE TABLE apartment ( apartment_id INTEGER NOT NULL PRIMARY KEY, apartment_number SMALLINT, house_number SMALLINT, number_people SMALLINT, area SMALLINT ); CREATE TABLE payment ( payment_type_id INTEGER not Null REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT, apartment_id INTEGER NOT NULL REFERENCES apartment(apartment_id) ON DELETE RESTRICT ON UPDATE RESTRICT, m_y_date DATE, summ NUMERIC(7,2), payment_date DATE ); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 14:22 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Алексей SQL, На основании чего вы всё это делаете, есть ТЗ? И что первично -- скрипт или ER? А так — скрипт использует английские названия, а схема -- русские. Конечно оно неправильно... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 14:29 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
vyegorov,первично ER, по ней нужно создать таблицы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 14:35 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Алексей SQLПрошу помочь правильно определится с ключами и связью таблиц. ER-диаграмму приложил. Преподаватель говорит что делаю неправильно, надеюсь на вашу помощь.Навскидку. В таблице payment отсутствует PRIMARY KEY. В остальных UNIQUE - естественных альтернативных ключей, чтобы бы не было дублирующих видов оплаты или квартир в соответствующих таблицах. Тема, скорее, для форума Проектирование БД . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 15:09 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Алексей SQL, Первичный ключ должен быть в каждой таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 15:09 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Алексей SQL, в payment не хватает какого-нибудь primary key, хранить месяц/год в поле типа date может быть не совсем корректно. в остальном на вид ок. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 15:11 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Спасибо большое за ответы, буду пробовать! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 15:48 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
И еще небольшой вопрос. Я правильно сделал связи payment_type_id INTEGER not Null REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT, или они не нужны? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 15:49 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Переделал, посмотрите что получилось. Немного сомневаюсь в ключах CREATE TABLE payment_type ( payment_type_id INTEGER NOT NULL PRIMARY KEY, name VARCHAR(15) UNIQUE, price_area NUMERIC(7,2), price_people NUMERIC(7,2) ); CREATE TABLE apartment ( apartment_id INTEGER NOT NULL PRIMARY KEY, apartment_number SMALLINT, house_number SMALLINT, number_people SMALLINT, area SMALLINT, UNIQUE (apartment_number, house_number) ); CREATE TABLE payment ( payment_id INTEGER NOT NULL PRIMARY KEY, payment_type_id INTEGER NOT NULL REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT, apartment_id INTEGER NOT NULL REFERENCES apartment(apartment_id) ON DELETE RESTRICT ON UPDATE RESTRICT, m_y_date DATE, summ NUMERIC(7,2), payment_date DATE ); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 16:30 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Алексей SQL, Провеки целостности лучше оставить как есть (NO ACTION). Эффект такой же, как и у RESTRICT, однако NO ACTION может быть отложена до конца транзакции. В таблице payment только суррогатный первичный ключ и нет уникального по реальным значениям. Для уникального понадобиться изменить формат хранения m_y_date. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 17:21 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
vyegorovВ таблице payment только суррогатный первичный ключ и нет уникального по реальным значениям. Если есть уникальный ключ, зачем тогда нужен суррогатный. В данной схеме можно обойтись натуральными ключами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 17:54 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
big-trot, подскажите пожалуйста как это сделать, какие поля взять за ключи? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 18:10 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
big-trotЕсли есть уникальный ключ, зачем тогда нужен суррогатный. В данной схеме можно обойтись натуральными ключами. Это понятно. Я же и говорил о том, что натуральных ключей нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2016, 21:18 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
Алексей SQLПеределал, посмотрите что получилось. Немного сомневаюсь в ключахавторCREATE TABLE payment ( payment_id INTEGER NOT NULL PRIMARY KEY, payment_type_id INTEGER NOT NULL REFERENCES payment_type(payment_type_id) ON DELETE RESTRICT ON UPDATE RESTRICT, apartment_id INTEGER NOT NULL REFERENCES apartment(apartment_id) ON DELETE RESTRICT ON UPDATE RESTRICT, m_y_date DATE, summ NUMERIC(7,2), payment_date DATE, PRIMARY KEY(apartment_id, payment_type_id, m_y_date) ); Если правильно понял исходную модель, то так, IMHO, будет разумнее. По смыслу означает, что для одной и той же квартиры один и тот же вид оплаты за один месяц года может быть выполнен только один раз. Порядок полей в PRIMARY KEY должен быть выбран под наиболее частый вид условий при выполнении запросов. Впрочем, в логической задачке это неважно, важнее правильные ограничения. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2016, 03:06 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
ChAПо смыслу означает, что для одной и той же квартиры один и тот же вид оплаты за один месяц года может быть выполнен только один раз. т.е. частичные платежи в практике не имеют место быть? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2016, 08:23 |
|
||
|
Первичный и альтернативный ключи и связь таблиц
|
|||
|---|---|---|---|
|
#18+
LonepsychoChAПо смыслу означает, что для одной и той же квартиры один и тот же вид оплаты за один месяц года может быть выполнен только один раз. т.е. частичные платежи в практике не имеют место быть? Представленная ER позволяет думать, что в рамках поставленной задачи частичных платежей не будет. В противном случае там было бы больше сущностей: счёт для квартиры (с баланасом), выставленные счета, платежи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2016, 08:58 |
|
||
|
|

start [/forum/topic.php?fid=53&msg=39238397&tid=1997234]: |
0ms |
get settings: |
11ms |
get forum list: |
21ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
176ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 253ms |
| total: | 534ms |

| 0 / 0 |
