Model bazy danych - transakcje

Witam, mam pytanie. Czy da się wykonać relację między tabelami operując tylko na kluczach podstawowych a raczej kluczach złożonych? pytam, bo muszę wykonać model bazy transakcji, jednak użyłem klucze obce i wykładowca napisał, że nie mogą być żadne klucze obce.

Może przez normalizacje? Czyli utworzyć tabele pośrednią zawierającą tylko odniesienia...

Raczej nie chodzi o normalizację. Mogę wkleić to co mi napisał.

To dawaj

Może mu chodziło o to żeby zastosować klucze "biznesowe" - czyli np. nr faktury + id klienta.
Albo o to żeby nie używać foreign key w definicji bazy...
A może o to że zrobiłeś relację jeden-do-wielu zamiast wiele-do-wielu.
...

O to treść co mi napisał:
Jedna strona transakcji jest klient (tabela klient, w której są dane
klienta i żadne klucze obce!!!).

Nie wiem co jest drugą stroną transakcji - ???

Transakcja to realizacja zamówienia czyli główna tabela będzie tabela
Zamowienia, w której jest zawarty nagłówek zamówienia: numer zamówienia,
połączenie z klientem, data zamówienia, wartość zamówienia, itp.

Ale zamówienie jest wielopozycyjne czyli (tak jak na zajęciach
pokazywałem) istnieje druga tabela np. Pozycje_zamówienia, która jest w
relacji z tabelą zamówienia i z drugą stroną transakcji (np. produkty)

Mowa była o kluczach złożonych, więc zrobiłem tak:

create table Klient(
ID_Klienta  integer not null,
NrZamowienia integer not null,
Imie varchar(25) null,
Nazwisko varchar(40) null,
Adress varchar(40) null,
Miasto varchar(50) null,
KodPocztowy varchar(10) null,
Telefon varchar(20) null,
constraint ID_Klienta
primary key (NrZamowienia)
);

create table Zamowienia (
ID_Klienta  integer  not null,
NrZamowienia integer not null,
PozycjaZam integer not null,
StatusZam varchar(6) null,
NazwaProjektu varchar(100) null,
DataZam date,
CenaProjektu varchar(20) null,
constraint ID_Klienta
primary key (NrZamowienia, PozycjaZam)
);

 

Tylko , że tu nagłówkiem jest ID_Klienta ale jak połączyć tabele nie używając kluczy obcych?

Chodzi o to że w tabeli Klient nie powinno być pola NrZamowienia, a primary key powinno być ustawione na ID_Klienta.

...chyba że Klient.NrZamowienia to nie relacja tylko generator i wtedy trzeba tylko zmienić primary key a prowadzącemu wyjaśnić że pole Klient.NrZamowienia to nr ostatniego lub następnego zamówienia dla danego klienta. W takiej sytuacji trzeba też zmienić PK w zamówieniach:

primary key (ID_Klienta, NrZamowienia, PozycjaZam)

A jak połączyć te tabele bez kluczy obcych? Wykładowcy chodzi aby były dwie strony Klient/Odbiorca gdzie klient składa zamówienie a odbiorca odbiera i realizuje.

ja bym zrobił klienta i odbiorcę w jednej tabeli:

Klient:
ID - primary key
Nazwa

Zamówienia:
ID - primary key
Data
Numer
IDZamawiajacego /w relacji z ID tabeli klient/
IDOdbiorcy /w realacji z ID tabeli klient/

ZamówieniaDetale:
ID - primary key
IDZamowienia /w relacji z ID tabeli zamówienia/
LP
Nazwa
Cena
ilosc

W jednej tabeli ale mimo tego trzeba użyć kluczy obcych a wykładowca nie chce aby uzywać kluczy obcych, jedynie chce model zrobiony w dowolnym programie np w word i zapisac jako jpeg i przeslać na mail. Czyli pokazac aby zaakceptował/

Powiem szczerze nie rozumiem go. Możemy się spierać o szczegóły, ale ogólna koncepcja musi być taka, a nie inna. Trochę w życiu baz komercyjnych napisałem i nie widzę innego podejścia do tematu. Można zastąpić ID generowane przez system np. NIPem klienta, ale nie zawsze jest on dostępny. Czasami model biznesowy wymusi pewną nadmiarowość danych, ale problem przez Ciebie opisany jest klasycznym przykładem od którego zaczyna się naukę programowania relacyjnych baz danych: klient - faktura - detale faktury.

powiem więcej takie podejście zwalnia programistę od pisania zbędnego kodu np. na serwerze SQL wymuszam relację między tabelami zamówienie i zamówieniedetale z usuwaniem kaskadowym. Jeżeli w programie usunę rekord z tabeli zamówienie nic nie muszę dopisywać na temat usuwania powiązanych rekordów w tabeli zamówieniadetale zrobi to za mnie serwer.

To wg.ciebie jest słabe nazewnictwo kolumn? Co prawda odchudziłem tabele Zamówienie do 4 pozycji.

Sama idea wygląda tak że mamy dodatkową tabele w której przechowujemy zbiorcze dane z dwóch tabeli, co w zasadzie jest normalizacją tylko że w definicji nie ustawiamy kluczy obcych... Inaczej założenia nie mają sensu żadnego... Bo to nie ma żadnego praktycznego zastosowania wg. mnie i jest dość nie potrzebne.

Tu były tabele...

tak z praktycznego punktu widzenia nr zamówienia jako klucz jest złym pomysłem bo w nowym roku zwykle zaczyna się numerację od 1 więc nastąpi konflikt. Jeżeli już to klucz złożony numer zamówienia + dodatkowe pole rok (w firmie może być kilka równoległych ciągów faktur wystawianych np. przez sklep, serwis itp. więc do klucza trzeba dodać jeszcze jedno pole) Czy w tabeli będą 4 pola czy 40 to już wg mnie nie ma znaczenia zależy to od specyfiki firmy i może zostać ustalone później bez drastycznych zmian w schemacie bazy . Ja osobiście preferuje klucze automatycznie nadawane przez system, ale to już kwestia gustu i przyzwyczajeń oraz platformy.

dalej z praktyki jeżeli jest kod pocztowy to musi być poczta i miejscowość. Szczególnie na wsi miejsce zamieszkania/prowadzenie działalności nie musi zgadzać się z pocztą. np Olsztynek 12-345 Olsztynek Duży.

dalej cena usługi jako varchar ? a jak to chcesz sumować real, double lub coś podobnego

i ostatnia uwaga nr zamówienia jako int to też odważna decyzja

cofam co napisałem o nr zamówienia bo z rozpędu pomyliłem z nr faktury

A NrZamowienia to w której tabeli nie powinno być kluczem PK? NrZamowienia wg. ciebie jaką powinien miec wartość? int IDENTINTY?
Powiem tak, ten schemat jest tworzony w Sybase, dalej, co do ceny, to chciałem dać nie typ varchar a money ale w sybase takiej wartości nie ma.
Co do kluczy złożonych to w Zamowieniach tworzyłem tak:
primary key (ID_Klienta),
constraint (kolumna 1, kolumna 2)
ale na razie dałem jedną kolumnę.

sprawdziłem w dokumentacji sybase i można money jak i smallmoney ale jak daje cene 83 to wyświetla się 83.000 więc dałem numeric(10,2) i zupełnie inaczej zaprojektowałem model bazy bez łączenia tabel.

jeżeli chodzi o nr zamówienia jako klucz to może być. Miałem jakiś blackout i pomyślałem o nim jak o numerze faktury.
O ile nr faktur zwykle zerują się w nowym roku finasowym to numer zamówienia może iść od 0 do dowolnej liczby . Wrzuć strukturę na forum