środa, 25 marca 2026

SQL - Wprowadzenie - Składnia języka SQL

 Składnia języka SQL

W języku SQL występuje 5 głównych kategorii syntaktycznych:

  1. identyfikatory, czyli nazwy obiektów
  2. literały, czyli stałe
  3. operatory, czyli spójniki
  4. słowa kluczowe, czyli wyrazy interpretowane przez serwer bazodanowy w określony sposób
  5. komentarze, ignorowane przez serwery bazodanowe 
Instrukcja języka SQL zaczyna się poleceniem (słowem kluczowym) określającym operację, która ma być wykonana, następnie występują z reguły dookreślające tę operację klauzule.

Identyfikatory


Każdy z obiektów (baza, tabela, kolumna) musi mieć niepowtarzalną nazwę, czyli swój identyfikator. 

Identyfikatory muszą być zgodne ze zdefiniowanymi w standardzie języka SQL regułami, takimi jak:
  1. nie mogą składać się z więcej niż znaków
  2. mogą zawierać litery, cyfry oraz symbole: @, $, #. Pozostała symbole, w tym znak spacji, są niedozwolone
  3. mogą zaczynać się literą, ale nie cyfrą. Identyfikatory zaczynające się jednym z dwóch dozwolonych symboli mają specjalne znaczenie:
    • identyfikator rozpoczynający się symbolem @ oznacza zmienną
    • identyfikator rozpoczynający się symbolem # oznacza obiekt tymczasowy
  4. nie mogą być słowami kluczowymi języka SQL
Dodatkowo identyfikatory powinny być zgodne z poniższymi konwencjami nazewniczymi:
  1. Powinny być krótkie, ale jednoznacznie opisywać dany obiekt. Np. tabela zawierająca zamówienia z roku 2026 powinna nazywać się nie Z26, ale raczej Zamowienia2026.
  2. Wielkość liter powinna być zgodna z przyjętymi w ramach projektu regułami. Na przykład zasada mówiąca o tym, że każdy wyraz (z wyjątkiem pierwszego) powinien zaczynać się od wielkiej litery, np. danePersonalnePracownikow
  3. Przedrostek nazw widoków, funkcji użytkownika, procedur składowanych czy wyzwalaczy powinien wskazywać na typ obiektu, np. udf funkcja użytkownika (User Define Function), usp - procedura użytkownika (Trigger).

Literały


Wszystkie cyfry, ciągi znaków i daty, jeżeli nie są identyfikatorami, są traktowane jako stałe, czyli literały. W języku SQL ciągi znaków umieszcza się w apostrofach. 


Operatory


Operatory odgrywają rolę spójników. Operatory dzielą się na:
  1. arytmetyczne, do których należą: iloczyn *, iloraz /, modulo %, suma + i różnica -.
  2. znakowe, do których nalezą: konkatenacja (złączanie ciągów znaków) +, symbol wieloznaczny (zastępujący dowolny ciąg znaków) % i symbol wieloznaczny (zastępujący jeden znak) _.
  3. logiczne, do których należą: koniunkcja AND, alternatywa OR i negacja NOT.
  4. porównania, do których należą: = równy, < mniejszy niż, > większy nić, <= mniejszy lub równy, >= większy lub równy, i różny != (lub <>).
  5. charakterystyczne dla języka SQL. Takie jak m.in.: IN -przynależność do zbioru, BETWEEN...AND -przynależność do domkniętego przedziału, LIKE -zgodność ze wzorem, CASCADE -kaskadowe wykonanie operacji, APPLY -wywołanie funkcji tabelarycznej.

Słowa kluczowe


Słowa kluczowe to zastrzeżone, mające ściśle określone znaczenie ciągi znaków. Należą do nich:
  1. instrukcje języka SQL, takie jak SELECT czy CREATE.
  2. klauzule języka SQL, np. WHERE lub JOIN
  3. nazwy typów danych, np. INT lub CHAR
  4. nazwy funkcji systemowych, takie jak ISNULL() lub ABS()
  5. terminy zarezerwowane dla przyszłego użycia w danym serwerze bazodanowym.
Lista najczęściej spotykanych słów kluczowych jest dostępna w dodatkach.

Komentarze


W języku SQL występują dwa rodzaje komentarzy:
  1. Podwójny znak myślnika oznacza komentarz w wierszu. Cześć wiersza, która znajduje się za znakami --, jest traktowana jako komentarz.
  2. Znaki /* oznaczają początek bloku komentarza, a znaki */ jego koniec. Wiersze znajdujące się pomiędzy tymi znakami są traktowane jako komentarz.

środa, 4 marca 2026

SQL - Wprowadzenie - Normalizacja

 Normalizacja

Zgodnie z definicją zamieszczoną w Encyklopedii PWN, normalizacja może być rozumiana jako:

[...] działalność mająca na celu uzyskanie optymalnego w danych okolicznościach stopnia uporządkowania w określonym zakresie (przez ustalenie postanowień przeznaczonych do powszechnego i wielokrotnego stosowania, a dotyczących problemów istniejących lub możliwych do wystąpienia), w szczególności opracowywanie, publikowanie i wdrażanie norm;

Normalizacja to proces dostosowywania schematu bazy danych do wymogów modelu relacyjnego. Jego głównym celem jest wyeliminowanie anomalii wynikających z nadmiarowości danych, które mogłyby doprowadzić do utraty spójności danych. Podczas normalizacji zmienia się strukturę tabel tworzy nowe tabele i określa łączące je relacje, ale nie usuwa się ani nie modyfikuje przechowywanych w bazie informacji.

Normalizacja baz danych ma wiele zalet:

  • zmniejsza ryzyko niespójności danych;
  • upraszcza operacje dodawania, odczytu, aktualizacji i zapisu do bazy danych;
  • pozwala łatwiej pogrupować dane (np. poprzez wyodrębnienie nowych tabel);
  • zmniejsza ostateczny rozmiar bazy danych poprzez usunięcie duplikatów;
Normalizacja baz danych ma również istotne wady. Sztywne trzymanie się zasad normalizacji może powodować powstawanie dużej ilości relacji między tabelami, co sprawia, że proste zapytanie SELECT może zmienić się w skomplikowane zapytanie zawierające wiele klauzul JOIN oraz wykorzystujące wiele tabel pośrednich. Takie zapytanie może okazać się bardziej czasochłonne i wymagające dla silnika bazodanowego.


Pierwsza postać normalna

Głównym celem doprowadzenia do pierwszej postaci normalnej jest wyeliminowanie  nieatomowych atrybutów (tabela jest zgodna z 1PN, jeśli wszystkie jej kolumny przechowują atomowe, niepodzielne wartości).  Na przykład kolumnę Adres należy rozbić na kilka kolumn przechowujących kod, nazwę miasta i ulicę, a kolumnę Osoba - na dwie zawierające osobno Imię i Nazwisko. 

Za atomowe wartości należy przyjąć takie, które mogą być użyte w przyszłości do:

  • wyszukiwani, np. znalezienia osoby o podanym nazwisku
  • sortowania, np. przygotowania listy osób ułożonej alfabetycznie według imion
  • grupowania, np. policzenia osób mieszkających w poszczególnych miastach.
Ponadto, aby tabela mogła spełnić wymogi pierwszej postaci normalnej, musi posiadać kolumnę klucza podstawowego.


Druga postać normalna


Doprowadzenie tabeli do drugiej postaci normalnej polega na usunięciu z niej kolumn, które zależą funkcyjnie od części klucza podstawowego (tabela jest zgodna z 2PN, jeżeli znajduje się już w  pierwszej postaci normalnej i wartości wszystkich niekluczowych kolumn zależą od całego klucza podstawowego). W praktyce oznacza to, że jeśli klucz podstawowy tabeli jest prosty (założony na pojedynczej kolumnie), a nie złożony (założony na kilku kolumnach) i tabela jest w 1PN, to spełnia ona też automatycznie wymogi drugiej postaci normalnej. 


Trzecia postać normalna


Doprowadzenie tabeli to trzeciej postaci normalnej polega na znalezieniu i usunięciu przechodnich zależności pomiędzy atrybutami ( tabela jest zgodna z 3PN, jeżeli jest już w drugiej postaci normalnej i wartości jej kolumn nie są zależne od niekluczowych atrybutów). 

Doprowadzenie tabel do trzeciej postaci normalnej polega na:
  1.  Utworzenie tabel słownikowych, np. tabeli z nazwami miast. Takie tabele zawierają listy (słowniki) używanych w bazie terminów, dzięki czemu zamiast każdorazowo posługiwać się danym terminem, wystarczy użyć jego identyfikatora.
  2. Utworzeniu tabel łącznikowych, czyli takich, które umożliwiają budowanie relacji typu "wiele do wielu". Na przykład jeżeli założymy, że ta sama osoba może zapisać się jednocześnie na kilka kursów, a na ten sam kurs może zapisać się wiele osób, powinniśmy utworzyć nową tabelę KursOsoba i umieścić w niej klucze obce tabel Osoby i Kursy oraz atrybuty konieczne dla połączenia kursanta z jego zajęciami. 


Postać Boyce-a-Codda


Kolejną (czasami nazywaną postacią trzy i pół) postacią normalną jest postać Boyce-a-Codda (BCNF). Jej formalna definicja brzmi następująco: tabela jest zgodna z BCNF, jeżeli jest już w trzeciej postaci normalnej i dla każdej nietrywialnej zależności między podzbiorami jej atrybutów zbiór będący wyznacznikiem jest jej zbiorem identyfikującym. 


Czwarta postać normalna 


Omówione do tej pory postacie normalne definiowane były za pomocą pojęcia zależności funkcyjnej, czyli zależności, w której na podstawie wartości jednej kolumny (lub kolumn) można wnioskować wartość innych kolumn. Normalizując tabele zgodnie z tymi postaciami, minimalizowaliśmy liczbę powtarzających się wartości.

W definicji 4PN termin "zależność funkcyjna" jest zastąpiony terminem "zależność wielowartościowa"  (tabela jest zgodna z 4PN, jeżeli jest już w postaci Boyce'a-Codda i nie występują w niej zależności wielowartościowe). Wyobraźmy sobie tabelę Produkty, w której w kolumnie Nazwa zapisane są nazwy rożnych przedmiotów (np. krzesło, lornetka i tak dalej). W kolejnych kolumnach znajdują się wartości różnych atrybutów tych przedmiotów, np. w kolumnie Obicie kolor obicia, a w kolumnie Ogniskowa dane o ogniskowej obiektywu. Jako różne przedmioty mają rżzne cechy wiele komórek takiej tabeli będzie pustych. Powodem takiej anomalii jest występowanie  zależności wielowarstwowej, czyli takiej, w której na podstawie jednej kolumny  (nazwy przedmiotu) można wnioskować o wielu kolumnach. Aby doprowadzić  tabelę do postaci zgodnej z czwartą postacią normalną, należy ją rozbić na osobne tabele, których kolumny będą zawierały wyłącznie nazwy cech obiektów danego typu. 

środa, 25 lutego 2026

SQL - Wprowadzenie - Założenie relacyjnego modelu baz danych

 Założenia relacyjnego modelu baz danych

W 1970 roku doktor E.F. Codd opublikował pracę zatytułowaną "A Relational Model of Data for Large Shared Data Banks", w której proponował prezentowanie danych w postaci zestawu tabel. Zamiast wskaźników używanych do poruszania się między powiązanymi encjami, nadmiarowe dane mają być używane do łączenia rekordów w różnych tabelach. 

W modelu relacyjnym dane są prezentowane przez zbiory krotek (pól tabel), do których dostęp zapewniają operatory algebry relacji, takie jak selekcja, projekcja czy suma.

Każda tabela w relacyjnej bazie danych zawiera informacje unikatowo identyfikujące rekord w danej tabeli (tzw. klucz podstawowy) oraz informacje dodatkowe niezbędne do pełnego opisania encji. 

Każdy serwer bazy danych dostarcza mechanizm pozwalający na generowanie unikatowych zbiorów liczb używanych jako wartości klucza podstawowego. Dlatego nie trzeba zajmować się sprawdzaniem, jaki liczby zostały przypisane jako klucze podstawowe. 

E.F. Codd określił 12 podstawowych zasad, które musiał spełniać system, by mógł zarządzać relacyjnym modelem danych. 

Postulaty dotyczące struktury danych

Spełnienie postulatów dotyczących struktur danych pozwala w ten sam sposób, niezależnie od wykorzystywanego serwera bazodanowego, zarządzać przechowywanymi w bazie informacjami. Do tych postulatów należą:

  • Postulat informacyjny - Informacje są reprezentowane w postaci logicznych tabel. Oznacza to, że fizyczny sposób organizacji i przechowywania danych przez serwer bazodanowy nie może mieć wpływu na działanie programów klienckich.
  • Postulat dostępu - Każda informacja musi być dostępna za pomocą nazwy tabeli, kolumny i wartości klucza podstawowego. Innymi słowy, znajomość struktury tabeli i wartości identyfikatorów musi wystarczyć do odczytania dowolnej informacji z bazy.
  • Postulat fizycznej niezależności danych - Sposób przechowywania danych i wewnętrzne mechanizmy dostępu do nich przez serwer nie mogą mieć wpływu na aplikacje klienckie. Na przykład to, czy dane są przechowywane w jednym pliku, czy w wielu plikach, dla programów klienckich musi być całkowicie niewidoczne.
  • Postulat logicznej niezależności danych - Zmiany w strukturze bazy danych, np. zmiana definicji tabeli, o ile tylko nie powodują utraty informacji i są poprawne semantycznie, nie mogą mieć wpływu na aplikację kliencką.
  • Postulat niezależności dystrybucyjnej - Odwołania do danych za pomocą języka SQL muszą być niezależne od fizycznej lokalizacji danych. Innymi słowy, aplikacje klienckie powinny mieć taki sam dostęp do danych znajdujących się  na lokalnym dysku twardym jak do danych rozproszonych pomiędzy różne lokalizacje.
  • Postulat zabezpieczenia przed modyfikacjami przeprowadzanymi za pomocą języków proceduralnych - Jeśli serwer bazodanowy umożliwia bezpośrednie modyfikowanie poszczególnych rekordów za pomocą języków niższego poziomu, zmiany te nie mogą naruszać spójności danych, w szczególności nie mogą być sprzeczne z nałożonymi na tabele ograniczeniami.

Postulaty dotyczące przetwarzania danych

Relacyjny model danych został stworzony z myślą o wydajnym i łatwym modyfikowaniu zapisanych w bazach informacji. Te zmiany muszą być przeprowadzane z uwzględnieniem poniższych postulatów:
  • Postulat pełnego języka danych - Serwer baz danych musi implementować jeden język pozwalający definiować tabele, widoki i ograniczenia (więzy spójności), zarządzać dostępem użytkowników i transakcjami oraz odczytywać i modyfikować dane.
  • Postulat modyfikowania bazy danych przez widoki - Zmiany danych przeprowadzane poprzez widoki muszą być odzwierciedlane w odpowiednich tabelach, a bezpośrednie zmiany danych w tabelach muszą być automatycznie widoczne poprzez widoki.
  • Postulat modyfikowania danych na wysokim poziomie abstrakcji - Odczytanie, zmodyfikowanie, wstawienie lub usunięcie danych musi być możliwe za pomocą pojedynczej operacji. 

Postulaty dotyczące integralności danych

Przestrzeganie postulatów dotyczących integralności danych gwarantuje zachowanie logicznej spójności przechowywanych w bazie informacji:
  • Postulat wartości NULL - Serwer bazodanowy w spójny sposób przetwarza specjalną wartość NULL, jak brakującą informację. a nie jak zero czy pusty ciąg znaków ("").
  • Postulat słownika danych - Metadane (informacje o strukturze bazy danych) są przechowywane i udostępniane tak samo (w postaci tabel) jak zapisane w bazie informacje.
  • Postulat niezależności ograniczeń - Ograniczenia (więzy spójności) muszą być definiowane w tym samym języku SQL i przechowywane po stronie bazy danych, a więc nie jest obowiązkowe implementowanie ich po stronie aplikacji klienckiej. Serwer baz danych musi umożliwić zdefiniowanie przynajmniej dwóch typów ograniczeń:
    • ograniczenia klucza podstawowego, które gwarantują spójność w ramach tabel.
    • ograniczenia klucza obcego, które gwarantują spójność danych zapisanych w powiązanych tabelach.


środa, 18 lutego 2026

SQL - Wprowadzenie - Modele baz danych

Modele baz danych

Wyróżniamy trzy modele baz danych: relacyjny, obiektowy i jednorodny.

Model jednorodny

W tym modelu wszystkie dane są przechowywane w jednym arkuszu, tabeli lub pliku (stąd nazwa modelu).

Zaletą tego modelu jest łatwość i szybkość odczytywania interesujących nas danych. (w tym przypadku wystarczy tylko znaleźć rekord opisujący np. szukany zakup, żeby poznać wszystkie szczegóły danej operacji).

Wadą modelu jednorodnego jest duża liczba duplikatów (powtarzających się danych). Wielokrotne zapisywanie tych samych danych nie tylko zajmuje więcej miejsca da dysku i w pamięci, lecz także:

  • Utrudnia modyfikowanie danych. Gdyby na przykład firma zmieniła adres lub numer telefonu, musielibyśmy je zmieniać w wielu różnych rekordach. Gdybyśmy przeoczyli jeden z nich, dane byłyby niespójne, tj. odczytując dwa razy tę samą informację (adres lub telefon) moglibyśmy otrzymać różne wyniki.
  • Większe ryzyko wpisania błędnych danych. Podając po raz kolejny nazwę tej samej firmy, możemy przypadkowo dodać spację, zmienić wielkość liter czy w inny sposób pomylić się przy jej wpisywaniu. W rezultacie w bazie zostaną zapisane różne nazwy i gdybyśmy chcieli w przyszłości np. podsumować zakupy u poszczególnych dostawców, otrzymane wyniki byłyby nieprawdziwe.

Model relacyjny

W modelu relacyjnym dane są przechowywane w wielu odrębnych, ale powiązanych ze sobą tabelach. W jednej tabeli powinno się zapisywać dane o obiektach jednego typu, np. wyłącznie informacje o produktach czy klientach. Te łączące tabele powiązania nazywa się relacjami (stąd nazwa modelu).

Zaletą modelu relacyjnego jest zapobieganie tworzeniu duplikatów danych - dane np. o poszczególnych sprzedawcach i nazwach towarów są zapisane tylko raz. Nie tylko zmniejsza to ilość przechowywanych w bazie informacji, lecz także ułatwia ich modyfikowanie i wstawianie.

Wadą modelu relacyjnego jest jego skomplikowanie i wolne odczytywanie z niego danych. W dodatku dane odczytane z jednej tabeli należy właściwie połączyć z danymi odczytanymi z pozostałych tabel.

Żeby relacje były jednoznaczne, połączone z nimi tabele muszą mieć klucze podstawowe, a zapisane w nich identyfikatory muszą być powtórzone w każdej z połączonych z nią tabel. Kolumna, która zawiera identyfikator rekordu innej tabeli, nazywa się kluczem obcym.

Charakterystyczną cechą modelu relacyjnego jest prostota struktur danych (poszczególne tabele przechowują informacje o bardzo uproszczonych obiektach).

W praktyce relacyjne bazy danych składają się z wielu powiązanych ze sobą relacjami tabel. Informacje na temat tego,jak tabele są ze sobą powiązane, są prezentowane w postaci diagramów E/R (diagramów Encja/Relacja).

Relacyjną bazę danych można porównać do magazynu z meblami, w którym każda cześć mebla jest umieszczana w osobnym, przeznaczonym wyłącznie dla nich kontenerach (ich odpowiednikami w SQL są tabele). Umieszczając meble w takim magazynie, rozbieramy je na części i osobno układamy drzwi, półki i tak dalej. Taki sposób przechowywania jest bardzo wydajny, ale wyjmując mebel z magazynu, każdorazowo musimy złożyć go w jedną całość.

Model obiektowy

W opracowanym w latach 90. XX wieku modelu obiektowym informacje są przechowywane w bazie nie w postaci rekordów, ale całych obiektów. Tak zapisane dane są dostępne za pośrednictwem metod tych obiektów, np. obiekt Produkt może mieć metodę pozwalającą odczytać nazwę tego produktu i inną metodę zwracającą dane producenta tego produktu.  

Model obiektowy przypomina magazyn, w którym meble są ustawiane bez rozbierania na części. W rezultacie korzystanie z magazynu jest prostsze, za to liczba mebli, jaką można zmieścić na tej samej powierzchni, jest znacznie mniejsza.

Model obiektowy jest bardzo popularny wśród programistów takich języków programowania, jak C# czy Java, zakłada że wszystko jest obiektem o nieznanej nam wewnętrznej budowie. Owa wewnętrzna budowa z reguły nas jednak nie interesuje, za to musimy wiedzieć jak używać tych obiektów.

Zaletą modelu obiektowego jest zgodność z obowiązującym paradygmatem programowania. W tym przypadku programiści nie natrafiają na problemy takie jak:

  • niezgodność składni - składnia języka SQL jest zupełnie inna niż składnia takich języków, jak C, Java czy Visual Basic.
  • niezgodność typów - większość języków programowania, w przeciwieństwie do języka SQL, ma wbudowaną statyczną kontrolę typów, a w prawie żadnym z niech nie występuje podstawowy dla języka SQL typ "relacja".
  •  niezgodność użycia - w języku SQL programista określa wynik, ja chce otrzymać, a nie sposób w jaki ma on być osiągnięty. Ponadto SQL jest językiem interpretowanym, a nie kompilowanym.

środa, 11 lutego 2026

SQL - Dodatki - Słowa kluczowe języka SQL

Słowa kluczowe języka SQL

SQL jest językiem opartym na słowach kluczowych. (Słowo kluczowe jest specjalnym słowem używanym w trakcie wykonywania zapytania). Słowa te są zarezerwowane prze język SQL, więc nie należy ich zatem używać jako nazw baz danych, tabel, kolumn ani innych obiektów baz danych. 

W tym dodatku wymieniam listę najczęściej stosowanych słów kluczowych w najpopularniejszych systemach zarządzania bazami danych. 

Należy jednak pamiętać że słowa kluczowe są ściśle uzależnione od systemu zarządzania bazą danych i nie wszystkie wymienione słowa kluczowe muszą występować w każdym systemie. 

Aby zapewnić zgodność kodu z różnymi systemami zarządzania bazą danych i jego przenośność, warto unikać wszystkich zarezerwowanych słów kluczowych, nawet tych, które nie są zarezerwowane w używanym przez nas systemie. 


ABORT                                                                    

ABSOLUTE

ACTION

ACTIVW

ADD

AFTER

ALL

ALLOCATE

ALTER

ANALYZE

AND

ANY

ARE

AS

ASC

ASCENDING

ASSERTION

AT

AUTHORIZATION

AUTO

AUTO-INCREMENT

AVG


BACKUP

BEFORE

BEGIN

BETWEEN

BIGINT

BINARY

BIT

BOOLEAN

BOTH

BREAK

BROWSE

BY

BYTES


CACHE

CALL

CASCADE

CASCADED

CASE

CAST

CATALOG

CHANGE

CHAR

CHARACTER

CHECK

CHECKPOINT

CLOSE

CLUSTER

CLUSTERED

COALESCE

COLLATE

COLUMN

COLUMNS

COMMENT

COMMIT

COMMITED

COMPUTE

COMPUTED

CONDITIONAL

CONFIRM

CONNECT

CONNECTION

CONSTRAINT

CONSTRAINTS

CONTAINING

CONTAINS

CONTINUE

CONTROLROW

CONVERT

COPY

COUNT

CREATE

CROSS

CSTRING

CUBE

CURRENT

CURRENT_DATE

CURRENT_TIME

CURRENT_TIMESTAMP

CURRENT_USER


DATABASE

DATABASES

DATE

DATETIME

DAY

DEALLOCATE

DEBUG

DEC

DECIMAL

DECLARE

DEFAULT

DELETE

DENY

DESC

DESCENDING

DESCRIBE

DISCONNECT

DISK

DISTINCT

DISTRIBUTED

DIV

DO DOMAIN

DOUBLE

DROP

DUMMY

DUMP


ELSE

ELSEIF

ENCLOSED

END

ERROREXIT

ESCAPE

ESCAPED

EXCEPT

EXCEPTION

EXEC

EXECUTE

EXISTS

EXIT

EXPLAIN

EXTEND

EXTERNAL

EXTRACT


FALSE

FETCH

FIELD

FIELDS

FILE

FILTER

FLOAT

FLOPPY

FOR

FORCE

FOREIGN

FOUND

FREETEXT

FREETEZTTABLE

FROM

FULL

FUNCTION


GENERATOR

GET

GLOBAL

GO

GOTO

GRANT

GROUP


HAVING

HOUR


INDENTITY

IF

IN

INACTIVE

INDEX

INDICATOR

INFILE

INNER

INOUT

INPUT

INSERT

INT

INTEGER

INTERSECT

INTERVAL

INTO

IS

ISOLATION


JOIN


KEY

KILL


LANGUAGE

LAST

LEADING

LEFT

LENGTH

LEVEL

LIKE

LIMIT

LINES

LOAD

LOCAL

LOCK

LOGFILE

LONG

LOWER


MANUAL

MATCH

MAX

MERGE

MERGE

MESSAGE

MIN

MINUTE

MODULE

MONEY

MONTH

MOVE


NAMES

NATIONAL

NATURAL

NCHAR

NEW

NEXT

NO

NOCHECK

NONCLUSTERED

NONE

NOT

NULL

NULLIF

NUMERIC


OF

OFF

OFFSET

OFFSETS

ON

ONCE

ONLY

OPEN

OPTION

OR

ORDER

OUTER

OUTPUT

OVER

OVERFLOW

OVERLAPS


PAD

PAGE

PAGES

PARAMETER

PARTIAL

PASSWORD

PERCENT

PERM

PERMANENT

PIPE

PLAN

POSITION

PRECISION

PREPARE

PRIMERY

PRINT

PRIOR

PRIVILEGES

PROCEDURE

PROTECTED

PUBLIC

PURGE


READ

READTEXT

REAL

REFERANCES

REGEXP

RELATIVE

RENAME

REPEAT

REPLACE

RESERV

RESET

RESTORE

RESTRICT

RETAIN

RETURN

REVOKE

RIGHT

ROLLBACK

ROLLUP

ROWCOUNT

RULE


SAVE

SAVEPOINT

SCHEMA

SECOND

SECTION

SEGMENT

SELECT

SENSITIVE

SEPARATOR

SEQUENCE

SRT

SETUSER

SHADOW

SHARED

SHOW

SHUTDOWN

SINGULAR

SIZE

SMALLINT

SNAPSHOT

SOME

SORT

SPACE

SQL

SQLCODE

SQLERROR

STABILITY

STARTING

STARTS

STATISTICD

SUBSTRING

SUM

SUSPEND


TABLE

TABLES

TEMP

TEMPORARY

TEXT

TEXTSIZE

THEN

TIME

TIMESTAMP

TO

TOP

TRAN

TRANSACTION

TRANSLATE

TRIGGER

TRIM

TRUE

TRUNCATE

TYPE


UNCOMMITTED

UNION

UNIQUE

UNTIL

UPDATE

UPPER

USAGE

USE

USER

USING


VALUE

VALUES

VARCHAR

VARIABLE

VARYING

VIEW

VOLUME


WAIT

WHEN

WHERE

WHILE

WITH

WORK

WRITE


XOR


YEAR


ZONE

SQL - Wprowadzenie - Składnia języka SQL

  Składnia języka SQL W języku SQL występuje 5 głównych kategorii syntaktycznych: identyfikatory, czyli nazwy obiektów literały, czyli stałe...