Zadanie. Czy prawdziwe jest stwierdzenie, że w kluczu żaden atrybut nie może być funkcyjnie zależny od żadnego innego atrybutu tego klucza? Odpowiedź uzasadnić.
Definicja klucza: Niech dany będzie schemat relacyjny R = (U; F).
Zbiór atrybutów K <= U (zawarty w U) nazywamy kluczem schematu R wtedy i tylko wtedy, gdy zbiór ten spełnia następujące warunki:
1. K -> U (jednoznaczna identykowalność wszystkich pozostałych atrybutów).
2. X -> U => ~(X < K) (minimalność, czyli nie istnieje taki podzbiór atrybutów schematu R zawarty w K, który by jednoznacznie identyfikował wszystkie inne atrybuty. innymi słowy po usunięciu z K dowolnego atrybuty nie będzie spełniony warunek 1.)
Gdyby którykolwiek z atrybutów klucza schematu relacji R wyznaczał funkcyjnie którykolwiek inny z atrybutów klucza, to nie byłby spełniony warunek minimalności klucza, zatem podzbiór K nie byłby kluczem lecz nadkluczem. Zatem twierdzenie jest prawdziwe.
Zadanie . Dany jest schemat relacji R=(U,F). U={A,B,C,D} F={AB->C,B->D,BC->A}
Klucze: AB, BC Czy schemat R jest w 3PN? Dlaczego?
Schemat R jest w 1PN, ponieważ wszystkie atrybuty są atomowe.
Schemat R nie jest w 2PN ponieważ jedyny atrybut niekluczowy D, nie zależy w pełni funkcyjnie od każdego z kluczy (B -> D). Ponieważ schemat R nie jest w 2PN to nie może też być w 3PN.
Zadanie - Dany jest schemat bazy danych NOCLEGI: Hotele(hotelNr, hotelNazwa, miasto)
Pokoje(pokojNr, hotelNr, rodzaj, cena) Rezerwacje(hotelNr, goscNr, dataOd, dataDo, pokójNr)
Goście(goscNr, goscNazwisko, goscAdres)
Zadanie I.1.a:
SELECT Pokoje WHERE Cena>50 GIVING R1 JOIN Hotele and R1 OVER hotelNr GIVING R2
PROJECT R2 OVER hotelNazwa GIVING WYNIK
Zadanie I.1.b:
RANGE Pokoje X GET W(Hotele.hotelNazwa): EX(Hotel.hotelNr = X.hotelNr i X.Cena>50)
Zadanie I.1.c
SELECT hotelNazwa FROM ( (SELECT * FROM Pokoje WHERE cena > 50) JOIN Hotele ON hotelNr) )
Zadanie I.2.b. Podaje nazwiska wszystkich gości przebywających aktualnie w hotelu
SELECT goscNazwisko FROM Goście WHERE goscNr IN (SELECT goscNr FROM Rezerwacje WHERE
hotelNr IN (SELECT hotelNr FROM Hotele WHERE hotelNazwa='Merkury')
AND (dataOd<DATE() AND dataDo>DATE()) )
I/4Nadaj użytkownikom o identy. recepcjonista prawa dostępu INSERT do relacji Goście i Rezerwacje.
CREATE ROLE recepcjonista
GRANT INSERT ON Goście TO recepcjonista
GRANT INSERT ON Rezerwacje TO recepcjonista
G 1. wypisać reguły, zrobić ERD i schematy relacji dla *bardzo prostego* przykladu (Klienci i Konta, klient może mieć wiele kont, konto należy do jednego klienta). Lista atrybutów Klienta i Konta była podana. 2 reguły, prosty schemacik ze zwiazkiem 1,1-0,N i ok. Relacje wyszly a'la Klienci(NrKlienta, Nazwisko, ...), Konta(NrKonta, NrKlienta, TypLokaty, ...)
2. zaznaczyć klucze w tych relacjach
3. zaproponować dziedzinę atrybutu "TypLokaty" (dałem że liczba - ilość miesięcy)
4. coś tam o zapewnieniu, żeby konto było przypisane zawsze do jakiegoś klienta Wynika to z wprowadzenia reguly, i zrobieniu zwiazku z ktorego wychodzi schemat relacji Konta z obligatoryjnym kluczem zewnetrznym. Nie napisalem doslownie "obligatoryjny" ale sie o to dopytal i wyraznie zalezalo mu na tym.
5. Napisac zapytanie we wszystkich 4 jezykach, proste bylo, bodajze o id i nazwiska kilentow posiadajacych lokaty jakiegos typu.
W QbE dalem:
Klienci |
NrKlienta |
Nazwisko |
|
Konta |
NrKonta |
NrKlienta |
TypLokaty |
|
P._ID |
P. |
|
|
|
_ID |
12 |
SQL:
SELECT NrKlienta, Nazwisko FROM Klienci WHERE NrKlienta IN (SELECT NrKlienta FROM Konta WHERE TypLokaty=12)
6. Czy schematy relacji sa w 3PN i dlaczego (2PN bo klucze proste, 3PN bo nie bylo zaleznosci funkcyjnych poza kluczowymi wiec nie ma zaleznosci przechodnich)
7. Nadac userowi Kowalski uprawnienia (SQL) do odczytu _jego wlasnych_ danych. Podobno chodzilo o perspektywy. Ostatecznie zrobilem GRANT READ ON Kowalski_Dane To Kowalski z komentarzem, ze zakladam ze Kowalski_Dane to perspektywa tablicy Dane ograniczona do danych Kowalskiego.
8. Napisac w SQL sprawdzanie warunku ze kazdy klient ma jakies konto. Zrobilem proste query ktore liczylo klientow bez konta z komentarzem ze jak zwróci zero, to warunek jest spełniony.