Kwerenda : Podać numery dostawców którzy dostarczają

Kwerenda : Podać numery dostawców którzy dostarczają przynajmniej jedna cześć,
którą dostarcza przynajmniej jeden dostawca który dostarcza przynajmniej jedną część
czerwoną.
SELECT NAZWISKO
FROM D
WHERE D# IN
(SELECT D#
FROM DC
WHERE C# = ’CZ’)
• Druga wersja z kwantyfikatorem ANY:
SELECT NAZWISKO
FROM D
WHERE D# = ANY
(SELECT D#
FROM DC
WHERE C# = ‘CZ’)
• Relacje D I DC są złączone ze względu na wspólny element
SELECT NAZWISKO
FROM D,DC
WHERE D.D# = DC.D# AND C#=’CZ’
• Kwantyfikator EXIST
SELECT NAZWISKO
FROM D
WHERE EXIST
(SELECT FROM DC
WHERE D# = D.D#
AND C#=’CZ’)
• Przykład: zapytanie skorelowane
SELECT NAZWISKO
FROM D
WHERE ‘CZ’ IN
(SELECT C#
FROM DC
WHERE D#=D.D#)
• Przykład z kwantyfikatorem ANY z tymże mamy tutaj to zapytanie skorelowane
SELECT NAZWISKO
FROM D
WHERE ‘CZ’ = ANY
(SELECT C#
FROM DC
WHERE D# = D.D#)
• Przykład z group
SELECT NAZWISKO
FROM D, DC
WHERE D.D# = DC.D# AND C#=’CZ’
GROUP BY NAZWISKO
• Ad. Kwerenda podana na początku
SELECT IN
FROM DC
WHERE C# IN
(SELECT C#
FROM DC
WHERE D# IN
(SELECT D#
FROM DC
WHERE C# IN
(SELECT C#
FROM C
WHERE KOLOR=’RED’)))
Złączenia zewnętrzne – dwie relacje oznaczające klientów banku (A- maja konto, B- biorą
pożyczki), ostatni atrybut numer konta I numer pożyczki, należy je złączyć, wspólne atrybuty
to nr klienta i nazwisko, pierwsze złączenie AxB to normalne według atrybutów K# i
nazwisko, czyli to te osoby które posiadają i konto i pożyczka, drugie złączenie lewostronne
czyli tylko Ci co maja konto ( wszystkie z A i niektóre z B) czyli do relacji dopisywany jest
numer pożyczki(nie wszyscy biorą wiec będę puste pola tam), Parkera np. nie ma bo nie ma
konta
Potem złączenie prawostronne , mamy tutaj wszystkich co wzięli pożyczki(wszystkie krotki z
relacji B) – wartości wystąpią przy numerze konta,
Złączenie obustronne całkowite – wszystkie krotki z obydwu relacji
A
K#
name
Nr.k
1
Blake
1000
2
Smith
1203
3
Clark
1142
4
Davis
1358
5
Blair
1224
B
K#
name
Nr.p
1
Blake
125
6
Lewis
132
7
Ray
141
4
Davis
115
8
Parker
105
Złączenia zostały złączone w SQL, rezultat złączenie występuje po słowie from
Przykłady
SELECT DISTINCT NAME
FROM D NATURAL JOIN DC
WHERE C#=’CZ’
JOIN – wg wszystkich atrybutów o takich samych nazwach
bez natural trzeba zdefiniować wg czego następuje złączenie
lub z ON
SELECT DISTINCT NAME
FROM D JOIN DC ON
D.D# = DC.D# AND C#=’CZ’
Inne formy :
Całkowite złączenie naturalne – czyli obustronne gdzie wystąpią krotki z obydwu relacji,
potem left I right, takie wyrażenie mocze wystąpić po słowie from
D NATURAL FULL OUTER JOIN DC
D NATURAL LEFT OUTER JOIN DC
D NATURAL RIGHT OUTER JOIN DC
Powyższych złączeń nie można stosować na egzaminie, czyli jak będzie polecenie ze trzeba
losować SQL to nie można stosować ten złączeń,
D FULL OUTER JOINC ON DMIASTO=CMIASTO
D LEFT OUTER JOIN C ON
DMIASTO = CMIASTO
D RIGHT OUTER JOIN C ON
D MIAASTO=CMIASTO
Operacje typu UPDATE – są to takie które cokolwiek zmieniają
1. tworzenie indeksu ( słowa kluczowe CREATE INDEX) – tworzymy index na
atrybucie status w relacji D
CREATE INDEX RANGA ON DCSTATION
2. drop oznacza usuniecie indexu, indexy spowalniają aktualizacje czyli wprowadzanie
danych
DROP INDEX RANGA
Insert
–
wprowadzenie
czegoś,
tutaj
konkretnych
wartości,
poniżej
przepisanie(wykorzystanie już wprowadzonych i przepisanie ich do innej relacji)
INSERT INTP D(D# NAZWISKO)
INSERT INTO D.100
SELECT D#, NAZWISKO, MIASTO,
FROM D
WHERE STATUS>100
STATUS
Delete – usuwa wszystko z dc
DELETE FROM DC
DELETE FROM D
WHERE STATUS < 10
Definiowanie nowych tabel - R – nazwa nowej tabeli , A – atrybut, D – opis – description
, <I,c> - warunki integralności – może być wiele od 1 do n
Primary key – główny klucz
Foreign key – obcy klucz
Warunek opisany słowem checz ( p – oznacza warunek który musi być sprawdzony)
CREATE TABLE
R(A1D1,A2D2,….,ANDN)
<i1c1>
……
<in,cn>)
Opis atrybutu (wiersza bo w jednym wierszu jest) może zawierać typ danych oraz
dodatkowe informacje typu IS NOT NULL np. czy tez PRIMARY KEY(tylko jeden
atrybut może mieć taki atrybut)
Przykłady
CREATE TABLE LEKI
(NUMER INTEGER NOT NULL,
NAZWA_HANDLOWA CHAR(20),
PRODUCENT# INTEGER,
POSTAC CHAR(20)
DAWKA INTEGER
PRIMARY KEY(NUMER))
Operacje typu update
UPDATE DC
SET ILOŚĆ=ILOSC+10
WHERE D#=’01’
(na egzaminie jak nie będziemy umieli rozwiązać zad w SQL to można podać instrukcje
jakie są w SQL żeby to jakoś przejść)
Zmiana schematu relacji
Słowo ALTER – można dodawać atrybuty i można je usuwać, wreszcie można usuwać
tabele
ALTER TABLE LEKI
ADD KRAJ CHAR(20)
ALTER TABLE LEKI
DROP POSTAC
DROP TABLE LEKI
Więzy klucza obcego można definiować poprzez umieszczenie następującego opisu
wiersza
PRODUCENT# INTEGER
REFERENCES FARM(P#)
CZYLI TO ZNACZY ZE WARTOSCI ATRYB UTU PRODUCENT # NALEŻY DO OPISU
ATRYBUTY P# RELACJI farm
Relacja – nie ma nazwy atrybutu, bo kluczem relacji d jest d # , c c# więc tu mamy takie
same nazwy , a skoro są takie same nazwy to nie trzeba oznaczać)
CREATE TABLE DC
(D# INT REFERENCES D
C# INT REFERENCES C
ILOSC INT
PRIMARY KEY(D#,C#))
Inny sposób definiowania klucza obcego
FOREIGN KEY(D#) REFERENCES D
Inne formy – możemy w wierszu relacji(atrybutowym) napisać
SPRAWDZ ZE ATRYBUT DECK ZNAJDUJE SIĘ W TAKIM I TAKIM ZBIORZE
CHECK (DEG IN(‘Bach’,’Most’,’Dac’))
Sprawdza czy dawka jest większa od zera
CHECK(DAWKA>0)
Sprawdź czy nazwisko znajduje się w zbiorze określonym przez kwerendę
CHECK(B_NAME IN
(SELECT B_NAME
FROM B)
PRODUCENT # INTEGER
CHECK(PRODUCENT # IN
(SELECT P#
FROM FARM))
Inna forma definiowania więzów klucza obcego, sprawdzamy czy wartość atrybuty
znajduje się w zbiorze będącym odpowiedzią dla atrybutu
Alternatywa dla tego jest za pomocą klucza obcego z references – poprzedni sposób jest o
wiele lepszy, bo tutaj tylko sprawdzi wartość atrybutu producent ale jeśli ten numer nie
będzie spełniał warunku to operacja zostanie odrzucona, natomiast ten warunek pozwoli
na zmianę relacji, nie dotyczy relacji farm ( relacja lekka)
Tam definiował relacje pomiędzy obydwoma polami ( a nie jak tu na jedno narzucony
warunek)
PERESPEKTYWY
SA to relacje wirtualne tzn. nie zawierają żadnych danych, definiują obraz bazy danych
widziany przez użytkownika
Tworzymy ja za pomocą instrukcji CREATE VIEV
Tutaj powstaje perspektywa o nazwie D_L zawierająca krotki opisujące dostawców
mieszkających w Londynie
CREATE VIEW D_L AS
SELECT #
FROM D
WHERE MIASTO=’LONDYN”
Nazwa perspektywy może pojawić się wszędzie tam gdzie występuje nazwa relacji
Dalej mamy przykład tego – chcemy znaleźć nazwiska dostawców o statusie większym
niż 100
SELECT NAME
FROM D_L
WHERE STATUS>100
(system sam wykona odpowiednie przekształcenia – zamiast D_L from, no i że miasto =
Londyn)
Trudniej jest używać perspektyw przy wprowadzaniu nowych krotek
CREATE E VIEW RANGA AS
SELECT C#, STATUS
FROM DC,D
WHERE DC.D#=D.D#
perspektywa ranga została zdefiniowana za pomocą dwóch relacji a poprzednia za
pomocą jednej I to jest bardzo duża różnica, Dla każdej dostarczanej części podawany jest
status jej dostawcami, wiec łączymy relacje z dostawcami i mamy odpowiedni atrybut
przypuśćmy ze za pomocą tej perspektywy wprowadzamy krotkę C5 20. wymaga to
wprowadzenia do relacji d krotki NULL NULL 20 NULL oraz do DC krotki NULL C5
NULL. Przypuśćmy ze następnie usiłujemy wykonać kwerendę za pomocą tej
perspektywy. Krotka C5 20 nie będzie należeć do odpowiedzi
Otóż wyznaczenie odpowiedzi wymaga realizacji złączenia, są tu łączone krotki z
atrybutami o wartościach NULL. Zgodnie z zasada działań na wartościach pustych NULL
/= NULL.
5 jest NULL
5<NULL – niewiadomo – relacja UNKNOWN
Miejsce bazy danych w systemie informatycznym
Model związków encji jest jednym z narzędzi projektowania systemów, drugim
narzędziem SA diagramy przepływu danych DFD (DATA FLOW DIAGRAM)
Elementy diagramu DFD
1) procesy – zadania spełniane przez system
2) magazyny danych – SA to dane w spoczynku
3) przepływy – dane w ruchu
4) terminatory – obiekty z którymi kontaktuje się system(obiekty zewnętrzne)
Przebieg procesu projektowania
OPIS PROJEKTU
OMF
OML
NML
NMF
OML – MODEL (o- obecny n – nowy, f – fizyczny lub l- logiczny)
OMF - służy implementacji dla informatyka który ma rozpoznać obiekt, uwzględnia
szczegóły implementacyjne systemu,
OML - uwzględnia wymagania użytkownika bez szczegółów implementacyjnych, czyli to co
system robi a nie to co jak robi
NML – nowy model logiczny – opisuje to co system ma robić
NMF – szczegóły implementacyjne nowego systemu
Jeżeli OML = NML to celem projektowania jest poprawienie implementacji systemu
Na czym polega ta różnica ??
– opis tego co się dzieje wraz z opisem szczegółów implementacyjnych, przychodzą
zamówienia i przyjmuje je Jerzy(powiedziana tez nazwa procesu – osoba realizująca pewne
zadanie), dalej komputer, - urzędnik sprzedaży, urzędnik wysyłki ktoś kto produkuje wysyłkę
i ktoś kto produkuje i wysyła faktury, segregator – magazyn danych i w nim tez plik
zamówień
Niżej to samo tylko bez szczegółów implementacyjnych – PRZYJM ZAM – przyjmij
zamówienie, nie ma już podanej osoby jest tylko wpisane w nazwie zadanie procesu, mamy
tylko utwórz dokument wysyłki i utwórz fakturę
Model podstawowy systemu – skalda się z
!) Diagramu kontekstowego
2) listy zdarzeń podstawowych na które system ma reagować
3) celu systemu
1) Diagram kontekstowy – zawiera jeden proces oznaczający system oraz terminatory z
którymi się system kontaktuje
Mamy następujące terminatory – klienci drukarnia kierownictwo księgowość
Mogą ale nie musza być etykietowane tak jak tutaj SA niektóre, klient przychodzi i kontaktuje
się z systemem wysyłając zamówienie a potem on dostaje fakturę
Wyróżniamy zdarzenia(na które system ma reagować) sterowane przepływem oraz zdarzenia
temporalne
Te pierwsze to zdarzenia asynchroniczne – mogą pojawić się w dowolnej chwili(mieć miejsce
w dowolnej chwili) na przykład- przychodzi pacjent do ośrodka zdrowia i trzeba wszystko
opisać, jak go obsłużyć – trzeba to dokładnie opisać jako jeden z wariantów, następnie
obsługa zdarzenia może wymagać kontaktu z innym terminatorem czyli wysłania do niego
przepływu i oczekiwania odpowiedzi, może to też wymagać przeczytania danych z magazynu
danych
Zdarzenia temporalne mają miejsce w ściśle określonych chwilach. Przyjmuje się ze w
systemie znajduje się zegar, przykład – na godzinę 14 musi być gotowy raport dla
księgowości, tutaj nie ma żadnego przepływu który by to zdarzenie uruchamiał (poprzednio
żeby zaistniało zdarzenie musiał istnieć przepływ)
Dla każdego zdarzenia tworzymy diagram, zawiera on jeden proces oraz odpowiednia ilość
terminatorów i magazynów danych
Terminator w postaci pacjenta, przychodzi pacjent ale może w rożnym celu Np umówić się na
wizytę więc trzeba przeczytać magazyn danych w postaci kalendarza wizyt i przypisać mu,
może przyjść do lekarza – informacja o lekarzach, na badania – inf. o badaniach, może
przyjść zapłacić rachunki
Magazyny danych stanowa interfejs miedzy procesami opisującymi poszczególne zdarzenia –
diagramy dla wszystkich zdarzeń umieszcza się na jednym rysunku . ze względu na brak
czytelności tego rysunku kolejnym etapem jest łączenie procesów. Powstają w ten sposób
procesy wyższego rzędu
(skomplikowany rysunek – nie przepisany)
Uzupełnieniem opisu procesu jest specyfikacja
Strukturalny język naturalny – połączenie cech języka naturalnego i języka
programowania(łatwy i zrozumiały z precyzyjnym) – narzucono w nim ograniczenia na
postać formułowanych zdań - są to zdania w trybie rozkazującym (tak aby osoba nie znająca
się mogła zrozumieć)
Zd-1
Zd-2
…
Zd-n
IF war-1
Zd-1
Zd-2
ELSE
Zd-2
Zd-4
Zd-5
ENDIF
DO WHILE war-1
Zd-1
Zd-2
Zd-3
………………………….
Za pomocą takich zdań można zdefiniować specyfikacje – specyfikacja procesu polegającego
na przenoszeniu pacjenta do archiwum (jego danych)
2 magazyny danych pacjenci i karty pacjentów, mamy z nich przenieść rekordy do archiwum
ale trzeba przewidzieć sytuacje awaryjne kiedy nie ma odpowiedniego rekordu, zarówno
magazynie danych pacjenci jak i karty pacjentów i jednocześnie poinformować użytkownika
dlatego generowana jest odpowiedz
BEGIN
ZNAJDŹ pacjenta w PACJENCI
Z pasującym ID_pacjenta
IF nie znaleziono rekord
Odpowiedz=”nie ma pacjenta”
ELSE
ZNAJDZ kartepacjenta w
KARTY PACJENTOW z pasującym ID_pacjenta
IF nieznaleziono rekordu
Odpowiedz=”nie ma karty pacjentow”
ELSE
Przenieś rekord pacjenta do archiwum
Przenieś karte pacjenta do archiwum
Odpowiedz=”informacja przeniesiona’
ENDIF
WYSWETL odpowiedz
ENDIF