Witam,
Mam stworzyć bazę danych o temecie F1. Zaprojektowałem taki schemat i chciałem się dowieczieć czy jest ona dobry bo zaczynam dopieor tworzyć bazy i nie wiem czy dobrze to zrobiłem
http://fotoo.pl/show.php?img=677404_bezantytua-u.jpg.html
Pełna wersja: Baza danych F1
nie trzymasz sie zadnej konwencji, DuZeMaLeLiTEry do tego literowki,
słowem miszmasz, sprawia ze struktura jest nieczytelna.
czy funkcjonalna...?
nie wiem...
... bo nie wiem, co chcesz zrobić...
J.
słowem miszmasz, sprawia ze struktura jest nieczytelna.
czy funkcjonalna...?
nie wiem...
... bo nie wiem, co chcesz zrobić...
J.
jest to jedna z mich pierwszych baz i nie wiem jek je jeszcze towrzyć.
muszę stworzyć bazę a potem zrobić do niej zapytania :
Tworzący widoki (co najmniej 3-5) oraz sekwencje (dla każdego klucza głównego).
Usuwający wszystkie widoki oraz sekwencje.
Usuwający wszystkie wiersze ze wszystkich tabel.
Zawierający co najmniej 5-10 poleceń INSERT dla każdej tabeli.
Zawierający po jednej instrukcji INSERT naruszającej każdy z typów ograniczeń (np. UNIQUE, NOT
NULL, CHECK, klucza głównego, klucza obcego, itp) dla dowolnej tabeli.
Modyfikujący dowolnie wybraną tabelę:
• dodający kolumnę (np. test VARCHAR2(20)),
• dodający ograniczenia do dodanej kolumny (np. NOT NULL),
• usuwający ograniczenia dotyczące dodanej kolumny,
• usuwający dodaną kolumnę.
Zawierający co najmniej 10 – 15 zaawansowanych instrukcji SELECT wykorzystujących np.:
• MIN, MAX, SUM, AVG, COUNT,
• GROUP BY,
• HAVING,
• ORDER BY,
• UNION, INTERSECT, MINUS,
• EXISTS, IN, ALL, ANY,
• CASE,
• złączenie,
• podzapytania,
• funkcje np. do obsługi dat, testów, liczb, itd.,
• zapytania
Tworzący co najmniej 7 - 10 procedur oraz funkcji zapewniających pełną obsługę bazy danych.
Usuwający procedury oraz funkcje.
Tworzący co najmniej 5-10 wyzwalaczy.
Usuwający wyzwalacze.
muszę stworzyć bazę a potem zrobić do niej zapytania :
Tworzący widoki (co najmniej 3-5) oraz sekwencje (dla każdego klucza głównego).
Usuwający wszystkie widoki oraz sekwencje.
Usuwający wszystkie wiersze ze wszystkich tabel.
Zawierający co najmniej 5-10 poleceń INSERT dla każdej tabeli.
Zawierający po jednej instrukcji INSERT naruszającej każdy z typów ograniczeń (np. UNIQUE, NOT
NULL, CHECK, klucza głównego, klucza obcego, itp) dla dowolnej tabeli.
Modyfikujący dowolnie wybraną tabelę:
• dodający kolumnę (np. test VARCHAR2(20)),
• dodający ograniczenia do dodanej kolumny (np. NOT NULL),
• usuwający ograniczenia dotyczące dodanej kolumny,
• usuwający dodaną kolumnę.
Zawierający co najmniej 10 – 15 zaawansowanych instrukcji SELECT wykorzystujących np.:
• MIN, MAX, SUM, AVG, COUNT,
• GROUP BY,
• HAVING,
• ORDER BY,
• UNION, INTERSECT, MINUS,
• EXISTS, IN, ALL, ANY,
• CASE,
• złączenie,
• podzapytania,
• funkcje np. do obsługi dat, testów, liczb, itd.,
• zapytania
Tworzący co najmniej 7 - 10 procedur oraz funkcji zapewniających pełną obsługę bazy danych.
Usuwający procedury oraz funkcje.
Tworzący co najmniej 5-10 wyzwalaczy.
Usuwający wyzwalacze.
Na MySQL-u INTERSECT, MINUS, CHECK?
Zapomnij.
Zapomnij.
przy projektowaniu najlepiej się trzymać jednej konwencji
są rożne, i tak naprawdę nie ma większego znaczenia którą wybierzesz, poza pustym dyskursem...
wybierając jednak jedną metodę - trzeba się jej dość sztywno trzymać
ja np. wszystkie nazwy piszę z małych liter, camel_case
nazywanie indeksów tu też będziesz miał przynajmniej dwa wiodące nurty,
np tabela 'samochody' to indeks do niej można odpowiednio
z prefiksami:
id_samochod
id_samochody
pk_samochod
pk_samochody
to samo, tylko z sufiksami
samochod_id
samochody_id
samochod_pk
samochody_pk
lub tez bez prefiksów i sufiksów czyli
samochod lub samochody
osobiście, ostatnio piszę id_samochod niezaleznie czy to pk czy fk, dla mnie upraszcza zapytania, ale jest mniej czytelne być może.
o ile dla nazw tabel w większości stosowana jest liczba mnoga, tak już dla indeksu są liczne dyskusje, w liczbie mnogiej ma być czy też nie.
znam argumenty za i przeciw większością z tych konwencji.
jaką byś nie wybrał, trzymając się jej ściśle - sprawiasz ze pisanie zapytań staje się prostsze (wystarczy znać nazwę tabeli, a resztę sobie dośpiewasz)
ty tutaj - piszesz jak ci się uda...
np.:
brak jakiejkolwiek konsekwencji jest widoczny z daleka...
nie wspominam już o tym ze złe relacje są tutaj zrobione.
ja osobiście tą tabelę zrobił w ten deseń
dodawanie id_team jest w tej relacji bez sensu.
z tego co piszesz- to czeka Cie duuuzo pisania kodu, i warto jest ułatwić sobie pracę...
**
część z tego co napisałeś nie jest dostępne bezpośrednio w mysql, ale chyba wszystko da się rozpisać w zastępczy sposób
są rożne, i tak naprawdę nie ma większego znaczenia którą wybierzesz, poza pustym dyskursem...
wybierając jednak jedną metodę - trzeba się jej dość sztywno trzymać
ja np. wszystkie nazwy piszę z małych liter, camel_case
nazywanie indeksów tu też będziesz miał przynajmniej dwa wiodące nurty,
np tabela 'samochody' to indeks do niej można odpowiednio
z prefiksami:
id_samochod
id_samochody
pk_samochod
pk_samochody
to samo, tylko z sufiksami
samochod_id
samochody_id
samochod_pk
samochody_pk
lub tez bez prefiksów i sufiksów czyli
samochod lub samochody
osobiście, ostatnio piszę id_samochod niezaleznie czy to pk czy fk, dla mnie upraszcza zapytania, ale jest mniej czytelne być może.
o ile dla nazw tabel w większości stosowana jest liczba mnoga, tak już dla indeksu są liczne dyskusje, w liczbie mnogiej ma być czy też nie.
znam argumenty za i przeciw większością z tych konwencji.
jaką byś nie wybrał, trzymając się jej ściśle - sprawiasz ze pisanie zapytań staje się prostsze (wystarczy znać nazwę tabeli, a resztę sobie dośpiewasz)
ty tutaj - piszesz jak ci się uda...
np.:
Cytat
Kierowca_has_WYSCIG
Kierowca_Team_ID_team
Kierowca_ID_kierowca
WYSCIG_idWYSCIG
Kierowca_Team_ID_team
Kierowca_ID_kierowca
WYSCIG_idWYSCIG
brak jakiejkolwiek konsekwencji jest widoczny z daleka...
nie wspominam już o tym ze złe relacje są tutaj zrobione.
ja osobiście tą tabelę zrobił w ten deseń
Cytat
kierowcy_has_wyscigi
id_kierowca
id_wyscig
id_kierowca
id_wyscig
dodawanie id_team jest w tej relacji bez sensu.
z tego co piszesz- to czeka Cie duuuzo pisania kodu, i warto jest ułatwić sobie pracę...
**
część z tego co napisałeś nie jest dostępne bezpośrednio w mysql, ale chyba wszystko da się rozpisać w zastępczy sposób
eh,
w pierwszym rzucie popraw ortografy w bazie, jesli to praca zaliczeniowa - to dosc kiepsko bedzie wygladac.
czy kierowca może być tylko w jednym zespole? można tak założyć tylko dla uproszczenia, często po sezonie kierowca zmienia team. ja bym zmienił na relację n:n
samochod, co ma sie kryc pod polami 'opony' i 'silnik'?
sponsor... budrzet
pomijając, tutaj nie rozumiem pola id_team zwłaszcza ze dalej masz relacje n:n ..?
mechanik nie jestem przekonany co do specjalnosci - tutaj wychodzi ze mechanik może mieć tylko jedna... a tak raczej nie jest..
nie za bardzo łapię jak chcesz zapisywać tabele przebieg, nie wydaje mi sie to tutaj za bardzo przemyślane.
no i nie mam pojęcia o tabeli student...
w pierwszym rzucie popraw ortografy w bazie, jesli to praca zaliczeniowa - to dosc kiepsko bedzie wygladac.
czy kierowca może być tylko w jednym zespole? można tak założyć tylko dla uproszczenia, często po sezonie kierowca zmienia team. ja bym zmienił na relację n:n
samochod, co ma sie kryc pod polami 'opony' i 'silnik'?
sponsor... budrzet
pomijając, tutaj nie rozumiem pola id_team zwłaszcza ze dalej masz relacje n:n ..?mechanik nie jestem przekonany co do specjalnosci - tutaj wychodzi ze mechanik może mieć tylko jedna... a tak raczej nie jest..
nie za bardzo łapię jak chcesz zapisywać tabele przebieg, nie wydaje mi sie to tutaj za bardzo przemyślane.
no i nie mam pojęcia o tabeli student...
stajnia samochod - tutaj cos mi nie gra z ta relacja..
poza tym na pierwsz rzut oka wydaje sie w miare ok... to juz zalezy od projektu..
pozdrawiam,
J
poza tym na pierwsz rzut oka wydaje sie w miare ok... to juz zalezy od projektu..
pozdrawiam,
J
To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.