2201


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.



Wyszukiwarka

Podobne podstrony:
2201
2201
KKK 371, 372, 2201 2206, 2331 2350, 2360 2365
001 Wstepid 2201 Nieznany (2)
2201
2201
Komentarz do rozporządzenia Rady (WE) nr 2201 2003 dotyczącego jurysdykcji oraz uznawania i wykonywa
API RP 2201

więcej podobnych podstron