---
# System prepended metadata

title: Bazy Danych  lista6

---


---
tags: BD, lista 6
---
# Bazy Danych  lista6

## ZADANIA 5/5 : <span style="color:green">1</span>, <span style="color:green">2</span>, <span style="color:green">3</span>, <span style="color:green">4</span>, <span style="color:green">5</span>
**Zadanie 1**  Podaj definicję postaci BCNF. Czy powyższa baza jest w tej postaci? Dlaczego? Zaproponuj taki rozkład bazy do postaci BCNF, który jest odwracalny i zachowuje wszystkie zależności. Nie rozkładaj jakiejkolwiek tabeli, która już jest w postaci BCNF.

* Mafia(Miasto, Gang, Proceder, Szef, Dochód, ROI).
* Gang → Szef 
* Szef → Dochód 
* Proceder → ROI
* + dodatkowo: każdy gang ma przypisany 1 zbiór procederów, które uprawia w każdym mieście, w którym występuje 

**definicja** : 
Relacja R ze zbiorem zależności funkcyjnych F jest w postaci normalnej Boyce-Codda, jeśli dla każdej nietrywialnej zależności α → β (α ∩ β = ∅) zbiór α jest **nadkluczem**.

**nadklucz** - nazywamy dowolny podzbiór atrybutów, identyfikujący jednoznacznie każdy wiersz.
                                                                
Nie jest, bo zbiór *Gang* nie jest nadkluczem w tej relacji (może występować wiele wpisów z tą samą wartością w polu *Gang*).

Propzycja:
1. Kierownictwo(Gang, Szef); 
    * (*Gang* jest kluczem (nie może mieć 2 szefów))
3. Dochód(Szef, Dochód) 
    * (*Szef* jest kluczem)
4. Działalność(Gang, Miasto, Proceder) 
    * (nie zachdzą żadne zależności między atrybutami w tej relacji)
5. ROI(Proceder, ROI) 
    * (*Proceder* jest kluczem)

**Zadanie 2** Czy mimo tego, że baza (po Twoich modyfikacjach) jest w postaci BCNF dostrzegasz w niej jeszcze jakąś oczywistą redundancję? Jaka jest jej przyczyna?

* w tabeli Działalność() może występować wielokrotnie wpis o [Gang,Proceder], powtórzy się tyle razy w ilu miastach jest ten gang obecny 
* PRZYCZYNA: nie ma zależności między tymi atrybutami więc nie trzeba uważąć na powtórzenia w tej relacji. 

**Zadanie 3** Czy istnieje odwracalny rozkład pozwalający się tej redundancji pozbyć? Podaj go. Dlaczego jest on odwracalny?
* TAK, relacje 1, 2, 4 takie jak były 
* relacja 3: Lokalizacja(Gang, Miasto); Działalność(Gang, Proceder)

Dlaczego jest odwracalny? 
* weżmy dowolny stan r = <m, g, p, s, d, roi> spełniający zależności 
* czy są r1, r2, r3, r4, r5
    * <g, m> jest w Lokalizacja, <g, p> jest w Działalność
    * więc <g, m, p> jest w Lokalizacja x Działalność
    * <g, s, d> jest w Kierownictwo x Dochód 
    * więc <m, g, p, s, d> jest w Lokazlizacja x Działalność x Kierownictwo x Dochód 
    * można resztę też doklejić też ROI 


**Zadanie 4** Napisz zapytanie algebry relacji zwracające niepustą odpowiedź wtedy i tylko wtedy gdy w relacji Mafia naruszona jest zależność funkcyjna ```Proceder → ROI```.

Zapytanie ma zwrócić wpisy o tej samej wartości w polu *Proceder* ale różnej wartości w polu *ROI*. 

```
σ M.RIO ≠ M2.RIO (M ⨝ M.Proceder = M2.Proceder (ρ M2 (M)))
```

**Zadanie 5** Baza(author_id, author_name, author_location, author_description, created_at, text,
tweet_id, hashtags, mentions, retweeted_tweet_id, in_reply_to_tweet_id). 

Zaprojektuj **znormalizowany** schemat bazy danych do przechowywania tweetów. Uzasadnij swoje założenia oraz swoje decyzje projektowe.

1. **Users**(*Id*, *Name*, *Location*, *Description*)
2. **Tweets**(*Id*, *UserId*, *time*, *text*)
3. **Replies**(*Id1*, *Id2*) &nbsp; &nbsp;[*Id2* <- na co tweet Id1 jest odpowiedzią] 
4. **Retweets**(*Id1*, *Id2*) [*Id2* <- czego retweet'em jest tweet Id1]
5. **Hashtags**(*Id*, *Text*)
6. **Hashtags_in_tweets**(*Idtweet*, *Idhashtag*)
7. **Mentions**(*Idtweet*, *IdUser*)

Czy to jest dobry podział, jaki ma być to podział ??? 
Rozbicie tak aby nie było redundancji. 
"Pilnując różnych zależności"
(Podzbiór kolumn nie może być determinowany przez coś co nie jest kluczem)
Jakie zależności funkcyjne tutaj zachodzą? 

**Users** <- pozwala uniknąć wielokrotnego powtarzania info o danym użytkowniku
**Tweets** <- podstawowe info o tweet'cie wszystkie kolumny determinowane tylko przez klucz Id
**Replies** i **Retweets** <- pozwala uniknąć przechowywania nulli (w sytuacji gdy dany tweet nie wspomina nikogo ani nie odapowiada na żaden inny tweet)
**Hashtags_in_tweets** oraz **Mentshion** <- bo w relacji przechowujemy tylko dane atomowe, dlatego rozicie tablicy na pary 
## MATERIAŁY


