Должен ли я продублировать свою таблицу для правильного нормализованного проектирования базы данных?

Question

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

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

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

Вот как выглядит мой дизайн:

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

Должен ли я дублировать таблицу tblGiverReceiver и переименовать каждую из них в tblGiver / tblReceiver, или я могу связать таблицутаким образом вернуться к самому себе?

РЕДАКТИРОВАТЬ: Я прочитал предлагаемую ссылку от товарища stackoverflow-er ( Как вы можете представить наследование в базе данных? ), однако поставленный вопросне то, что я искал.

Answer 1

Я подумал, что вам может быть полезно увидеть SQL DDL для диаграммы схемы в моем предыдущем ответе.

Этот DDL также был сгенерирован из нашего инструмента NORMA. Мне потребовалось около 30 секунд, чтобы выбрать подходящие варианты, а затем вуаля! через миллисекунду или около того мы имеем SQL DDL в пятой нормальной форме.

CREATE SCHEMA "Donations"
GO

CREATE TABLE "Donations".Person
(
    personNr int NOT NULL,
    addressNr int NOT NULL,
    firstName nchar(30) NOT NULL,
    languagePref nchar(15) NOT NULL,
    lastName nchar(40) NOT NULL,
    nickName nchar(100) NOT NULL,
    title nchar(50) NOT NULL,
    CONSTRAINT Person_PK PRIMARY KEY(personNr)
)
GO


CREATE TABLE "Donations".Address
(
    addressNr int NOT NULL,
    address1 nchar(40) NOT NULL,
    address2 nchar(40) NOT NULL,
    country nchar(40) NOT NULL,
    postalCode nchar(10) NOT NULL,
    province nchar(30) NOT NULL,
    address3 nchar(40),
    CONSTRAINT Address_PK PRIMARY KEY(addressNr)
)
GO


CREATE TABLE "Donations".Donation
(
    donationNr int NOT NULL,
    amount decimal(6,2) NOT NULL,
    "date" datetime NOT NULL,
    personNr int,
    CONSTRAINT Donation_PK PRIMARY KEY(donationNr)
)
GO


CREATE TABLE "Donations".Payment
(
    paymentNr int NOT NULL,
    amount decimal(6,2) NOT NULL,
    "date" datetime NOT NULL,
    personNr int,
    CONSTRAINT Payment_PK PRIMARY KEY(paymentNr)
)
GO


ALTER TABLE "Donations".Person ADD CONSTRAINT Person_FK FOREIGN KEY (addressNr) REFERENCES "Donations".Address (addressNr) ON DELETE NO ACTION ON UPDATE NO ACTION
GO


ALTER TABLE "Donations".Donation ADD CONSTRAINT Donation_FK FOREIGN KEY (personNr) REFERENCES "Donations".Person (personNr) ON DELETE NO ACTION ON UPDATE NO ACTION
GO


ALTER TABLE "Donations".Payment ADD CONSTRAINT Payment_FK FOREIGN KEY (personNr) REFERENCES "Donations".Person (personNr) ON DELETE NO ACTION ON UPDATE NO ACTION


GO

Answer 2

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

Таблицы и взаимосвязи начинаются как констатация фактов, таких как «У человека есть LanguagePreference». Я указал факты и затем использовал наш NORMA tool для создания схемы проекта. Извините, но я не смог понять концепцию «процентных сумм», поэтому она не включена.

Вот схема:

Вот факты, из которых была сгенерирована схема.

Вот ограничения.