Klucz obcy z dwóch tabel? - Czy to możliwe?

0

Cześć !
Robię projekt bazy danych na studia, nic specjalnego, ale natrafiłem na problem z którym nie mogę sobie poradzić, więc prosiłbym w miarę możliwości o sugestie.
W załączniku pokazuje fragment schematu, którego dotyczy problem. Otóż w bazie mam dwa rodzaje osób: prywatne (tabela Person) i osoby z firm (tabela CompanyPerson).
Każda z tym osób może się rejestrować na konferencje (tabela Registration).
W schemacie wyglądało wszystko ok, jednak teraz gdy pisze procedurę umożliwiającą osobie firmowej / prywatnej zrobić rejestrację mam problem z tym, że osoba prywatna nie istnieje w tabeli osób z firm i naprzemian.

Wrzucam kod.

/****** Object:  StoredProcedure [dbo].[AddPersonCompanyToParticipants]    Script Date: 1/6/2016 9:31:41 PM ******/
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO

ALTER PROCEDURE [dbo].[AddPersonCompanyToParticipants]
    @PESEL nvarchar(20),
    @ConferenceDay date,
    @ConferenceId int

AS
BEGIN
    SET NOCOUNT ON;

    DECLARE @CurrentDate date;

    SET @CurrentDate = GETDATE()

    INSERT INTO [dbo].[Registration]
           ([PESEL_FK]
           ,[ConferenceDay_FK]
           ,[ConferenceID_FK]
           ,[DateOfRegistration])
     VALUES
           (@PESEL,
            @ConferenceDay,
            @ConferenceId,
            @CurrentDate)       
END
/****** Object:  Table [dbo].[Registration]    Script Date: 1/6/2016 9:32:41 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Registration](
    [RegistrationId_PK] [int] IDENTITY(1,1) NOT NULL,
    [PESEL_FK] [nvarchar](11) NOT NULL,
    [ConferenceDay_FK] [date] NOT NULL,
    [ConferenceID_FK] [int] NOT NULL,
    [DateOfRegistration] [date] NOT NULL,
 CONSTRAINT [PK_Registration] PRIMARY KEY CLUSTERED 
(
    [RegistrationId_PK] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

GO

ALTER TABLE [dbo].[Registration]  WITH CHECK ADD  CONSTRAINT [FK_Registration_DayOfConference] FOREIGN KEY([ConferenceDay_FK], [ConferenceID_FK])
REFERENCES [dbo].[DayOfConference] ([ConferenceDay_PK], [ConferenceId_PK_FK])
GO

ALTER TABLE [dbo].[Registration] CHECK CONSTRAINT [FK_Registration_DayOfConference]
GO

ALTER TABLE [dbo].[Registration]  WITH CHECK ADD  CONSTRAINT [FK_Registration_Person] FOREIGN KEY([PESEL_FK])
REFERENCES [dbo].[Person] ([PESEL_PK])
GO

ALTER TABLE [dbo].[Registration] CHECK CONSTRAINT [FK_Registration_Person]
GO

ALTER TABLE [dbo].[Registration]  WITH CHECK ADD  CONSTRAINT [FK_Registration_PersonCompany] FOREIGN KEY([PESEL_FK])
REFERENCES [dbo].[PersonCompany] ([PESEL_PK])
GO

ALTER TABLE [dbo].[Registration] CHECK CONSTRAINT [FK_Registration_PersonCompany]
GO
0

Da sie tylko po co?

Za szybko odpisałem,FK nie może wskazywać na PK z 2 tabel, założyłem bez zagłębiania w treść że masz dwa FG nie jeden

Połącz tabele person z comapnyperson i dodaj atrybut typ: firma/osoba.

0
Panczo napisał(a):

Da sie tylko po co?

Jestem bardzo ciekaw jak. Bo jeśli twierdzisz, że się da to nie zrozumiałeś problemu.

Połącz tabele person z comapnyperson i dodaj atrybut typ: firma/osoba.

natomiast to jest jedyne słuszne rozwiązanie, w szczególności że większość pól się i tak pokrywa

0

Dzięki Panowie ! Zastosowałem to rozwiązanie i widzę, że rozwiązują się moje problemy... Jednak zrodził się kolejny problemik :)
Person może ale nie musi mieć konto internetowe (login, hasło).
Mam tabelkę Konta - tam powędrował PESEL szczęśliwców, którzy takie konto mogą mieć. Jednak istnieje też coś takiego jak konto dla firmy, a firma nie ma PESELU, tylko NIP i jest w zupełnie innej tabeli... mam zrobić dwie tabele Konto?

Dodaje zrzut ekranu dla rozjaśnienia sprawy.

0

Ale w diagramie masz nadal companyperson, person i emploee

Uprościłbym to do jednej tabeli Persons z kolumną type i tak wpis
dla pracownika ma w type Emploee (id dowolne)
dla personcompany w type personcompany (id dowolne)
dla person w type person (w id PESEL)

i to accountlogin ma foregin key z tabeli persons, dzieki temu łatwo utrzymasz unikalność loginów.

Jeżeli to firma ma mieć konto, zakładasz wpis w persons i nadajesz login...
dodatkowo dodajesz pole CompanyID w persons jako fk do company, lub tworzysz tabele definiującą powiązania companyperson <->compan

1

powiem szczerze, że nie czaję tych tabel - jak dla mnie to to powinna być jedna tabela i tyle. Masz 5 tabel. Login jest w 4, firstname, lastname w 3, adres w 4. Normalnie paranoja jakaś. Potem jest to bardzo trudne do ogarnięcia.

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0