mam taki projekt do zrobienia, aplikacje zarządzającą stacją paliw. Muszę zrobić bazę danych na oraclu. Chciałbym się dowiedzieć czy macie jakieś artykuły, www z tutkami od podstaw, od czego zacząć projektowanie bazy i jak się za to zabrać żeby baza miała prawidłową strukturę? Może Wy macie jakiś własne sposoby na tworzenie struktury bazy?

Mozesz zaczac od drugiej strony - czego nie robic;-)

Jest ksiazka "SQL Antipatterns" (http://pragprog.com/book/bksqla/sql-antipatterns) (w przyszlym roku ma byc polskie tlumaczenie w Helionie). Szybko sie czyta i jest napisana raczej dla poczatkujacych. Osobiscie nie zgadzam sie z pewnymi tezami autora, np. krytykuje wzorzec EAV, a jako rozwiazanie innego antywzorca podaje wlasnie skrytykowany wczesniej EAV, ale ogolnie jest to dobra pozycja na poczatek;-)

Oprocz tego mozesz sobie jeszcze poczytac:

http://www.ssw.com.au/ssw/Standards/Rules/...NullsTextFields
http://www.nyx.net/~bwunder/dbChangeControl/standard.htm

ale nie wiem, czy Cie nie zanudzi;-)

Jezeli dopiero zaczynasz zabawe z bazami danych, to niestety, ale bedziesz uczyl sie na wlasnych bledach;-)

tylko właśnie chodzi o to że potrzebuję w miarę szybko to sklecić bo muszę zrobić projekt... prosił bym o pomoc w tej sprawie schemat stacji

Szybko baz danych się nie buduje.
Trzeba troszkę czasu by poukładać relację.
Mogę pomóc ale nie na wczoraj

Chyba już po fytkach, jako że trochę czasu minęło.

Tak na szybko to pomyślę na głos. Nie jestem programistą, więc napiszę nie o metodach, lecz o tabelach.
Moim zdaniem na swoim diagramie trochę się rozminąłeś z rzeczywistością, tzn. nie tak wygląda składowanie i przetwarzanie danych przez aplikacje komercyjne. Ja bym to zrobił inaczej.

1)
Tabela 'Klient'.
Proponuję dołożyć:
- pole 'Firma', number(1). Wartość 1 będzie wskazywać na podmiot gospodarczy, a 0 na osobę fizyczną.
bez sensu mieć dodatkowe tabele 'Prywatny' i 'Firma', które nie wnoszą nic do tematu
REGON raczej nie jest potrzebny, trudno mi znaleźć dla niego zastosowanie
- pole 'id_podatnika', varchar2(13) . Dla podmiotu gospodarczego będzie to numer NIP, dla osoby fizycznej numer PESEL (wg nowych przepisów). Chyba że chcesz kontrolować wartości, jakie będzie wpisywał użytkownik, wtedy warto mieć dwa dedykowane pola, czyli NIP i PESEL.
- pole 'id_rabatu', które będzie wskazywać na rodzaj i wartość domyślnego rabatu (patrz niżej)

2)
Tabela 'Rabaty':
- pole 'id_rabatu'
- pole 'rodzaj_rabatu' (np. 'podm.gosp.', 'os.fizyczna', 'inny1', 'inny2' 'VIP'')
- pole 'wart_rabatu'
Ot, zwykła tabela słownikowa.

Pożytek? Jak właścicielowi/managerowi przyjedzie do głowy np. zmienić wartość udzielanego rabatu dla firm, to wystarczy zmienić go w jednej tabeli (Rabaty), nie ingerując w tabelę 'Klient'.

3)
Tabela 'Paliwo', chociaż ja bym ją nazwał np. 'Asortyment'.
Traktowałbym ją jako tabelę słownikową, która przechowuje nazwy towarów (czyli nazwy paliw)
- pole 'ID_paliwa'
- pole 'nazwa'
- pole 'stawka_VAT'
zrezygnowałbym z pól 'znizka_' w tej tabeli, gdyż rabat bywa udzielany klientom, a nie paliwom (patrz wyżej)
stawka podatku dla celów rozliczeń z fiskusem
cenę proponuję przechowywać w magazynie (dystrybutorze), gdyż cena zmienia się w czasie, jest różna na różnych dostawach

4)
Tabela hm... 'Magazyn'. Jak go zwał, tak go zawał, chodzi o zawartość zbiorników.
- pole 'ID_paliwa'
- pole 'ID_dostawcy'
- pole 'ID_dystrybutora'
- pole 'cena_netto'
- pole 'stawka_VAT'
- pole 'cena_brutto'
- pole 'ilosc'

5)
Tabela 'Dystrybutory'
- pole 'ID_dystrybutora'
- pole 'nazwa_dystrybutora'
- pole 'pojemnosc'

6)
Tabela 'Transakcje', po twojemu historia_transakcji
- 'ID_transakcji'
- 'ID_dokumentu'
- 'ID_paliwa'
- 'ilosc'
- 'stawka_vat'
- 'cena_netto_przed_rabatem'
- 'cena_brutto_przed_rabatem'
- 'cena_netto_po_rabacie'
- 'cena_brutto_po_rabacie'

7)
Tabela 'Dokumenty'
- 'ID_dokumentu'
- 'ID_klienta'
- "ID_pracownika'
- 'rodzaj_dokumentu' (paragon fiskalny lub faktura VAT)
- 'wartosc_netto'
- 'wartosc_brutto'
- 'stawka_VAT'

8)
Być może z VATem przesadziłem, ale gdybyś miał obsłużyć inne rodzaje produktów, np. artykuły rolnicze lub prasę/książki, to właśnie podatek VAT wszystko komplikuje. Inna rzecz, że podatek to podstawa
Stawka VAT w tabeli 'Paliwo' (słwoniku z asortymentem) jest po to, aby system wiedział, jaki VAT obowiązuje w chwili sprzedaży na dany produkt.
Stawka VAT w tabeli 'Transakcje' jest do celów tak bieżących, jak i historycznych.
Np. dzisiaj sprzedajemy paliwo z VATem 23% ('Paliwa'), ale w roku 2010 sprzedawaliśmy z VATem 22% ('Transakcje'). 'Paliwa' mają VAT aktualny, a 'Transakcje' historyczny, więc jest git.
Magazyn - stawka VAT jest wskazana, w razie gdybyś w magazynie oprócz paliwa trzymał jeszcze ziemniaki lub prasę.

Rozliczenia ZUSu i wypłat na razie pominę.

9)
Pytanie jak najbardziej na miejscu - skąd ma się wziąć towar w magazynie?
Należałoby go wprowadzić na magazyn jako fakturę zakupu VAT.
Czyli byłaby potrzebna tabela 'Dostawcy' i tabela przechowująca nagłówki dokumentów zakupu 'Faktury_zakupu'.

10)
Myślę, że dużo ci namieszałem, ale chciałem pokazać z grubsza logikę aplikacji.
Czyli towary kupujemy od dostawców (wprowadzamy na magazyn), sprzedajemy klientom (zdejmujemy z magazynu).
Dostawy przychodzą w różnych cenach w różnym czasie, a stan magazynowy jest zmienny w czasie.
Towar sprzedajemy klientowi, który w zależności od rabatu, który się mu należy, płaci mniej lub więcej.
Itd, itp.

Jak już ktoś napisał wcześniej, trudno pomóc szybko i 'od ręki'.

pozdrawiam