Kwerenda : Podać numery dostawców którzy dostarczają przynajmniej jedna cześć, którą dostarcza przynajmniej jeden dostawca który dostarcza przynajmniej jedną część czerwoną. WHERE D# IN (SELECT D# C WHERE C# = CZ ) Druga wersja z kwantyfikatorem ANY: WHERE D# = ANY (SELECT D# C WHERE C# = CZ ) Relacje D I DC są złączone ze względu na wspólny element,dc WHERE D.D# = DC.D# AND C#= CZ Kwantyfikator EXIST WHERE EXIST (SELECT C WHERE D# = D.D# AND C#= CZ ) Przykład: zapytanie skorelowane WHERE CZ IN (SELECT C# C WHERE D#=D.D#) Przykład z kwantyfikatorem ANY z tymże mamy tutaj to zapytanie skorelowane WHERE CZ = ANY (SELECT C# C WHERE D# = D.D#) Przykład z group, DC
WHERE D.D# = DC.D# AND C#= CZ GROUP BY NAZWISKO Ad. Kwerenda podana na początku SELECT IN C WHERE C# IN (SELECT C# C WHERE D# IN (SELECT D# C 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 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 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, STATUS WHERE STATUS>100 Delete usuwa wszystko z dc DELETE C DELETE 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 # 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 _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 C,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