Bazy Danych

(informatyczna definicja)

• Jest to zbiór tabel spełniaj

ą

cych

okre

ś

lone kryteria

• Zbiór powi

ą

za

ń

pomi

ę

dzy tabelami

Cechy „fizyczne” kolumn w

tabelach

• Ka

ż

da tabela ma unikaln

ą

nazw

ę

w bazie

danych i składa si

ę

z wierszy i kolumn

• Ka

ż

da kolumna musi mie

ć

swoj

ą

unikaln

ą

nazw

ę

• Nieznana jest kolejno

ść

kolumn w obr

ę

bie tabeli

-> wniosek:

– do kolumny odwołujemy si

ę

poprzez jej nazw

ę

a nie

pozycj

ę

w tabeli

• Ka

ż

da kolumna ma

ś

ci

ś

le okre

ś

lon

ą

dziedzin

ę

(typ danych)

Cechy „fizyczne” kolumn

(najcz

ę

stsze typy danych)

•

int (typ całkowity – wystarczaj

ą

cy nawet do du

ż

ych miar)

•

char(#) – napis zajmuj

ą

cy dokładnie # znaków miejsca

•

varchar(#) napisz, który mo

ż

e zajmowa

ć

od 1 do # znaków miejsca

(teoretycznie zajmuje fizycznej pamieci dokładnie tyle ile liter
wpiszemy -> jest to nieprawda, ka

ż

dy taki element ma najczesciej

narzut od 10 do 20 znaków)

•

money -> pieni

ą

dze

•

bit -> 0 lub 1 (niektórzy nazywaj

ą

go logicznym 0 – falsz, 1 –

prawda)

•

Datetime -> data z czasem (czasami wyst

ę

puj

ą

typy date i time

osobno). To jest typ binarny (kilka bajtów) na których jest
„zakodowana” dokładna data z czasem z dokładno

ś

ci

ą

do

milisekund

Cechy „fizyczne” kolumn

(typ datetime)

•

Wewn

ę

trzny sposób przechowywania daty nie ma nic wspólnego z

jej formatem

•

Tabela/Baza danych nie dopu

ś

ci do wpisania wadliwej daty (np.

dnia 32, miesi

ą

ca nr 13 itp., itd.)

•

Zazwyczaj daty do tabeli wstawia si

ę

u

ż

ywaj

ą

c tekstowego formatu.

Baza danych dokona „ukrytej” konwersji (tłumaczenia daty).

•

Domy

ś

lnym formatem tekstowym daty na SQL-u jest MM.DD.YYYY.

Ale poniewa

ż

ustawienie to mo

ż

na zmieni

ć

dla całej bazy lepiej jest

u

ż

ywa

ć

funkcji zamieniaj

ą

cej napis na dat

ę

, w której mo

ż

emy poda

ć

rodzaj u

ż

ytego formatu. Np.. convert(datetime, ‘20061025’, 112)

oznacza w MS-SQL zamie

ń

na dat

ę

napis w formacie YYYYMMDD

(jest to format nr 112)

•

Sposób wy

ś

wietlania daty przez program pobieraj

ą

cy dane z tabeli

nie zale

ż

y od bazy danych. Zale

ż

y od systemu operacyjnego,

oprogramowania, ustawie

ń

tego oprogramowania

Cechy „fizyczne” kolumn

wła

ś

ciwo

ść

NULL i NOT NULL

NULL – oznacza, ze tej danej nie musimy podawa

ć

NOT NULL – ze wpisuj

ą

c wiersz tej informacji pomin

ąć

Imi

ę

varchar(40)

NOT NULL

Nazwisko

varchar(40)

NOT NULL

Data_ur

datetime

NULL

PESEL

char(11)

NULL

Maciej

Stodolski

10.03.2000 000310xxx

Mi

ś

Testowy1

10.10.1970 NULL

Mi

ś

Testowy2

NULL

NULL

Cechy „fizyczne” wierszy w tabeli

• Nieznana jest kolejno

ść

wierszy w tabeli (nie

mo

ż

na systemu poprosi

ć

o np. 5-ty wiersz tabeli

• Dlatego wiersze mo

ż

emy rozpoznawa

ć

tylko

poprzez ich zawarto

ść

.

– Np. poka

ż

wiersze z tabeli osoby w których w

kolumnie imi

ę

jest napis ‘Maciej’ a w kolumnie

nazwisko jest napis ‘Stodolski’

• Wszystkie bazy wymagaj

ą

aby istniał podzbiór

kolumn w tabeli, którego zawarto

ść

nigdy si

ę

nie

powtórzy. Taki podzbiór nazywamy Kluczem
głównym tabeli

Cechy tabel:

Klucz główny tabeli

• Klucz główny mo

ż

e si

ę

składa

ć

z dowolnej liczby

kolumn. Oznacza si

ę

go jako PK (od Primary Key)

• Kolumny wchodz

ą

ce w skład klucza musz

ą

mie

ć

atrybut

NOT NULL

• Je

ż

eli w przykładzie na slajdzie nr 5 zdefiniujemy PK

jako (imi

ę

, nazwisko) to spowoduje,

ż

e:

– Wynik zapytania „pokaz wiersz z imieniem ‘Maciej’ i nazwiskiem

‘Stodolski’” b

ę

dzie albo pusty (brak takiej osoby w tabeli albo

b

ę

dzie TYLKO jeden taki wiersz)

– Baza nie dopu

ś

ci do powstania w tabeli dwu wierszy o tej samej

warto

ś

ci klucza głównego

Podsumowanie

Cechy fizyczne tabeli

• Nazwa tabeli musi by

ć

unikalna w bazie danych

(tabela rozpoznawana jest przez nazw

ę

)

• Kolumny w ramach jednej tabeli musz

ą

mie

ć

unikalne nazwy. Dost

ę

p do kolumn jest poprzez

ich nazwy.

• Ka

ż

da kolumna ma jeden okre

ś

lony typ danych i

ustawiony atrybut NULL lub NOT NULL

• Ka

ż

da tabela musi/powinna mie

ć

zdefiniowany

klucz główny

Cechy logiczne tabeli

• Dane w tabeli powinny dotyczy

ć

tylko

jednej logicznej cało

ś

ci

– Je

ż

eli dotycz

ą

dwóch tabel to nale

ż

y tak

ą

tabel

ę

podzieli

ć

na dwie i pokaza

ć

powi

ą

zanie

pomi

ę

dzy nimi (klucz obcy Foreign Key)

– Czasami logiczna cało

ść

wynika z potrzeby

zabronienia wpisywania pewnych pól ->
konieczno

ś

ci wybierania danych z tak zwanej

tabeli słownikowej

Przykładowa tabela

Nazwa kolumny

Typ Danych

NULL ?

DANE

Imi

ę

varchar(40)

NOT NULL

Maciej

Mis

Maciej

Nazwisko

varchar(40)

NOT NULL

Stodolski

Testowy

Stodolski

kod_poczt

char(6)

NOT NULL

05-075

00-000

05-075

ulica

varchar(40)

NOT NULL

Kwiatowa 111

Pod mostem

Kwiatowa 111

Miasto

varchar(40)

NOT NULL

Warszawa-WESOŁA

Gda

ń

sk

Warszawa-WESOŁA

data_ur

datetime

NULL

NULL

01.01.1970

NULL

nazwa_firmy

varchar(100)

NOT NULL

Politechnika-Warszawska

Politechnika-Warszawska

Hewlett-Packard

kod_poczt

char(6)

NOT NULL

00-000

00-000

00-000

ulica_firmy

varchar(40)

NOT NULL

Pl. Politechniki 1

Pl. Politechniki 1

Szturmowa 2a

Miasto

varchar(40)

NOT NULL

Warszawa

Warszawa

Warszawa

Stanowisko

varchar(40)

NOT NULL

adjunkt

adjunkt

analityk

Pensja

money

NOT NULL

4000

3900

11000

Od

datetime

NOT NULL

01.01.1995

01.01.2000

01.01.2001

Do

datetime

NULL

NULL

NULL

NULL

Podział tabeli

na logiczne cz

ęś

ci

Osoby

PK

Id_osoby

Imię
Nazwisko
kod_poczt
ulica
miasto
data_ur

Firmy

PK

Nazwa_skr

Nazwa
kod_poczt
ulica
miasto

Etaty

PK

id_etatu

FK1

ID_firmy

FK2

Id_osoby
stanowisko
pensja
od
do

Wybór PK dla tabeli ETATY

• (Id_osoby, Id_firmy) po takim wyborze nie

b

ę

dzie mo

ż

liwe wpisanie osoby pracuj

ą

cej na

dwóch etatach w jednej firmie albo nie b

ę

dzie

mo

ż

liwe przechowywanie informacji

archiwalnych (kto

ś

kiedy

ś

pracował i teraz

znowu pracuje na innym etacie)

• (id_osoby, id_firmy, od) teoretycznie powinno

wystarczy

ć

, ale je

ż

eli w przyszłosci planujemy

powi

ą

za

ć

etaty z innymi tabelami to mo

ż

e lepiej

b

ę

dzie wprowadzi

ć

unikalny identyfikator,

nadawany przez system

Dalszy podział wynikaj

ą

cy

z potrzeb klienta

• Klient chce przy ka

ż

dym mie

ś

cie mie

ć

informacje w jakim województwie jest to
miasto

• Najlepiej jakby nazwa miasta i

województwo było wybierane ze słownika
(z osobnej tabeli) a nie wpisywane

• Z informacji tych wynika konieczno

ść

zast

ą

pienia pola miasto odwołaniem do

kolejnej tabeli

Ostateczny schemat bazy

Przykładowe dane

Województwa

Miasta

nazwa

kod_woj

Nazwa

id_miasta

kod_woj

Mazowieckie

Maz

Warszawa-Wesoła

1 Maz

Pomorskie Pom

Warszawa

2 Maz

Gda

ń

sk

3 Pom

Osoby

Id_osoby Imie

Nazwisko

ulica

kod_poczt id_miasta data_ur

1 Maciej

Stodolski

Kwiatowa 111

05-075

1 NULL

2 Mis

Testowy

Pod Mostem

00-000

3 01.01.1970

Firmy

Nazwa_skrkod_poczt ulica

nazwa

id_miasta

PW

00-000

Pl.Pol.1

Politechnika Warszawska

2

HP

02-773

Szturmowa 2a Hewlett Packard Polska

2

Etaty

id_osoby id_firmy

stanowisko

pensja

od

do

1 PW

adjunkt

4000 01.01.1995 NULL

2 PW

adjunkt

3900 01.01.2000 NULL

1 HP

analityk

11000 01.01.2001 NULL

Architektura systemów baz danych

• Archaiczne rozwi

ą

zanie: na ka

ż

dej stacji

roboczej jest program zawieraj

ą

cy tzw. „motor”

bazy danych (czyli programy pozwalaj

ą

ce

przeszukiwa

ć

i modyfikowa

ć

zawarto

ść

tabel).

Tabele s

ą

umieszczone w jednym lub wielu

plikach na wspólnym dysku (Access, dBase, …)

• Architektura Klient-Serwer w której wszystkie

operacje na tabelach wykonuje jeden program
(nazwijmy go serwerem). Tylko on ma dost

ę

p do

tabel. Programy ze stacji wysyłaj

ą

do tego

programu polecenia a on je odpowiednio
„kolejkuje” i wykonuje

Dlaczego w bazie powinny by

ć

powi

ą

zania mi

ę

dzy tabelami

• Bł

ę

dnym podej

ś

ciem jest traktowanie bazy

danych jako zbioru tabel nad którymi „czuwa”
tylko aplikacja

– Administratorzy i osoby uprawnione maj

ą

dost

ę

p

bezpo

ś

redni do bazy danych

– Istnieje wiele uznanych systemów raportuj

ą

cych

opieraj

ą

cych si

ę

na informacjach z bazy danych

(mi

ę

dzy innymi pobieraj

ą

one powi

ą

zania pom.

tabelami)

– Je

ż

eli wyst

ą

pi bł

ą

d po stronie aplikacji to b

ę

dzie miał

dla bazy fatalne skutki a tak dobrze zaprojektowana
baza b

ę

dzie odporna na takie bł

ę

dy

Cechy nowoczesnej aplikacja

bazodanowej

•

Zabezpieczenia w postaci kluczy obcych (przed utrat

ą

integralno

ś

ci

danych)

•

Zabezpieczenia pod postaci

ą

sprawdzania poprawno

ś

ci danych na

poziomie bazy (oprócz weryfikacji po stronie aplikacji)

•

Wi

ę

kszo

ść

kodu do manipulacji danymi jest wykonana po stronie

bazy poprzez procedury bazodanowe w tym triggery.

•

Aplikacja wywołuje procedury bazodanowe a nie przesyła zapytania
(mniej bezpieczne i mniej efektywne rozwi

ą

zanie)

•

Wszystkie zło

ż

one operacje s

ą

wykonywane transakcyjnie.

•

Wi

ę

kszo

ść

tabel słownikowych ma mo

ż

liwo

ść

ukrywania informacji,

które przestały obowi

ą

zywa

ć

(np. zakres dat obowi

ą

zywania lub

cho

ć

by jedna data „do_kiedy_obowi

ą

zuje”)

•

Operacje na danych słownikowych, zmiany, dezaktualizacje, tych
danych, s

ą

automatycznie rejestrowane przez baz

ę

(wykorzystanie

techniki triggerów)

Krótka teoria j

ę

zyków

do manipulacji danymi

• Baza danych spełnia podane wcze

ś

niej

• Wynikiem ka

ż

dej operacji jest nowa tabela

• J

ę

zyk powinien udost

ę

pnia

ć

nast

ę

puj

ą

ce

operacje:

– WW (wyboru wierszy) T -> WW -> nT

– WK (wybór kolumn) T -> WW -> nT

– R (iloczyn kartezja

ń

ski, relacja pomi

ę

dzy tabelami)

• T1 x T2 -> nT

• inny zapis to T1,T2 -> nT

Na czym polega operacja relacji

pomi

ę

dzy tabelami

• Operacja relacji ł

ą

czy ka

ż

dy wiersz z tabeli

pierwszej ze wszystkimi wierszami z tabeli
drugiej

• Wynikowa tabela zawiera wszelkie mo

ż

liwe

kombinacje poł

ą

cze

ń

pomi

ę

dzy wierszami z

obydwu tabel

• WNIOSEK w j

ę

zyku manipulacji danymi, wybór

danych z dwu tabel powoduje otrzymanie
wynikowej tabeli zawieraj

ą

cej wszelki mo

ż

liwe

poł

ą

czenia wierszy z obydwu tabel

Przykład operacji relacji

na tabelach miasta, województwa

Kod_woj

Nazwa

Maz

Mazowieckie

Pom

Pomorskie

Kod
Woj

Id Nazwa

Maz

1

W-wa-Wesoła

Maz

2

Warszawa

Pom

3

Gda

ń

sk

Kod_
woj

Nazwa

KodWoj

Id

Nazwa1

Maz

Mazowieckie

Maz

1

W-wa-Wesoła

Maz

Mazowieckie

Maz

2

Warszawa

Maz

Mazowieckie

Pom

3

Gda

ń

sk

Pom

Pomorskie

Maz

1

W-wa-Wesoła

Pom

Pomorskie

Maz

2

Warszawa

Pom

Pomorskie

Pom

3

Gda

ń

sk

Operacja Relacji

Wnioski

• Wybór danych z dwu tabel daje „nieoczekiwany” wynik

• Wybór taki ma sens tylko jak dodamy warunek ł

ą

cz

ą

cy

tabele (czyli operacj

ę

Wyboru Wierszy)

– Poni

ż

ej u

ż

yto warunek: miasta.kod_woj = województwa.kod_woj

Kod_woj

Nazwa

KodWoj

ID

Nazwa1

Maz

Mazowieckie

Maz

1

W-wa-Wesoła

Maz

Mazowieckie

Maz

2

Warszawa

Pom

Pomorskie

Pom

3

Gda

ń

sk

J

ę

zyk SQL

• Słu

ż

y do wydawania polece

ń

SQL-serwerowi

• Wysyłamy do SQL serwera polecenie a w

odpowiedzi otrzymujemy:

– Wirtualn

ą

tabel

ę

wynikow

ą

(je

ż

eli u

ż

yli

ś

my polecenia

wyboru danych SELECT bez podania adresu tabeli
docelowej). W bazie danych nie ma

ś

ladu po

uzyskanym wyniku

– Lub komunikat o poprawno

ś

ci zako

ń

czenia operacji

(gdy operacja inna ni

ż

wy

ż

ej opisana)

– Komunikat bł

ę

du w przypadku złego sformułowania

polecenia lub niemo

ż

no

ś

ci jego wykonania

Polecenie tworzenia tabel

• CREATE nazwa_tabeli (definicja_kolumny

[,definicja_kolejnej_kolumny])

• W MS-SQL-u klucz gowny jest podawany jako

rodzaj ograniczenia zadanego na kolumn

ę

tabeli

create table woj

(

kod_woj

char(3)

not null

constraint pk_woj primary key

,

nazwa

varchar(30)

not null

)

GO

MS-SQL – tworzenie tabeli,

definiowanie kluczy obcych

• Klucz obcy, w MS-SQL-u, tak jak klucz główny

zadawany jest w postaci ograniczenia na
kolumn

ę

w tabeli

• IDENTITY to wła

ś

ciwo

ść

autonumeracji kolumny

create table miasta

(

id_miasta int

not null identity

constraint pk_miasta primary key

,

kod_woj

char(3)

not null

constraint fk_miasta__woj foreign key

references woj(kod_woj)

,

nazwa

varchar(30)

not null

)

Tworzenie tabeli, kolumny

„wirtualne” i warto

ś

ci domy

ś

lne

create table osoby

(

id_osoby

int

not null identity

constraint pk_osoby primary key

,

id_miasta

int

not null

constraint fk_osoby__miasta foreign key

references miasta(id_miasta)

,

imi

ę

varchar(20)

not null

,

nazwisko

varchar(30)

not null

,

imi

ę

_i_nazwisko as

convert(char(24),left(imi

ę

,1)+'. ' + nazwisko)

,

data_ur

datetime

null

,

wiek

as datediff(yy,data_ur,getdate())

,

data_wpisania datetime

not null

DEFAULT (GETDATE())

,

stacja

char(30)

not null

DEFAULT (LEFT(HOST_NAME(),30)

)

Polecenie wyboru danych

SELECT

SELECT WK

FROM lista_tabel (czyli Realacja)

[ WHERE WW ]

Przykład:

SELECT o.Imi

ę

_i_nazwisko

,

o.id_osoby

AS ID

FROM osoby o

/* jest to przykład operacji wyboru kolumn */

Praca z „prostym” klientem SQL-

owym

• Przykładem takiego programu jest

QueryAnalizer (program nosi nazw

ę

isqlw.exe)

współpracuj

ą

cy z MS-SQL-em 2000

• Jest to zwykły edytor tekstowy

• Mo

ż

emy wpisa

ć

wiele polece

ń

, zaznaczy

ć

to,

które chcemy wykona

ć

i kaza

ć

je uruchomi

ć

– Menu Query, opcja Execute

– Lub u

ż

y

ć

jednego ze skrótów F5, Ctrl+E

Praca z SQL-Serwerem

• Nawi

ą

zanie poł

ą

czenia z SQL-Serwerem

po uruchomieniu programu QueryAnalizer

Praca z QueryAnalizerem

SELECT – Wybór Wierszy

SELECT o.*

FROM osoby o

WHERE

(o.nazwisko LIKE ’S%’)

/* wybiera osoby o nazwisku zaczynaj

ą

cym si

ę

na S */

• Kolumna LIKE ‘Wzorzec’. We wzorcu mo

ż

na u

ż

ywa

ć

:

– % oznacza dowoln

ą

ilo

ść

dowolnych znaków

– _ oznacza dokładnie jeden dowolny znak

SELECT – wybór wierszy

• Kolumna Operator Warto

ść

– Operator: =, !=, >, <, >=, <=

/* osoby o imieniu Maciej */

SELECT o.*

FROM osoby o

WHERE

(o.Imi

ę

= ‘Maciej’)

• NOT (Kolumna Operator Warto

ść

)

/* osoby o imieniu innym ni

ż

Maciej */

SELECT o.*

FROM osoby o

WHERE

NOT (o.Imi

ę

= ‘Maciej’)

Operacja Relacji

• Wybór danych z tabel miasta i woj.

select

w.kod_woj

, w.nazwa

AS [Województwo]

, m.kod_woj

AS [Kod_woj z Miasta]

, m.nazwa

AS [Miasto]

, m.id_miasta

from miasta m, woj w

Operacja Relacji (miasta x woj.)

Operacja relacji z poł

ą

czeniem

pomi

ę

dzy tabelami

SELECT

w.kod_woj

, w.nazwa AS województwo

, m.nazwa AS miasto

, m.id_miasta

FROM woj w, miasta m

WHERE

(w.kod_woj = m.kod_woj)

Wybór z wielu tabel z warunkiem

ł

ą

cz

ą

cym i dodatkowym

SELECT

w.kod_woj

, w.nazwa AS województwo

, m.nazwa AS miasto

, m.id_miasta

FROM woj w, miasta m

WHERE

(w.kod_woj = m.kod_woj)

AND

(m.nazwa LIKE ‘W%’)

Wady standardowych zapyta

ń

• Najpowa

ż

niejsz

ą

wad

ą

jest brak

rozró

ż

nienia warunków ł

ą

cz

ą

cych tabele,

niezb

ę

dnych do prawidłowego

funkcjonowania zapytania od warunków
dodatkowych

• Programi

ś

ci warunki ł

ą

cz

ą

ce staraj

ą

si

ę

umieszcza

ć

jako pierwsze a po

odpowiednim komentarzu warunki łacz

ą

ce

Nowy standard ANSI zapyta

ń

SELCT lista_kolumn

FROM tabela
[ join tabela2 ON (warunek łacz

ą

cy tabele) ]

WHERE dodatkowe_warunki

ORDER BY lista_kolumn

• Podstawowa zaleta to oddzielenie warunków

ł

ą

cz

ą

cych tabele od dodatkowych warunków

• W wi

ę

kszo

ś

ci SQL Serwerów zamiast słowa join

trzeba napisa

ć

inner join

Nowy standard ANSI

Przykład

select

w.kod_woj

, w.nazwa

AS [Województwo]

, m.kod_woj

AS [Kod_woj z Miasta]

, m.nazwa

AS [Miasto]

, m.id_miasta

from miasta m

join woj w ON (m.kod_woj = w.kod_woj)

WHERE

(m.nazwa LIKE 'W%')

/* to samo zapytanie, które było w starszym

standardzie */

Porady tworzenia zapyta

ń

w nowym standardzie

• Do ju

ż

wymienionych tabel w klauzuli

FROM dodajemy takie tabele, które ł

ą

cz

ą

si

ę

z ju

ż

wymienionymi tabelami

SELECT *

FROM woj w join osoby ON (…)

• W powy

ż

szym przykładzie nie mo

ż

emy

poda

ć

warunku ł

ą

cz

ą

cego tabele, gdy

ż

takowy nie istnieje.

Porady tworzenia zapyta

ń

w nowym standardzie c.d.

SELECT

w.kod_woj

, w.nazwa AS Województwo

, m.nazwa AS miasto

, o.imie_i_nazwisko

, o.id_osoby

FROM osoby o

join miasta m ON (m.id_miasta=o.id_miasta)

join woj w ON (w.kod_woj = m.kod_woj)

ORDER BY w.nazwa,m.nazwa,o.imi

ę

_i_nazwisko

Porady tworzenia zapyta

ń

w nowym standardzie

SELECT

o.imie_i_nazwisko

,

mo.nazwa

AS miasto_osoby

,

e.pensja

,

f.nazwa

AS firma

,

mf.nazwa

AS miasto_firmy

FROM osoby o

join miasta mo ON (mo.id_miasta=o.id_miasta)

join etaty e ON (e.id_osoby = o.id_osoby)

join firmy f ON (f.nazwa_skr = e.id_firmy)

join miasta mf ON (mf.id_miasta = f.id_miasta)

WHERE

(e.do IS NULL)

ORDER BY 1, 4, 3 DESC

/* pokaz aktualne etaty, miasto gdzie mieszka osoba i miasta w

którym znajduje si

ę

firma */

Zapytania z funkcjami agreguj

ą

cym

• Funkcje agreguj

ą

ce to:

– MAX(kolumna) -> maksymalna warto

ść

– MIN(kolumna) -> minimalna

– AVG(kolumna) ->

ś

rednia

– COUNT(*) -> liczba rekordów pobranych

przez zapytanie

– COUNT( DISTINCT kolumna) -> liczba

unikalnych wyst

ą

pie

ń

danej kolumny

Zapytania z funkcjami

agreguj

ą

cymi

• W zapytaniu mo

ż

emy u

ż

y

ć

dowolnej ilo

ś

ci

funkcji agreguj

ą

cych

• Nie mo

ż

emy wybiera

ć

razem z tymi

funkcjami innych danych

• W wyniku dostajemy ZAWSZE tabel

ę

zawieraj

ą

c

ą

jeden wiersz

Zapytania z funkcjami

agreguj

ą

cymi - przykład

SELECT

COUNT(*) AS [Ile akt.etatów jest na PW]

, COUNT(DISTINCT e.id_osoby)

AS [Ile osób jest na tych etatach]

, MAX(e.pensja) AS [Jaka jest maks.pensja]

, AVG(e.pensja) AS [Jaka jest

ś

r.pensja]

FROM etaty e

WHERE

(e.do IS NULL) /* aktualne */

AND

(e.id_firmy = ’PW’) /* tylko PW*/

Funkcje agreguj

ą

ce

• Chc

ą

c znale

źć

w bazie aktualnie

maksymaln

ą

pensj

ę

i zobaczy

ć

kto

aktualnie tyle zarabia musimy wykona

ć

dwa zapytania

• Nie da si

ę

tego zrobi

ć

w jednym zapytaniu

SELECT MAX(e.pensja), e.id_osoby

FROM etaty e

NIE ZADZIAŁA – i słusznie

Funkcja agreguj

ą

ce c.d.

• Najpierw wybieramy do tabeli tymczasowej

maksymaln

ą

pensj

ę

:

SELECT MAX(e.pensja) AS mp INTO #t

FROM etaty e

WHERE

(e.do IS NULL)

• Teraz pokazujemy kto tyle ma:

SELECT e.pensja, o.imi

ę

_inazwisko,e.id_firmy

FROM etaty e join #t ON (e.pensja=#t.mp)

join osoby o ON (o.id_osoby=e.id_osoby)

WHERE

(e.do IS NULL)