Podstawy
4 godz. 8 min · Bazy Danych · Full-stack i Programowanie
Pierwszy rozdział wprowadza w historię powstania języka. Wspomnimy o standardach, wykorzystywanych wersjach i podzbiorach SQL’a. Zaraz potem wskoczymy w pierwsze poważne operacje, które pozwolą na pełny cykl tworzenia, zasilania bazy danych i wyciągnięcia z niej wybranych informacji. Rozwikłamy też tajemniczy akronim - CRUD.
Skoro potrafimy już tworzyć bazę i tabele, w które możemy wstawić nowe wiersze, dowiemy się więcej o bardzo ważnej funkcji bazy danych: weryfikacji danych. Zostaną zaprezentowane mechanizmy i techniki, które pomogą utrzymać spójność danych.
W kolejnych lekcjach znajduje się opis serca SQL’a, czyli polecenia wybierającego dane i możliwości i opcji z nim związanych. Od przekształcenia bazy danych w prosty kalkulator, aż do warunków filtrowania wybieranych danych (klauzulą WHERE), sortowania ich (klauzulą ORDER BY), czy ograniczania dużych zestawów wynikowych - w tym wsparcia do paginacji.
SQL jest językiem obsługi relacyjnych baz danych. Dlatego najwyższy czas, aby wspomnieć o relacjach i tym w jaki sposób rozszerzają one możliwości wyszukiwania danych oraz pozwalają zobrazować powiązania między danymi w bazie. Dowiesz się o różnych rodzajach połączeń między tabelami i jak te połączenia (zwane JOIN’ami) pozwalają wybrać to, czego potrzebujesz.
Kolejny rozdział dotyczy grupowania danych (wykorzystując klauzulę GROUP BY) i związanych z tym nowymi możliwościami. Dowiesz się tutaj też w jaki sposób agregować pogrupowane dane i jak takie zagregowane dane filtrować.
Przekonasz się, w jaki sposób można zapamiętywać trudne lub często wykonywane zapytania, wykorzystując do tego widoki (VIEWS) i jak można poprawić wydajność pobierania z nich danych. Przykładowo zastosujemy widoki zmaterializowane (MATERIALISED VIEWS). W tym rozdziale przećwiczysz też możliwość zapisywania danych przez widoki.
Z baz danych korzysta zwykle wielu użytkowników. Aby operacje, które wykonują na wspólnej bazie nie spowodowały nieoczekiwanych konsekwencji, wykorzystuje się mechanizm transakcji. W tym rozdziale wytłumaczymy Ci w jaki sposób użytkownicy mogą modyfikować równolegle te same dane. Tutaj też dowiesz się o poziomach izolacji transakcji i jak używać ich w różnych sytuacjach bazodanowych.
Przy pracy z większą ilością danych, bardzo szybko doświadczysz spowolnienia wykonywania zapytań. O tym jak je przyspieszyć dowiesz się właśnie w tym rozdziale. Zwiększanie wydajności zapytań jest tematem rozległym i zaawansowanym. Tutaj będziesz miał szansę poznać podstawy, w tym - po co są i jak używać indeksów, w jaki sposób analizować jak zapytania są wykonywane i jakie jeszcze są metody wydajniejszego odczytywania danych.
Kurs jest dla osób początkujących, rozpoczynających przygodę z bazami danych. Nie wymaga się znajomości SQL'a ani zaawansowanej wiedzy dotyczącej baz danych. Warto wiedzieć co to są relacyjne bazy danych. Dobrze mieć dostęp do ulubionego silnika bazy danych, ale nie jest to wymagane.
Witaj w poprzednich rozdziałach dowiedziałeś się mnóstwa
rzeczy dotyczących baz danych i języka sql na przykładzie tabeli
do potencjalnej gry przygodowej ale bazy danych obsługiwane
przez sql nie nazywały by się relacyjnymi gdyby nie były stworzone
do opisywania relacji pomiędzy różnymi bytami w
tym rozdziale pokażę ci jak rozszerzyć bazy o nowe tabele i definiować
relacje między nimi a także jak łączyć je w zapytaniach nareszcie
nadchodzi ten moment dodajemy drugą tabelę wreszcie
będziemy mogli przechowywać dane powiązane z bohaterami i
określić między nimi relacje zanim to zrobimy dwa
słowa na temat typów relacji między encjami rozróżniamy
trzy główne typy relacji pomiędzy encjami pozwól że zilustruję
je je konkretnym przykładem uproszczonej bazy
danych filmów załóżmy że chcesz przechowywać informacje o filmach tworzysz
w takim razie encję film która opisuje cechy
filmu w filmach grają aktorzy wiadomo
że w każdym filmie może grać w wielu aktorów i każdy aktor może
grać w wielu filmach to sprawia że pomiędzy tymi
encjami występuje relacja wiele do wielu teraz
film jest wyprodukowany przez producenta każdy
film ma jednego producenta a jeden producent może
wyprodukować wiele filmów taka relacja jest zwana
jeden do wielu jest ona najczęściej spotykaną
relacją pomiędzy encjami danych na
koniec wyobraź sobie że producent oprócz zwykłych danych takich jak
nazwa data powstania i tym podobne ma też większe
dane jak na przykład logo czy pozycja geograficzna głównej
siedziby takie dane które obciążają operacje bazodanowe żeby
odciązyć te operacje można przenieść te dane
producenta do osobnej encji każdy producent ma
jeden taki zestaw danych i każdy zestaw jest przyporządkowany tylko
do jednego producenta ta relacja to jeden do jednego
tak jak poprzednie dwa typy są powszechnie
stosowane ten stosuje się w bardzo specyficznych sytuacjach
i warto zawsze rozważyć czy na pewno chcemy wydzielać jakieś
dane do osobnej tabeli czasami rzeczywiście jest
warto a taka decyzja jest na przykład podyktowana względami wydajnościowymi
w przypadku gdy część danych jest
często aktualizowana a część dość rzadko wtedy
dla przyspieszenia zapytań rozdziela się te dane na osobne
tabele które są ze sobą w relacji jeden do
jednego my natomiast na dzień dobry wykorzystamy
drugi typ z wymienionych czyli jeden do wielu i
pomoże nam w tym klucz obcy jak jak
o tym już za chwilę mamy
naszych bohaterów teraz przydałoby się ich w coś wyposażyć nie
będą przecież iść do walki z potworami z gołymi rękami w
takim razie musimy stworzyć miejsce
tabele w której będziemy trzymać zapisywać
ich ekwipunek pomyślmy jakie atrybuty
chcielibyśmy przechowywać w tej tabeli no na
pewno nazwę i typ ekwipunku mówiąc
o typie chcemy rozróżnić czy to jest hełm
topór zbroja czy może jakiś
zwój magiczny zauważ że na kolorowo podświetlane
są te dwie nazwy to oznacza że użyłem nazw zastrzeżonych nie tyle
zastrzeżonych co wykorzystywanych w sql i jak
już wcześniej wspomniałem lepiej unikać jest używania takich nazw
dlatego dodamy tutaj prefiks dodatkowo
nazwa kolumny equipment name jest czytelniejsza od
samego name bo wiadomo o co chodzi i w zapytaniach
wtedy jest też to czytelniejsze więc mamy nazwę typ
powiedzmy że zbroje będą miały charakterystykę obrony
bronie ilość zadawanych obrażeń no i jeszcze
durability które będzie opisywało
ile razy możemy użyć jakiś element ekwipunku jeżeli
ma ograniczone ograniczoną ilość użyć a
także ilość gdzie w przypadku na przykład strzał albo
butelek z napojami magicznymi chcemy
przechowywać ich ilość którą dany bohater posiada tak jak
w przypadku bohaterów tak w przypadku ekwipunku warto
by dodać kolumnę która będzie unikanie identyfikowała
dany element ekwipunku tradycyjnie będzie ona się
nazywała id identifier z prefiksem żeby
było wiadomo czego to jest identyfikator i będzie ona naszym
kluczem głównym jeszcze przypiszmy jakiego typu
będą to dane identyfikator standardowo liczba całkowita
equivalent name ciąg znaków o zmiennej długości tak
samo typ będziemy po prostu na razie wpisywać jaki to jest typ ekwipunku
armor wyrażany w liczbach całkowitych obrażenia
też wyrażone w liczbach całkowitych wytrzymałość także
i ilość także liczby całkowite dobrze
mamy wszystkie nasze atrybuty teraz musimy używając
tych atrybutów stworzyć zapytanie które tworzy nam tabelę posiadającą
właśnie takie kolumny jako ćwiczenie proponuję ci samemu
spróbować teraz napisać to zapytanie
zapauzuj wideo jeżeli potrzebujesz chwili do tego i
tak to wygląda dużo się nie zmieniło ale jednak w ten sposób
mamy zapytanie które możemy uruchomić i które
nam stworzy tabelę odświeżmy sobie widok tabel
i nasza tabela się tutaj pojawiła
no dobrze mamy tabelę ekwipunku gdzie możemy wpisywać nasz
ekwipunek mamy tabelę bohaterów ale teraz
jak połączyć jedno z drugim jak powiedzieć bazie
że ten ekwipunek należy do tego bohatera tu
z pomocą nam przychodzą klucze obce musimy w takim razie w tabeli
equipment zawrzeć informację do kogo należy dany ekwipunek
czyli musimy dodać kolumnę która wskaże nam jednoznacznie na
konkretnego bohatera co nam jednoznacznie
identyfikuje bohatera oczywiście klucz główny czyli hero id
w takim razie dodajmy do tej tabeli kolumny
nazywającej się hero id to będzie nam przechowywała identyfikatory bohatera do
którego należy dany element ekwipunku ponieważ tabela już jest stworzona
to musimy użyć zapytania ddl który nam zmodyfikuje
istniejącą tabelę czyli jak zapewne pamiętasz alter table equipment
i chcemy dodać kolumnę o nazwie hero id ta
kolumna powinna mieć ten sam typ co kolumna w tabeli którą chcemy powiązać
w tym przypadku był to integer nowa
kolumna powinna się pojawić i mamy już możliwość powiązania
naszego ekwipunku z bohaterem ale bazy
danych nie tylko służą do przechowywania danych ale też jak
już wspominałem pełnią rolę strażnika tych danych i zapewniają
pewien poziom kontroli nad tymi danymi w tym wypadku baza
danych pozwala zachować coś to się nazywa integralnością
referencyjną referential integrity pomiędzy dwoma
tabelami to znaczy że dane jednej tabeli odnoszą
się jednoznacznie do danych do rekordu w drugiej tabeli takim mechanizmem
który pozwala nam tego pilnować są klucze obce
jest to rodzaj ograniczenia czyli constraint który jest nałożony na
jedną z tabel w tym wypadku tabelę jakby potomną czyli equipment
gdzie definiujemy że w kolumnie hero id mogą się
pojawić tylko wartości z kolumny hero id w tabeli heroes
to znaczy że elementy ekwipunku muszą odnosić się do istniejących bohaterów
których mamy zapisanych w powiązanej tabeli zanim dodamy jeszcze
klucz obcy dodajmy klucz główny do tej naszej nowej
tabeli też używając zapytania ddl alter
table i dodamy primary key do kolumny equipment id
tak mamy nasz klucz główny dodajmy klucz
obcy na kolumnie hero id która będzie
odnosiła się reference odnosiła się
do tabeli heroes i do kolumny hero id także
w tym momencie stworzymy takie ograniczenie jak
odświeżymy sobie tutaj pojawią się obydwa nasze
ograniczenia 1 to jest klucz główny a drugi klucz
obcy do kolumny hero id w tabeli heroes zobaczmy
teraz jak to działa próbując dodać jakiś ekwipunek i od
razu przypisując go do któregoś z bohaterów będziemy
wpisywali do tabeli equipment wartości takie id
1 nazwa szyszak typ uzbrojenie i
teraz jak będzie miał 5 punktów obrony nie będzie zadawał
obrażeń wręcz jakakolwiek wartość tutaj
była niestosowna a do do wyrażenia tego
że to pole powinno być puste używamy wartości null
tak samo przy durability nie jest ona tutaj istotna
nasz szyszak nie będzie się zużywał i mamy jeden tylko
szyszek i teraz spróbujmy przypisać do bohatera
jakiegoś na przykład do naszego pierwszego bohatera posiadającego
id równe 1 i
pięknie się to udało zobaczmy teraz jak to
wygląda w tabeli wszystko jest cacy a
teraz próbujemy przypisać nowy szyszak o takich samych charakterystykach
do postaci której nie ma w naszej bazie dostajemy
informacje o błędzie że naruszyliśmy ograniczenie
klucza obcego dlatego że bohatera o identyfikatorze 99
nie ma w tabeli heroes baza danych pilnuje nas żebyśmy
nie wpisali błędnych danych do naszej tabeli
Utworzenie tabeli ekwipunku · 7 min
-- Utworzenie nowej tabeli ekwipunku postaci
CREATE TABLE equipment (
equipment_id int,
equipment_name varchar,
equipment_type varchar,
armor int,
damage int,
durability int,
amount int
);
-- Utworzenie kolumny łączącej ekwipunek i konkretnego bohatera
ALTER TABLE equipment ADD COLUMN hero_id int;
-- Stworzenie ograniczenia referencyjnego (klucza obcego) na kolunie 'hero_id'
ALTER TABLE equipment ADD FOREIGN KEY (hero_id) REFERENCES heroes (hero_id);
-- Dopisanie pierwszego elementu ekwipunku wraz z przypisaniem do postaci z tabeli 'heroes'
INSERT INTO equipment VALUES (1, 'szyszak', 'uzbrojenie', 5, NULL, NULL, 1, 1);
-- Próba dopisania elementu ekwipunku do nieistniejącej postaci (wygeneruje bład)
INSERT INTO equipment VALUES (1, 'szyszak', 'uzbrojenie', 5, NULL, NULL, 1, 99);