powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите с моделью БД
15 сообщений из 15, страница 1 из 1
Помогите с моделью БД
    #38880616
MrVoid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Создаю модель новой БД. Вкратце суть такая. Работники составляют акты. За составление актов им дают премию. Премия по акту делится в равных долях между составителями акта. Один акт могут составить несколько работников. Так как акт один, а составителей несколько, то создаём две таблицы: одна будет содержать данные акта, а вторая - работников по этому акту (один-к-одному-или-многим). Структура такая:


Меня интересует связь между Act (данные по акту) и ActBonus (данные по премиям по каждому работнику в акте).
Когда дошёл до создания таблицы ActBonus, то SQL Server заругался: " There are no primary or candidate keys in the referenced table 'dbo.Act' that match the referencing column list in the foreign key 'FK_Act_ActBonus_ActNumber' ":

Код: sql
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.
28.
create table dbo.Act
(
    Period        date         not null,
    Number        varchar(15)  not null,
    -----------------------------------
    CreationDate  date         not null,
    Consumer	  varchar(300) not null,
    [Description] varchar(300)     null,
    Kilowatts	  float(24)    not null,
    Fund          float(24)    not null,
    CategoryId    tinyint      not null, --FK
    DivisionId    tinyint      not null, --FK
    constraint PK_Act primary key (Period, Number)
);

create table dbo.ActBonus
(
    WorkerTableNumber int         not null,
    ActNumber         varchar(15) not null,
    --------------------------------------
    PostId            tinyint     not null,
    WorkCode          tinyint     not null,
    [Percent]         tinyint     not null,
    Bonus             real        not null,
    constraint PK_ActBonus primary key (WorkerTableNumber, ActNumber),
    constraint FK_Worker_ActBonus_WorkerTableNumber foreign key (WorkerTableNumber) references dbo.Worker(TableNumber),
    constraint FK_Act_ActBonus_ActNumber foreign key (ActNumber) references dbo.Act(Number)
);



Здесь понятно - ошибка говорит о том, что поле Number не уникально. Чтобы решить данную проблему, я добавляю UNIQUE для Number в таблицу Act, и всё становится ОК:
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
create table dbo.Act
(
    Period        date         not null,
    Number        varchar(15)  not null,
    -----------------------------------
    CreationDate  date         not null,
    Consumer	  varchar(300) not null,
    [Description] varchar(300)     null,
    Kilowatts	  float(24)    not null,
    Fund          float(24)    not null,
    CategoryId    tinyint      not null, --FK
    DivisionId    tinyint      not null, --FK
    constraint PK_Act primary key (Period, Number),
    constraint UQ_Act_Number unique (Number) -- <== UNIQUE
);


Но ведь UNIQUE создаёт дополнительный некластерный индекс, а это дополнительный maintenance и overhead. Быть может, как-то можно сделать модель по-другому? Буду благодарен за предложения. :)

Модератор: Тема перенесена из форума "Microsoft SQL Server".
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38880675
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
У Вас странный первичный ключ в Act - если поле Number уникально само по себе, какой смысл включать дополнительно в PK Period?

Вам надо либо убрать Period из первичного ключа в Act, либо мигрировать его в ActBonus.
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38880707
MrVoid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Period - это отчётный месяц. Реально день составления акта может не совпадать с отчётным месяцем, поэтому использовать дату составления акта не представляется возможным. Соответственно, этот поле НЕ уникально.
Number - это номер акта. Он уникален. Да, подходящий кандидат в primary key, но на деле он не нужен. Просто используется тот факт, что он уникален.
Назначение базы таково, что она будет использоваться чисто для выгрузки отчётов, а поиска по номеру акта не будет производиться (ну если раз в год найти какой-нибудь акт :) ). Итак, на Period повесить кластерный индекс не получится, а на Period + Number можно. :)
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38881332
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MrVoid
Меня интересует связь между Act (данные по акту) и ActBonus (данные по премиям по каждому работнику в акте).
Когда дошёл до создания таблицы ActBonus, то SQL Server заругался: " There are no primary or candidate keys in the referenced table 'dbo.Act' that match the referencing column list in the foreign key 'FK_Act_ActBonus_ActNumber' ":.


Вот у тебя какой первичный ключ в Act:

constraint PK_Act primary key (Period, Number)

Значит именно эти два поля должны входить и в ActBonus, в его первичный ключ.

Не один ActNumber, а ДВА поля.

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

Тебе надо для начала решить, какие поля будут первичнфм ключём в таблице Act , а затем перепроектировать из этих соображений таблицу ActBonus -- в её ПК должны входить все поля из ПК таблицы Act и все поля из таблицы Worker.
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38881337
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MrVoidPeriod - это отчётный месяц. Реально день составления акта может не совпадать с отчётным месяцем, поэтому использовать дату составления акта не представляется возможным. Соответственно, этот поле НЕ уникально.
Number - это номер акта. Он уникален. Да, подходящий кандидат в primary key, но на деле он не нужен. Просто используется тот факт, что он уникален.


Тут как бы ты должен решить, что использовать в качестве ПК, и всё.
Мне кажется из твоих слов, что Period не должен быть в составе ПК, а должен быть просто атрибутом. Можно было бы сделать его
UNIQUE, но для него неудачно выбран домен -- ты легко запихнёшь в таблицу данные с одинаковыми месяцами, но разными другими частями даты -- число месяца, час, мин. сек. -- так что нужны дополнительные ограничения на домен или поле.
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38882342
MrVoid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
@MasterZiv
Различать Period по часу, минуте и секунде - это уж костыль какой-то. :) Хотя надо подумать. :)

>>Далее ты делаешь глупости -- уникальный ключ не может входит в состав другого ключа, это бессмысленно.
Identifying Relationship, не?

Pro SQL Server 2008 Relational Database Design and Implementation
Relationships come in several different flavors that indicate how the parent table is related to the child. We will look at examples of several different types of relationships in this section:
Identifying , where the primary key of one table is migrated to the primary key of another. The child will be a dependent entity.
...

Не может или бессмысленно? :)
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38883380
Фотография MasterZiv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
MrVoid>>Далее ты делаешь глупости -- уникальный ключ не может входит в состав другого ключа, это бессмысленно.
Identifying Relationship, не?


не. Ваще всё не о том.

MrVoid Pro SQL Server 2008 Relational Database Design and Implementation
Relationships come in several different flavors that indicate how the parent table is related to the child. We will look at examples of several different types of relationships in this section:
Identifying , where the primary key of one table is migrated to the primary key of another. The child will be a dependent entity.
...

Не может или бессмысленно? :)

Тут всё правильно написано, но ты неправильно понимаешь.

migrated тут ключевое слово.

Я же тебе говорю о другом совсем.

Код: plaintext
1.
PK_TBL ( field1, field2 )
UNIQUE (field2)

-- вот это бессмыслица.
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38886021
MrVoid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
@MasterZiv
А как же тогда быть? По сути, уникальность номера акта мне совсем не нужна. Нужен только отчётный период. Быть может, к Period "прибавить" какой-нибудь искусственный ключ (Identity или Sequence)? :)
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38891282
Malter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
MrVoid, да именно так. Вообще по классическому правилу проектирования каждая сущность должна содержать суррогатный ID(PK)

Вам нужно сделать в Act одно поле первичного ключа (ID) и если нужно поставить ограничение уникальности на дополнительные поля Period и Number.
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38892247
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Malter Вообще по классическому правилу проектирования каждая сущность должна содержать суррогатный ID(PK)

Откуда взялось это "классическое правило"(tm)?
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38892277
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинMalter Вообще по классическому правилу проектирования каждая сущность должна содержать суррогатный ID(PK)

Откуда взялось это "классическое правило"(tm)?

Холивар "естественные ключи vs суррогатные ключи"?!
<:o)
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38892287
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mad_nazgulКот Матроскинпропущено...

Откуда взялось это "классическое правило"(tm)?

Холивар "естественные ключи vs суррогатные ключи"?!
<:o)

Я ничего не имею против суррогатных ключей, я не очень понимаю, почему их использование надо называть "классическим(!) правилом (!) проектирования"
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38892344
mad_nazgul
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот Матроскинmad_nazgulпропущено...


Холивар "естественные ключи vs суррогатные ключи"?!
<:o)

Я ничего не имею против суррогатных ключей, я не очень понимаю, почему их использование надо называть "классическим(!) правилом (!) проектирования"

Согласен с вами.
Классическим правилом проектирования можно считать как раз использование естественных ключей.
Ну это если обратиться к классикам :-)
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38892426
Malter
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
mad_nazgulКот Матроскинпропущено...


Я ничего не имею против суррогатных ключей, я не очень понимаю, почему их использование надо называть "классическим(!) правилом (!) проектирования"

Согласен с вами.
Классическим правилом проектирования можно считать как раз использование естественных ключей.
Ну это если обратиться к классикам :-)
Наверное я под КЛАССИЧЕСКИМ подразумевал лучшие практики - дальше можно спорить.

Двойственность мира и возникающие в нем коллизии являются фундаментом для этой практики. Использование суррогатных ключей везде избавляет от множества проблем в реальных системах (не абстрактных или логических моделях).

Я прекрасно понимаю о чем речь и ваше возмущение и не могу не согласиться с тем, что иногда не находится достаточного количества аргументов для того чтобы использовать суррогатный ключ в конкретной таблице. Но если эта реальная система взаимодействующая с другими системами, работающая и модифицирующаяся из года в год, то тем самым дополнительным аргументом станет ваш опыт.
...
Рейтинг: 0 / 0
Помогите с моделью БД
    #38898097
MrVoid
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В общем, прибавил к периоду отчёта суррогатный Id. :D

...
Рейтинг: 0 / 0
15 сообщений из 15, страница 1 из 1
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Помогите с моделью БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


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