====== Projekt logiczny ======

=====-. Projektowanie w oparciu o zdefiniowany diagram ERD =====
Nieco zmieniony [[new_erd_diagram|diagram ERD]]
<code>
CREATE TABLE friends
(
  id serial NOT NULL,
  id_user integer NOT NULL,
  id_friend integer NOT NULL,
  status smallint NOT NULL,
  CONSTRAINT friends_pkey PRIMARY KEY (id),
  CONSTRAINT friends_id_friend_fkey FOREIGN KEY (id_friend)
      REFERENCES users (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE,
  CONSTRAINT friends_id_user_fkey FOREIGN KEY (id_user)
      REFERENCES users (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)

CREATE TABLE tags
(
  id serial NOT NULL,
  "name" text,
  id_user integer NOT NULL,
  color integer,
  CONSTRAINT tags_pkey PRIMARY KEY (id),
  CONSTRAINT "owner" FOREIGN KEY (id_user)
      REFERENCES users (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)



CREATE TABLE user_event
(
  id serial NOT NULL,
  id_user integer NOT NULL,
  id_event integer NOT NULL,
  CONSTRAINT user_event_pkey PRIMARY KEY (id),
  CONSTRAINT user_event_id_event_fkey FOREIGN KEY (id_event)
      REFERENCES events (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE,
  CONSTRAINT user_event_id_user_fkey FOREIGN KEY (id_user)
      REFERENCES users (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE CASCADE
)

CREATE TABLE users
(
  id serial NOT NULL,
  "name" character varying(30),
  "login" text NOT NULL,
  "password" character(32) NOT NULL,
  session_cookie character(32),
  CONSTRAINT id PRIMARY KEY (id),
  CONSTRAINT users_login_key UNIQUE (login)
)

CREATE TABLE events
(
  id serial NOT NULL,
  id_tag integer,
  startdate date,
  title text,
  description text,
  duration integer,
  CONSTRAINT events_pkey PRIMARY KEY (id),
  CONSTRAINT events_id_tag_fkey FOREIGN KEY (id_tag)
      REFERENCES tags (id) MATCH SIMPLE
      ON UPDATE NO ACTION ON DELETE SET NULL
)

</code>



=====-. Słowniki danych =====

  * friends - tabela przechowująca dane o powiązaniach między uzytkownikami
    * id - klucz główny tabeli - serial NOT NULL,
    * id_user - użytkownik którego dotyczy relacja - klucz obcy do tabeli users.id, integer NOT NULL,
    * id_friend - użytkownik z którym związana jest relacja - klucz obcy do tabeli users.id, integer NOT NULL,
    * status - status relacji (wysłana, zaakceptowana, odrzucona) - smallint NOT NULL,

  * tags - tabela zawierająca dane o utworzonych etykietach
    * id - klucz główny tabeli - serial NOT NULL,
    * "name" - nazwa etykiety - text,
    * id_user - użytkownik z którym związana jest etykieta - klucz obcy do tabeli users.id, integer NOT NULL,
    * color - numer schematu kolorów - integer,

  * user_event - tabela zawierająca informację o powiązaniach użytkowników z wydarzeniami 
    * id - klucz główny tabeli - serial NOT NULL,
    * id_user - użytkownik którego dotyczy wydarzenie - klucz obcy do tabeli users.id, integer NOT NULL,
    * id_event - wydarzenie powiązane z użytkownikiem - klucz obcy do tabeli events.id, integer NOT NULL,

  * users - tabela zawierająca informacje o użytkownikach
    * id - klucz główny tabeli - serial NOT NULL,
    * "name" - nazwa wyświetlana użytkownika - character varying(30),
    * "login" - login użytkownika - text NOT NULL,
    * "password" - zhashowane hasło użytkownika - character(32) NOT NULL,
    * session_cookie - nazwa sesji do "zapamiętaj mnie" - character(32),

  * events - tabela zawierająca wydarzenia
    * id - klucz główny tabeli - serial NOT NULL,
    * id_tag - identyfikator etykiety - klucz obcy do tabeli tag.id, integer,
    * startdate - data rozpoczęcia wydarzenia - date,
    * title - tytuł wydarzenia - text,
    * description - opis wydarzenia - text,
    * duration -czas trwania wydarzenia - integer,
  

=====-. Analiza zależności funkcyjnych i normalizacja tabel  =====
**1NF**
  * spełniona - każda składowa w każdej krotce jest atomowa (nie daje podzielić się na mniejsze wartości). 

**2NF**
  * spełniona - bo jest 1NF oraz żaden atrybut wtórny relacji nie jest w pełni funkcyjnie zależny od wszystkich kluczy tej relacji.

**3NF**
  * spełniona - bo jest 2 NF oraz każdy atrybut wtórny jest tylko bezpośrednio zależny od klucza głównego.





=====-. Projektowanie operacji na danych =====
W projekcie zastosowane zostało mapowanie OR obsługiwane przez bibliotekę Hibernate.

**Konfiguracja Hibernate'a**
<code><?xml version="1.0"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
                                   "http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<!-- Generated May 3, 2011 3:57:34 PM by Hibernate Tools 3.4.0.CR1 -->
<hibernate-mapping>

 <class name="model.User" table="users">
  <id name="id" type="long">
   <generator class="identity"/>
  </id>
  <property generated="never" lazy="false" name="name"/>
  <property generated="never" lazy="false" name="login"/>
  <property generated="never" lazy="false" name="password"/>
  <property column="session_cookie" generated="never" lazy="false" name="sessionCookie"/>
  <set name="events" sort="unsorted" table="user_event">
   <key column="id_user"/>
   <many-to-many class="model.Event" column="id_event" unique="false"/>
  </set>
  <set inverse="true" name="friends" sort="unsorted" table="friends">
   <key column="id_user"/>
   <one-to-many class="model.Friend"/>
  </set>
  <set inverse="true" name="tags" sort="unsorted" table="tags">
   <key column="id_user"/>
   <one-to-many class="model.Tag"/>
  </set>
 </class>
 
 <class name="model.Friend" table="friends">
  <id name="id" type="long">
   <generator class="identity"/>
  </id>
  <property generated="never" lazy="false" name="status"/>
  <many-to-one column="id_user" name="user" lazy="false"/>
  <many-to-one column="id_friend" name="friend" lazy="false"/>
 </class>
 
 <class name="model.Event" table="events">
  <id name="id" type="long">
   <generator class="identity"/>
  </id>
  <many-to-one column="id_tag" name="tag" lazy="false"/>
  <property generated="never" lazy="false" name="startDate"/>
  <property generated="never" lazy="false" name="title"/>
  <property generated="never" lazy="false" name="description"/>
  <property generated="never" lazy="false" name="duration"/>
 </class>
 
 <class name="model.Tag" table="tags">
  <id name="id" type="long">
   <generator class="identity"/>
  </id>
  <property generated="never" lazy="false" name="name"/>
  <property generated="never" lazy="false" name="color"/>
  <many-to-one column="id_user" name="user" lazy="false"/>
 </class>
 
</hibernate-mapping>

</code>

==== Zapytania SQL ====
 **Logowanie użytkownika:**

Podczas logowania sprawdzane jest czy w bazie danych istnieje podany login i hasło:
<code>select user0_.id as col_0_0_ from public.users user0_ where user0_.login=? and user0_.password=?</code>
Następnie po sprawdzeniu pobierane są dane użytkownika:
<code>select user0_.id as id0_, user0_.name as name0_, user0_.login as login0_, user0_.password as password0_,
 user0_.session_cookie as session5_0_ from public.users user0_ where user0_.login=?</code>

W następnej kolejności pobierane są dodatkowe dane powiązane z bieżącym użytkownikiem.
Wydarzenia pobierane są poprzez wewnętrzne złączenie tabel user_event (tabela asocjacyjna wiążąca użytkowników z wydarzeniami) oraz events (tabela z wydarzeniami):
<code>select […] from public.user_event events0_ inner join public.events event1_ 
on events0_.id_event=event1_.id where events0_.id_user=? </code>
Dla każdego wydarzenia pobierane są etykiety (dla każdej użytej etykiety):
<code>select tag0_.id as id4_0_, tag0_.name as name4_0_, tag0_.color as color4_0_,
 tag0_.id_user as id4_4_0_ from public.tags tag0_ where tag0_.id=?</code>
Następnie pobierane są informacje o znajomych użytkownika:
<code>select […] from public.friends friends0_ where friends0_.id_user=?</code>
Ponieważ tabela friends jest tabelą asocjacyjną, konieczne jest pobranie reszty danych (każde zaytanie oddzielnie, ponieważ tabela friends z punktu widzenia mappera nie jest tablicą asocjacyjną, gdyż mapuje ona na nową klasę Friend, która posiada wskaźniki do użytkownika, jego znajomego, oraz dodatkowo posiada informacje o stopniu znajomości – znojomy, zaproszony, zablokowany):
<code>select user0_.id as id0_0_, user0_.name as name0_0_, user0_.login as login0_0_, user0_.password as password0_0_, 
user0_.session_cookie as session5_0_0_ from public.users user0_ where user0_.id=? </code>
Ostatecznie pobierane są także wszystkie etykiety, jakimi może zarządzać dany użytkownik:
<code>select tags0_.id_user as id4_0_1_, tags0_.id as id1_, tags0_.id as id4_0_, tags0_.name as name4_0_, tags0_.color as color4_0_,
 tags0_.id_user as id4_4_0_ from public.tags tags0_ where tags0_.id_user=? </code>

**Wyszukiwanie znajomych:**

Wystarczy jedno zapytanie o użytkowników, których nazwa lub login pasują do wzorca
<code>select user0_.id as id0_, user0_.name as name0_, user0_.login as login0_,
user0_.password as password0_, user0_.session_cookie as session5_0_ from
public.users user0_ where user0_.login like ? or user0_.name like ? </code>

**Wysyłanie zaproszenia do znajomego:**

Wysłanie zapytania typu insert:
<code>insert into public.friends (status, id_user, id_friend) values (?, ?, ?)</code>

**Dodawanie wydarzenia:**

Wysyłane są dwa zapytania typu insert, ponieważ należy dodać dane zarówno do tabeli z wydarzeniami, jak i do tabeli asocjacyjnej:
<code>insert into public.events (id_tag, startDate, title, description, duration) values
(?, ?, ?, ?, ?) </code>
oraz:
<code>insert into public.user_event (id_user, id_event) values (?, ?)</code>

**Porównywanie kalendarzy:**

Dla każdego wybranego do porównania użytkownika , konieczne jest pobranie listy jego wydarzeń.
Jest to spowodowane mechanizmem lazy-load. Zbiory (w tym wypadku zbiory wydarzeń) ładowane są dopiero przy pierwszym ich użyciu. Dlatego też dla każdego wybranego użytkownika nastąpi wysłanie zapytania:
<code>select […] from public.user_event events0_ inner join public.events event1_ on
events0_.id_event=event1_.id where events0_.id_user=?</code>