110269

l/4Nadai użytkownikom o identy. recepcjonista prawa dostępu INSERT do relacji Goścje 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* przykładu (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 związkiem 1,1-O.N i ok. Relacje wyszły 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 reguły, i zrobieniu związku z ktorego wychodzi schemat relacji Konta z obligatoryjnym kluczem zewnętrznym. Nie napisałem dosłownie "obligatoryjny" ale sie o to dopytał i wyraźnie zalezalo mu na tym.

5.    Napisać zapytanie we wszystkich 4 jeżykach, proste było, bodajże o id i nazwiska kilentow posiadających lokaty jakiegoś typu.

Klienci	NrKlien ta	Nazwis ko
	P. ID	P.

Konta	NrKont a	NrKlien ta	TypLok aty
		ID	12

WObEdalem:    _ ____

SOL:

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 było zależności funkcyjnych poza kluczowymi wiec nie ma zależności przechodnich)

7.    Nadać userowi Kowalski uprawnienia (SQL) do odczytu Jego wlasnych_ danych. Podobno chodziło o perspektywy. Ostatecznie zrobiłem GRANT READ ON Kowalski_Dane To Kowalski z komentarzem, ze zakładam ze Kowalski_Dane to perspektywa tablicy Dane ograniczona do danych Kowalskiego.

8.    Napisać w SQL sprawdzanie warunku ze każdy klient ma jakieś konto. Zrobiłem proste query które liczyło klientów bez konta z komentarzem ze jak zwróci zero, to warunek jest spełniony.