Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

Podstawy SQL dla FirebirdSQL Marek Dziedziczak, DB, DB1 Ericpol Telecom Sp. z o.o. Tel.: +48 605 506 395.

Podobne prezentacje


Prezentacja na temat: "Podstawy SQL dla FirebirdSQL Marek Dziedziczak, DB, DB1 Ericpol Telecom Sp. z o.o. Tel.: +48 605 506 395."— Zapis prezentacji:

1 Podstawy SQL dla FirebirdSQL Marek Dziedziczak, DB, DB1 Ericpol Telecom Sp. z o.o. Tel.:

2 ericpol.com RRRR-MM-DD 2 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Agenda Co to jest Relacyjna Baza Danych Projektowanie relacyjnych baz danych Składniki relacyjnych baz danych Podstawy SQLa

3 ericpol.com RRRR-MM-DD 3 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Rozdział I: Co to jest Relacyjna Baza Danych

4 ericpol.com RRRR-MM-DD 4 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Baza danych Książka telefoniczna Kod kreskowy Metka DNS Karta SIM System plików Zbiór danych zapisanych w ściśle określony sposób w strukturach odpowiadających założonemu modelowi danych. (pl.wikipedia.org)

5 ericpol.com RRRR-MM-DD 5 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL System zarządzania bazą danych Możliwość zapisywania, odczytywania i aktualizowania danych Sprawny dostęp do danych Zapewnienie spójności danych Możliwość dostępu wielu użytkownikom na raz Bezpieczeństwo danych Zarządzanie prawami dostępu do danych System zarządzania bazą danych, SZBD (ang. Database Management System, DBMS) nazywany też serwerem baz danych lub systemem baz danych. To oprogramowanie bądź system informatyczny służący do zarządzania komputerowymi bazami danych. (pl.wikipedia.org)

6 ericpol.com RRRR-MM-DD 6 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Relacyjna baza danych W bazach relacyjnych wiele tablic danych może współpracować ze sobą (są między sobą powiązane). (pl.wikipedia.org) Informacje dzielone są na powiązane ze sobą dane umieszczane w różnych tabelach i kolumnach. Wszystkie wartości danych oparte są na prostych typach danych. Wszystkie dane w bazie relacyjnej przedstawiane są w formie dwuwymiarowych tabel. Każda tabela zawiera zero lub więcej wierszy i jedną lub więcej kolumn. Na każdy wiersz składają się jednakowo ułożone kolumny wypełnione wartościami, które z kolei w każdym wierszu mogą być inne. Wszystkie operacje wykonywane są w oparciu o algebrę relacji. Wynikiem zapytań zawsze jest zbiór danych.

7 ericpol.com RRRR-MM-DD 7 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Relacyjna baza danych Informacje o pracowniku: Imię, Nazwisko, PESEL, kontak e- mail Pracownik może mieć adres ale nie musi Każdy pracownik może mieć kilka adresów z różnymi atrybutami (służbowy, prywatny, uczelniany)

8 ericpol.com RRRR-MM-DD 8 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Relacyjna baza danych ImięNazwiskoPESEL JanSmela AnnaSmela PawełSzczerkowski WojciechMalkiewicz WojciechDubiel PESELadreskategoria

9 ericpol.com RRRR-MM-DD 9 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Relacyjna baza danych ImięNazwiskoPESEL JanSmela AnnaSmela PawełSzczerkowski WojciechMalkiewicz WojciechDubiel PESELadreskategoria 1

10 ericpol.com RRRR-MM-DD 10 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Relacyjna baza danych 1 PRACOWNICY Imię Nazwisko PESEL E PESEL adres kategoria

11 ericpol.com RRRR-MM-DD 11 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Schemat bazy danych

12 ericpol.com RRRR-MM-DD 12 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Rozdział II: Projektowanie relacyjnych baz danych

13 ericpol.com RRRR-MM-DD 13 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - normalizacja Bezpieczeństwo danych Unikanie niespójności (problemy anomalii): nadmiarowość, anomalia modyfikacji i usunięć Normalizacja bazy danych jest to proces mający na celu eliminację powtarzających się danych w relacyjnej bazie danych. Główna idea polega na trzymaniu danych w jednym miejscu, a w razie potrzeby linkowania do nich. (pl.wikipedia.org) Nadmiarowość – redundancja - doprowadza do błędów lub wielu niepotrzebnych problemów z utrzymaniem bazy danych

14 ericpol.com RRRR-MM-DD 14 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - 1NF 1NF -Atomowość Jak przygotować strukturę do przechowywania danych tele-adresowych? ul.Targowa 9A Łódź tel: fax:

15 ericpol.com RRRR-MM-DD 15 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - 1NF dane ul.Targowa 9A; Łódź; ; ; Wszystkie dane w jednym stringu porozdzielane znakiem ; Adres; Telefon; Fax; Łatwe dopisywanie zwłaszcza w przypadku danych pochodzących z różnych źródeł, w których posiadały różne formy Oszczędność miejsca na dysku Trudne w wyszukiwaniu Format zapisu zależny wyłącznie od programu/osoby wpisującej – nie gwarantuje jednolitej formy – problem w wyszukiwaniu i wyświetlaniu Problem z formatowaniem przy wyświetlaniu – ciężko połamać linie wg określonych zasad

16 ericpol.com RRRR-MM-DD 16 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - 1NF Wszystkie dane podzielone wg kategorii Adres - osobny nieokreślony string Telefon i fax – osobne nieokreślone stringi – osobny nieokreślony string Dość łatwe dopisywanie zwłaszcza w przypadku danych pochodzących z różnych źródeł, w których posiadały różne formy Możliwość wyszukiwania po , telefon i fax AdresTelefonFax Łódź,ul.Targowa 9A Trudności w wyszukiwaniu – po mieście i ulicy Forma zapisu w dużym stopniu zależna od programu/osoby wpisującej – nie gwarantuje jednolitej formy (kolejność zapisu adresu, nr tel z/bez prefiksów) – problem przy wyszukiwaniu Problem z formatowaniem przy wyświetlaniu – ciężko połamać linie wg określonych zasad w przypadku adresu

17 ericpol.com RRRR-MM-DD 17 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - 1NF Wszystkie dane podzielone wg kategorii Adres – podzielone na kolumny dla kodu pocztowego, miasta i ulicy Telefon i fax – osobne nieokreślone stringi – osobny nieokreślony string Duże możliwości wyszukiwania - po , telefon i fax, kod pocztowy, miasto Duże możliwości formatowania przy wyświetlaniu – kolejność i podział na linie wg dowolnych zasad KodPocztMiastoUlicaTelefonFax Łódźul.Targowa 9A Trudności w wyszukiwaniu – po ulicy Utrudniony zapis – należy pilnować co gdzie jest wpisywane Forma zapisu w pewnym stopniu zależna od programu/osoby wpisującej – nie gwarantuje jednolitej formy (nr tel z/bez prefiksów) – problem przy wyszukiwaniu

18 ericpol.com RRRR-MM-DD 18 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - 1NF Wszystkie dane podzielone wg kategorii Adres – podzielone na kolumny dla kodu pocztowego, miasta i ulicy Ulica – podzielona na kolumny dla prefix (ul., al.), nazwa ulicy i numery Telefon i fax – osobne nieokreślone stringi i wydzielony nr kierunkowy – osobny nieokreślony string Duże możliwości wyszukiwania - po , telefon i fax, kod pocztowy, miasto, ulica Duże możliwości formatowania przy wyświetlaniu – kolejność i podział na linie wg dowolnych zasad KodPocztMiastoPrefUlicaNrKier Telefon Fax ŁódźulTargowa9A Bardzo utrudniony zapis – należy pilnować co gdzie jest wpisywane Forma zapisu w pewnym stopniu zależna od programu/osoby wpisującej – nie gwarantuje jednolitej formy (nr tel z/bez prefiksów) – problem przy wyszukiwaniu

19 ericpol.com RRRR-MM-DD 19 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF 2NF - Dla zdefiniowanego klucza nie może istnieć podzbiór atrybutów podstawowych, który identyfikuje atrybuty wtórne. 3NF - Każdy atrybut wtórny jest tylko bezpośrednio zależny od klucza głównego.

20 ericpol.com RRRR-MM-DD 20 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg..

21 ericpol.com RRRR-MM-DD 21 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg..

22 ericpol.com RRRR-MM-DD 22 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg..

23 ericpol.com RRRR-MM-DD 23 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg..

24 ericpol.com RRRR-MM-DD 24 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg..

25 ericpol.com RRRR-MM-DD 25 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF Baza danych

26 ericpol.com RRRR-MM-DD 26 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg.. tow1jm1..tow2jm2..tow3jm3..tow4jm4.. Karczek..kg..Kiełbasa..kg..Musztarda..szt..Katchup..kg.. Towar 1Towar 2Towar 3Towar 4Towar 5Towar 6Towar 7Towar 8 Karczek../kg/15/Kiełbasa../kg/20/Musztarda/szt/3/Ketchup/szt/3/5/ Towar 1Towar 2Towar 3Towar 4Towar 5Towar 6Towar 7Towar 8 Karczek../kg/15/..Kiełbasa../kg/20/..Musztarda/szt/3/..Ketchup/szt/3/5/.. Kaczka/kg/2/23/..Ogórek/kg/2/10/.. Indyk/kg/12/21/..Myśliwska/kg/5/..Kaszanka/kg/5/..

27 ericpol.com RRRR-MM-DD 27 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrdata..nabywcaadres..tow1jm1..tow2jm / EricpolTargowa 9A..Karczek..kg..Kiełbasa..kg.. nrdata..nabywcaadres.. 456/ EricpolTargowa 9A.. nrtowarjmilosccenavatwartosc 456/123Karczek..kg ,25 456/123Kiełbasa..kg ,00 456/123Musztarda..szt552318,45 456/123Ketchup..szt552318,45

28 ericpol.com RRRR-MM-DD 28 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrtowarjmilosccenaWartoscNETTOvatkwotaVATwartosc 456/123Karczek Smażonykg ,002386,25461,25 456/123Kiełbasa Zwyczajnakg ,002369,00369,00 456/123Musztarda Stołowaszt5515,00233,4518,45 456/123Ketchup Pudliszkiszt5515,00233,4518,45 3NF - Każdy atrybut wtórny jest tylko bezpośrednio zależny od klucza głównego.

29 ericpol.com RRRR-MM-DD 29 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrtowarjmilosccenavat 456/123Karczek Smażonykg /123Kiełbasa Zwyczajnakg /123Musztarda Stołowaszt /123Ketchup Pudliszkiszt5523 2NF - Dla zdefiniowanego klucza nie może istnieć podzbiór atrybutów podstawowych, który identyfikuje atrybuty wtórne.

30 ericpol.com RRRR-MM-DD 30 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrtowarilosccena 456/123Karczek Smażony /123Kiełbasa Zwyczajna /123Musztarda Stołowa55 456/123Ketchup Pudliszki55 2NF - Dla zdefiniowanego klucza nie może istnieć podzbiór atrybutów podstawowych, który identyfikuje atrybuty wtórne. towarjmvat Karczek Smażonykg23 Kiełbasa Zwyczajnakg23 Musztarda Stołowaszt23 Ketchup Pudliszkiszt23

31 ericpol.com RRRR-MM-DD 31 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrtowarilosccena 456/ / / idtowarjmvat 1Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowaszt23 4Ketchup Pudliszkiszt23

32 ericpol.com RRRR-MM-DD 32 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrtowarilosccena 456/123Karczek Smażony /123Kiełbasa Zwyczajna /123Musztarda Stołowa55 456/123Ketchup Pudliszki55 568/123Karczek Smażony /124Karczek Smażony235 towarjmvat Karczek Smażonykg23 Kiełbasa Zwyczajnakg23 Musztarda Stołowaszt23 Ketchup Pudliszkiszt23

33 ericpol.com RRRR-MM-DD 33 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF nrtowarilosccena 456/ / / / / idtowarjmvat 1Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowaszt23 4Ketchup Pudliszkiszt23

34 ericpol.com RRRR-MM-DD 34 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF 1Zakład Mięsny Rarytas Łódź, Piotrkowska Ericpol SP z o.o Łódź, Targowa 9a Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowasz t 23 4Kechup Pudliszkisz t /123Łódźgotówka Baza danych

35 ericpol.com RRRR-MM-DD 35 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF 1Zakład Mięsny Rarytas Łódź, Piotrkowska Ericpol SP z o.o Łódź, Targowa 9a Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowasz t 23 4Kechup Pudliszkisz t /123Łódźgotówka Baza danych

36 ericpol.com RRRR-MM-DD 36 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF 1Zakład Mięsny Rarytas Łódź, Piotrkowska Ericpol SP z o.o Łódź, Targowa 9a Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowasz t 23 4Kechup Pudliszkisz t /123Łódźgotówka Baza danych

37 ericpol.com RRRR-MM-DD 37 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF 1Zakład Mięsny Rarytas Łódź, Piotrkowska Ericpol SP z o.o Łódź, Targowa 9a Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowasz t 23 4Kechup Pudliszkisz t /123Łódźgotówka Baza danych

38 ericpol.com RRRR-MM-DD 38 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych – 2NF i 3NF 1Zakład Mięsny Rarytas Łódź, Piotrkowska Ericpol SP z o.o Łódź, Targowa 9a Karczek Smażonykg23 2Kiełbasa Zwyczajnakg23 3Musztarda Stołowasz t 23 4Kechup Pudliszkisz t /123Łódźgotówka Baza danych Dane transakcyjne Słowniki

39 ericpol.com RRRR-MM-DD 39 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - notacje Dobrze jest przyjąć jakąś konwencję w nazywaniu obiektów bazy danych i konsekwentnie ją stosować, dzięki temu unika się pomyłek i upraszcza pracę z bazą. Nazewnictwo powinno spełniać podstawowe warunki: Jak najkrótsze Opisywać istotę obiektu W przypadku dużych schematów warto dzielić je na mniejsze grupy wyróżniając w nazwie przedrostkiem lub końcówką Wybierając notację należy mieć na uwadze ograniczenia konkretnego systemu bazodanowego (ograniczenia w długości nazw, ograniczenia użycia znaków specjalnych itp.

40 ericpol.com RRRR-MM-DD 40 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Projektowanie baz danych - notacje Obierając system notacji należy pamiętać o wszystkich typach elementów bazy danych, które powinny być wyróżnione w nazwach. Nazwa tabeli Nazwa kolumn(y) PK (np. _PK) Nazwa kolumn(y) FK (np. _FK) Nazwa kolumn(y) specyficznych (data, flaga itp.) Nazwa tabeli zależnej (np. _elements) Widoki (np. V_ ) Indexy (np. _IDXn) Triggery (np. _TRGn) Procedury Funkcje

41 ericpol.com RRRR-MM-DD 41 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Rozdział III: Składniki relacyjnych baz danych

42 ericpol.com RRRR-MM-DD 42 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - CREATE Umożliwia utworzenie nowego obiektu (tabela,widok,index,procedura itp.) CREATE name_object ( ); CREATE TABLE ( col1 [primary key] col2 [[not] null] [default value ]); CREATE TABLE INDEX indexName ON tableName (col1,col2);

43 ericpol.com RRRR-MM-DD 43 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - DROP Powoduje usunięcie obiektu z bazy DROP object_name; DROP TABLE CASCADE CONSTRAINTS; DROP VIEW ; DROP PROCEDURE ;

44 ericpol.com RRRR-MM-DD 44 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - ALTER Powoduje zmianę struktury obiektu ALTER TABLE tab1 ADD (col5 ); ALTER TABLE tab1 RENAME COLUMN col5 TO col5_new; ALTER TABLE tab1 ADD CONSTRAINT pk_id PRIMARY KEY (id); ALTER PROCEDURE my_procedure COMPILE;

45 ericpol.com RRRR-MM-DD 45 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Obiekty bazy danych - tabela CREATE TABLE users ( idint, name varchar(100), lastNamevarchar(100) ); CREATE TABLE tableName ( ); DROP TABLE tableName; ALTER TABLE tableName ADD col2 ; Tabela – podstawowa jednostka przechowywania danych w bazie. Każda tabela składa się z kolumn i wierszy.

46 ericpol.com RRRR-MM-DD 46 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Obiekty bazy danych - tabela CREATE TABLE users ( idint, name varchar(100), lastNamevarchar(100) ); CHAR VARCHAR TIMESTAMP SMALLINT NUMERIC INTEGER DECIMAL FLOAT DOUBLE BLOB Typy danych w systemie FirebirdSQL:

47 ericpol.com RRRR-MM-DD 47 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Obiekty bazy danych - tabela CREATE TABLE users ( idint, name varchar(100), lastNamevarchar(100) ); CREATE VIEW viewName ( ) AS DROP VIEW viewName; Widok – zapytanie zapisane. Są to pseudotabele, które zamiast danych przechowują zapytania do tabel. Służą głównie do uproszczenia lub przyśpieszenia innych zapytań. CREATE VIEW admini (name, lastname) AS select name,lastname from users where admin=1;

48 ericpol.com RRRR-MM-DD 48 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Obiekty bazy danych - index CREATE INDEX indexName ON tableName ( ) [unique]; DROP INDEX indexName; Indeks – struktura powiązana z tabelą, pozwalająca na przyspieszenie wyszukania. Na każdej tabeli może być jeden lub więcej założonych indeksów. Indeksy mogą być unikalne lub nieunikalne Indeksy mogą być jedno i wielokolumnowe. CREATE INDEX usersIDX1 (name, lastname) unique;

49 ericpol.com RRRR-MM-DD 49 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Obiekty bazy danych - index

50 ericpol.com RRRR-MM-DD 50 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Elementy bazy danych - constraint Jeśli dane w tabeli nie spełniają reguły to constraint'a nie da się założyć. Jeśli spróbujemy wstawić dane łamiące reguły to dostaniemy błędem. PRIMARY KEY jest mocno zalecany FOREIGN KEY jest powszechnym sposobem pilnowania zależności między tabelami (relacje – relacyjna baza danych) CHECK w wielu przypadkach jest wydajniejszy od testowania z poziomu aplikacji (zwłaszcza przetwarzanie wsadowe) Bardzo wskazane do współpracy z przetwarzaniem wsadowym CONSTRAINT – reguła pilnująca dane w tabeli. Jest to funkcja, która zawsze zwraca TRUE. Dzielimy na: NOT NULL UNIQUE KEY PRIMARY KEY FOREIGN KEY CHECK.

51 ericpol.com RRRR-MM-DD 51 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Elementy bazy danych – constraint check (value > 10000) check (Town like 'Amst%') check (upper(value) in ( 'A', 'B', 'X' )) check (Minimum <= Maximum) create table MyData ( id int not null primary key, record_created timestamp default current_timestamp) create table eik ( a int not null primary key, b int not null unique); create table beuk ( b int references eik);

52 ericpol.com RRRR-MM-DD 52 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Rozdział IV: Podstawy SQLa

53 ericpol.com RRRR-MM-DD 53 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL DML (ang. Data Manipulation Language) select, insert, update, delete DDL (ang. Data Definition Language) create, drop, alter DCL (ang. Data Control Language) grant, revoke, deny SQL (ang. Structured Query Language ) – strukturalny język zapytań używany do tworzenia, modyfikowania baz danych oraz do umieszczania i pobierania danych z baz danych. (pl.wikipedia.org)

54 ericpol.com RRRR-MM-DD 54 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - INSERT Typ wstawianej wartości musi się zgadzać z typem kolumny Brak wpisanej wartości do kolumny jest równoważne w wstawieniem wartości NULL Przelicza indeksy i sprawdza constrainty (np. klucze obce) INSERT INTO tab1 [(col1,col2,col3)] VALUES (val1,val2,val3); INSERT INTO tab1 [(col1,col2,col3)] SELECT val1,val2,val3 FROM other_table;

55 ericpol.com RRRR-MM-DD 55 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - UPDATE Zapytanie zmienia wartość we wskazanej kolumnie dla wszystkich wierszy bądź wskaznych w klauzuli WHERE Typ zmienianej wartości musi się zgadzać z typem kolumny (możliwe są konwersje niejawne) Przelicza indeksy i sprawdza constrainty (np. klucze obce) UPDATE tab1 SET col1 = val1 WHERE ; UPDATE tab1 t1 SET col4 = 4 WHERE t1.col2 = 1; UPDATE tmp_visits v SET vis_prevTime = (select max(t.vis_time) from tmp_visits t where t.vis_time < v.vis_time);

56 ericpol.com RRRR-MM-DD 56 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - DELETE Usuwa wszystkie rekordy z tabeli bądź wskaznych w klauzuli WHERE Przelicza indeksy i sprawdza constrainty (np. klucze obce) TRUNCATE usuwa szybko i wszystko DELETE FROM tab2 WHERE col3 = ;

57 ericpol.com RRRR-MM-DD 57 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - SELECT Wynikiem jest zbiór danych W SELECT można używać funkcji agregujących: min(),max(),sum(),count(),list() (select list('[' || va.VAN_CODE || '] ' || va.VAN_DESCRIPTION,' ') from DRT_VISIT_ANALYSIS va where va.VAN_VIS_ID = v.vis_id;) Jeśli użyło się fkcji agregującej, wszystkie pozostałe kolumny muszą znaleźć się w GROUP BY (np. select count(*),PAR_NAME from DRT_APPOINTMENTS group by PAR_NAME;) SELECT col1, col2 FROM tab1, tab2 JOIN tab3 ON WHERE GROUP BY col1, col2 HAVING ORDER BY col1, col2

58 ericpol.com RRRR-MM-DD 58 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - SELECT W FROM zamiast tabeli można użyć innego zapytania (podzapytanie), ujmując je w nawias (np. SELECT name FROM (SELECT name FROM address_book WHERE city = 'Ladek Zdroj');) Niestety Firebird słabo to optymalizuje. Sortowanie (ORDER BY) można ustawić rosnąco (ASC) lub malejąco DESC. Domyślnie sortowanie jest ASC. Klauzulę HAVING stosuje się w przypadku użycia funkcji agregujących z grupowaniem (GROUP BY), przy żądaniu wyników których agregacja ma spełniać określony warunek (np. select count(*),PAR_NAME from DRT_APPOINTMENTS group by PAR_NAME having count(*) >1;) Użycie słowa kluczowego DISTINCT powoduje ograniczenie zapytania do niepowtarzających się wierszy (np. SELECT DISTINCT name FROM addres_book WHERE city='Ladek Zdroj';)

59 ericpol.com RRRR-MM-DD 59 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) Perfidny przykład SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

60 ericpol.com RRRR-MM-DD 60 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) pokaże wszystkie rekordy z tab1, które łączą się z tab3 SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

61 ericpol.com RRRR-MM-DD 61 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) pokaże wszystkie rekordy z tab1, które łączą się z tab2 SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

62 ericpol.com RRRR-MM-DD 62 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) pokaże wszystkie rekordy z tab1 oraz te z tab4, które łączą się z powyższymi jeśli dla jakiegoś wiersza tab1 i tab2 nie ma wartości w tab4, to odpowiednie kolumny w wynikach będą NULLowe SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

63 ericpol.com RRRR-MM-DD 63 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) które położenie jest właściwe? SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

64 ericpol.com RRRR-MM-DD 64 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) Jaki będzie efekt powyższego zapytania? SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

65 ericpol.com RRRR-MM-DD 65 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (inner / left join) Proste? SELECT * FROM tab1, tab2 INNER JOIN tab3 on tab1.col3 = tab3.col1 LEFT JOIN tab4 on tab1.col4 = tab4.col1 and tab4.col4 = 1 WHERE tab1.col2 = tab2.col1 And tab4.col4 = 1 And tab4.id is null;

66 ericpol.com RRRR-MM-DD 66 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (GROUP BY) Przykład SELECT count(*), APP_DR_ID FROM DRT_APPOINTMENTS GROUP BY APP_DR_ID HAVING count(*) >10 ORDER BY APP_DR_ID;

67 ericpol.com RRRR-MM-DD 67 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (GROUP BY) Podlicza wszystkie rekordy w DRT_APPOINTMENTS SELECT count(*), APP_DR_ID FROM DRT_APPOINTMENTS GROUP BY APP_DR_ID HAVING count(*) >10 ORDER BY APP_DR_ID;

68 ericpol.com RRRR-MM-DD 68 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (GROUP BY) Podlicza ilość rekordów w DRT_APPOINTMENTS dla każdego APP_DR_ID SELECT count(*), APP_DR_ID FROM DRT_APPOINTMENTS GROUP BY APP_DR_ID HAVING count(*) >10 ORDER BY APP_DR_ID;

69 ericpol.com RRRR-MM-DD 69 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (GROUP BY) Oblicza dla każdego i wybiera tylko te, których jest więcej niż 10 SELECT count(*), APP_DR_ID FROM DRT_APPOINTMENTS GROUP BY APP_DR_ID HAVING count(*) >10 ORDER BY APP_DR_ID;

70 ericpol.com RRRR-MM-DD 70 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (GROUP BY) Oblicza dla każdego i wybiera tylko te, których jest więcej niż 10, a na koniec sortuje po APP_DR_ID rosnąco SELECT count(*), APP_DR_ID FROM DRT_APPOINTMENTS GROUP BY APP_DR_ID HAVING count(*) >10 ORDER BY APP_DR_ID;

71 ericpol.com RRRR-MM-DD 71 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (GROUP BY) Aby posortować po wynikach podsumowań, trzeba zbudować podzapytanie SELECT * FROM ( SELECT count(*) ilosc, APP_DR_ID FROM DRT_APPOINTMENTS GROUP BY APP_DR_ID HAVING count(*) >10 ) ORDER BY ilosc;

72 ericpol.com RRRR-MM-DD 72 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (konwencja 1) SELECT s.MON$STATEMENT_ID, s.MON$ATTACHMENT_ID, s.MON$TRANSACTION_ID, s.MON$STATE, s.MON$TIMESTAMP, s.MON$SQL_TEXT, s.MON$STAT_ID, i.MON$STAT_GROUP, (i.MON$PAGE_READS * d.MON$PAGE_SIZE)/(1024*1024) as MBreads, (i.MON$PAGE_WRITES * d.MON$PAGE_SIZE)/(1024*1024) as MBwrites, (i.MON$PAGE_FETCHES * d.MON$PAGE_SIZE)/(1024*1024) as MBfetches, (i.MON$PAGE_MARKS * d.MON$PAGE_SIZE)/(1024*1024) as MBmarks, a.MON$STATE, a.MON$ATTACHMENT_NAME, a.MON$USER, a.MON$REMOTE_ADDRESS, a.MON$TIMESTAMP, a.MON$REMOTE_PROCESS, t.MON$TRANSACTION_ID, t.MON$STATE, t.MON$TIMESTAMP, t.MON$ISOLATION_MODE, t.MON$LOCK_TIMEOUT, t.MON$TOP_TRANSACTION, t.MON$OLDEST_TRANSACTION, t.MON$OLDEST_ACTIVE, c.MON$CALL_ID, c.MON$STATEMENT_ID, c.MON$CALLER_ID, c.MON$OBJECT_NAME, c.MON$OBJECT_TYPE, c.MON$TIMESTAMP, c.MON$SOURCE_LINE, c.MON$SOURCE_COLUMN, c.MON$STAT_ID FROM MON$IO_STATS i inner join MON$DATABASE d on 1=1 inner join MON$ATTACHMENTS a on a.mon$stat_id=i.mon$stat_id and a.MON$STATE=1 inner join MON$TRANSACTIONS t on t.MON$STAT_ID = i.mon$stat_id and t.MON$STATE=1 inner join MON$STATEMENTS s on s.MON$STAT_ID = i.mon$stat_id OR s.MON$TRANSACTION_ID = t.MON$TRANSACTION_ID inner join MON$CALL_STACK c on c.MON$STAT_ID = i.MON$STAT_ID WHERE i.MON$STAT_GROUP=3 and a.MON$REMOTE_ADDRESS=' ' order by i.MON$PAGE_FETCHES desc;

73 ericpol.com RRRR-MM-DD 73 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL – SELECT (konwencja 2) SELECT s.MON$STATEMENT_ID, s.MON$ATTACHMENT_ID, s.MON$TRANSACTION_ID, s.MON$STATE, s.MON$TIMESTAMP, s.MON$SQL_TEXT, s.MON$STAT_ID, i.MON$STAT_GROUP, (i.MON$PAGE_READS * d.MON$PAGE_SIZE)/(1024*1024) as MBreads, (i.MON$PAGE_WRITES * d.MON$PAGE_SIZE)/(1024*1024) as MBwrites, (i.MON$PAGE_FETCHES * d.MON$PAGE_SIZE)/(1024*1024) as MBfetches, (i.MON$PAGE_MARKS * d.MON$PAGE_SIZE)/(1024*1024) as MBmarks, a.MON$STATE, a.MON$ATTACHMENT_NAME, a.MON$USER, a.MON$REMOTE_ADDRESS, a.MON$TIMESTAMP, a.MON$REMOTE_PROCESS, t.MON$TRANSACTION_ID, t.MON$STATE, t.MON$TIMESTAMP, t.MON$ISOLATION_MODE, t.MON$LOCK_TIMEOUT, t.MON$TOP_TRANSACTION, t.MON$OLDEST_TRANSACTION, t.MON$OLDEST_ACTIVE, c.MON$CALL_ID, c.MON$STATEMENT_ID, c.MON$CALLER_ID, c.MON$OBJECT_NAME, c.MON$OBJECT_TYPE, c.MON$TIMESTAMP, c.MON$SOURCE_LINE, c.MON$SOURCE_COLUMN, c.MON$STAT_ID FROM MON$IO_STATS i, MON$DATABASE d, MON$ATTACHMENTS a, MON$TRANSACTIONS t, MON$STATEMENTS s, MON$CALL_STACK c WHERE i.MON$STAT_GROUP=3 AND a.mon$stat_id=i.mon$stat_id AND a.MON$STATE=1 AND a.MON$REMOTE_ADDRESS=' ' AND t.MON$STAT_ID = i.mon$stat_id AND t.MON$STATE=1 AND (s.MON$STAT_ID = i.mon$stat_id OR s.MON$TRANSACTION_ID = t.MON$TRANSACTION_ID) AND c.MON$STAT_ID = i.MON$STAT_ID order by i.MON$PAGE_FETCHES desc;

74 ericpol.com RRRR-MM-DD 74 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - warunki IS [not] NULL [not] IN ( ) [not] IN (select col from tab where ) [not] EXISTS (select 1 from tab where nadrz.id = id) BETWEEN AND Like '*' select count(*), type from group by type HAVING count(*)<10; select * from where col1 is null OR col1=0; select * from where COALESCE(col1,0)=0

75 ericpol.com RRRR-MM-DD 75 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - triggery CREATE TRIGGER DRP_APPOINTMENTS_APP_ID_TRG active before insert or update on DRT_APPOINTMENTS AS DECLARE VARIABLE USER_SESSION_ID INTEGER; BEGIN SELECT CURRENT_CONNECTION FROM RDB$DATABASE INTO :USER_SESSION_ID; IF (NEW.APP_ID IS NULL) THEN NEW.APP_ID = GEN_ID(GEN_APPOINTMENTS, 1); IF (NEW.APP_SUN_ID IS NULL) THEN NEW.APP_SUN_ID = GEN_ID(GEN_SERVICE_UNITS, 1); UPDATE DRT_LAST_ID SET LID_TIME=CURRENT_TIMESTAMP, LAST_ID = NEW.APP_ID WHERE SESSION_ID = :USER_SESSION_ID; IF (ROW_COUNT = 0) THEN INSERT INTO DRT_LAST_ID (SESSION_ID, LAST_ID) VALUES (:USER_SESSION_ID, NEW.APP_ID); END CREATE TRIGGER name [ACTIVE | INACTIVE] {BEFORE | AFTER} {INSERT | UPDATE | DELETE} ON {tablename | viewname} AS [ ] BEGIN [ ] END

76 ericpol.com RRRR-MM-DD 76 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - triggery db_event: CONNECT | DISCONNECT | TRANSACTION START | TRANSACTION COMMIT | TRANSACTION ROLLBACK CREATE OR ALTER TRIGGER DROP TRIGGER RECREATE TRIGGER Bardzo przydatne w realizacji stałych operacji na danych zawsze kiedy … to … - rozwiązanie bezpieczne i wydajne Bardzo przydatne przy przetwarzaniu wsadowym

77 ericpol.com RRRR-MM-DD 77 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - procedury CREATE PROCEDURE procname [{= | DEFAULT} value] [, {= | DEFAULT} value]...])] [RETURNS ( [,...])] AS [ ] BEGIN [ ] END

78 ericpol.com RRRR-MM-DD 78 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL SQL - funkcje DECLARE EXTERNAL FUNCTION localname [ [,...]] RETURNS { | PARAMETER 1- based_pos} [FREE_IT] ENTRY_POINT 'function_name' MODULE_NAME 'library_name'

79 ericpol.com RRRR-MM-DD 79 COMPANY/UNIT_PROJECT/PRS-RR:NNN UPL Źródła pomocy tml

80 Marek Dziedziczak, DB, DB1 Ericpol Telecom Sp. z o.o. Tel.: Dziękuję za uwagę.


Pobierz ppt "Podstawy SQL dla FirebirdSQL Marek Dziedziczak, DB, DB1 Ericpol Telecom Sp. z o.o. Tel.: +48 605 506 395."

Podobne prezentacje


Reklamy Google