tabela zależna
Teraz skomplikujmy trochę nasze zapytania. Dodajmy do naszej bazy nową tabelę zadań z zadaniami dla naszych pracowników. Zobaczmy, jakie wpisy zawiera:
SELECT * FROM task
Wynik takiego żądania:
ID | identyfikator_pracownika | nazwa | termin ostateczny |
---|---|---|---|
1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 |
2 | 2 | Napraw błąd w backendzie | 2022-06-15 |
3 | 5 | Kup kawę | 2022-07-01 |
4 | 5 | Kup kawę | 2022-08-01 |
5 | 5 | Kupię kawę | 2022-09-01 |
6 | (ZERO) | Posprzątaj biuro | (ZERO) |
7 | 4 | Ciesz się życiem | (ZERO) |
8 | 6 | Ciesz się życiem | (ZERO) |
Ta tabela ma tylko 4 kolumny:
- id — unikalny numer zadania (i wierszy w tabeli);
- id_pracownika — identyfikator pracownika z tabeli pracowników, do którego przypisane jest zadanie;
- name — nazwa i opis zadania;
- termin – czas, w jakim zadanie musi zostać wykonane.
Zwróć uwagę na kilka niuansów. Zadanie N6 nie ma identyfikatora pracownika, nie mamy osoby sprzątającej. Zadanie jest, ale nie ma wykonawcy. Zdarza się.
Również zadania 6-9 nie mają ustalonego terminu. Dzieje się tak, gdy zadanie musi być wykonywane regularnie i nieprzerwanie. Na przykład biuro trzeba codziennie sprzątać, ale trzeba też codziennie cieszyć się życiem :)
Jeśli jedna tabela używa identyfikatorów z innej tabeli, wówczas taka tabela jest nazywana zależną .
Zapytanie dotyczące wielu tabel
Tutaj widzimy w tabeli zadań, że są dwa zadania „Cieszyć się życiem”. Skąd wiemy, kim są ci szczęściarze?
Aby to zrobić, w SQL możesz wykonać zapytanie w dwóch tabelach jednocześnie. Ogólnie rzecz biorąc, w SQL można wysyłać zapytania do dowolnej liczby tabel w tym samym czasie. Ogólny format takiego wniosku to:
SELECT columns
FROM Table 1, table 2, tableN
Ważny! Jeśli napiszesz zapytanie do kilku tabel jednocześnie, w rezultacie otrzymasz tak zwany iloczyn kartezjański wierszy tabeli. Każdy rząd z pierwszej tabeli zostanie przyklejony do każdego rzędu z drugiej tabeli i tak dalej.
Oznacza to, że jeśli masz 5 wierszy w pierwszej tabeli i 10 wierszy w drugiej, to łącznie będziesz mieć 50 wierszy. W Javie to zapytanie wyglądałoby mniej więcej tak:
for (String row1 : table1)
{
for (String row2 : table2)
{
System.out.println(row1 + row2);
}
}
Napiszmy nasze zapytanie do dwóch tabel jednocześnie i zobaczmy, co się stanie:
SELECT * FROM employee, task
I wynik tego zapytania:
ID | nazwa | zawód | wynagrodzenie | wiek | ID | pracownik | _ID | nazwa | termin ostateczny |
---|---|---|---|---|---|---|---|---|---|
1 | Iwanow Iwan | Programista | 100000 | 25 | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 | |
2 | Pietrow Pietr | Programista | 80000 | 23 | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 | |
3 | Iwanow Siergiej | Próbnik | 40000 | trzydzieści | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 | |
4 | Rabinowicz Mojsza | Dyrektor | 200000 | 35 | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 | |
5 | Kirienko Anastazja | Kierownik biura | 40000 | 25 | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 | |
6 | Vaska | kot | 1000 | 3 | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 | |
1 | Iwanow Iwan | Programista | 100000 | 25 | 2 | 2 | Napraw błąd w backendzie | 2022-06-15 | |
2 | Pietrow Pietr | Programista | 80000 | 23 | 2 | 2 | Napraw błąd w backendzie | 2022-06-15 | |
3 | Iwanow Siergiej | Próbnik | 40000 | trzydzieści | 2 | 2 | Napraw błąd w backendzie | 2022-06-15 | |
4 | Rabinowicz Mojsza | Dyrektor | 200000 | 35 | 2 | 2 | Napraw błąd w backendzie | 2022-06-15 | |
5 | Kirienko Anastazja | Kierownik biura | 40000 | 25 | 2 | 2 | Napraw błąd w backendzie | 2022-06-15 |
W sumie mamy 48 linii wyników, ale tutaj podałem tylko 11. Inaczej po prostu nie starczy miejsca.
Zwróć uwagę na trzy rzeczy:
- Kolumny o tych samych nazwach: id . Jest to identyfikator z tabeli pracowników i identyfikator z tabeli zadań .
- Wiersze każdej tabeli są powtarzane. W lewej kolumnie po identyfikatorze 6 następuje ponownie identyfikator = 1.
- Mamy nonsensowne wiersze, w których na przykład id (z tabeli pracowników) wynosi 6, aw tym samym wierszu id_pracownika wynosi 1.
Usuwanie bezsensownych linii
W naszej tabeli wynikowej jest zbyt wiele wierszy , która jest iloczynem kartezjańskim wszystkich wierszy dwóch tabel pracownik i zadanie .
Logicznie rzecz biorąc, jeśli wiersz id_pracownika wynosi 3, to powinien trzymać się tylko wiersza z tabeli pracowników, w którym id wynosi 3. Spróbujmy naprawić to nieporozumienie za pomocą WHERE.
Napiszmy takie zapytanie:
SELECT * FROM employee, task
WHERE emploee.id = task.emploee_id
I wynik tego zapytania:
ID | nazwa | zawód | wynagrodzenie | wiek | ID | identyfikator_pracownika | nazwa | termin ostateczny |
---|---|---|---|---|---|---|---|---|
1 | Iwanow Iwan | Programista | 100000 | 25 | 1 | 1 | Napraw błąd w interfejsie użytkownika | 2022-06-01 |
2 | Pietrow Pietr | Programista | 80000 | 23 | 2 | 2 | Napraw błąd w backendzie | 2022-06-15 |
4 | Rabinowicz Mojsza | Dyrektor | 200000 | 35 | 7 | 4 | Ciesz się życiem | (ZERO) |
5 | Kirienko Anastazja | Kierownik biura | 40000 | 25 | 3 | 5 | Kup kawę | 2022-07-01 |
5 | Kirienko Anastazja | Kierownik biura | 40000 | 25 | 4 | 5 | Kup kawę | 2022-08-01 |
5 | Kirienko Anastazja | Kierownik biura | 40000 | 25 | 5 | 5 | Kupię kawę | 2022-09-01 |
6 | Vaska | kot | 1000 | 3 | 8 | 6 | Ciesz się życiem | (ZERO) |
Dobrą wiadomością jest to, że bezsensowne wiersze zniknęły: id z pierwszej kolumny jest zawsze równe id_pracownika.
Zła wiadomość jest taka, że zadania, które nikomu nie są przypisane, takie jak sprzątanie biura, odeszły w niepamięć. Ich identyfikator_pracownika miał wartość NULL, więc zostały one odrzucone po zakończeniu WHERE.
GO TO FULL VERSION