Instrukcja do projektu BD2.A – semestr 12L

Cel projektu

Celem projektu BD2.A jest przećwiczenie projektowania struktury relacyjnej bazy danych z użyciem modelowania ER (Entity-Relationship).

Etapy projektu

Projekt jest podzielony na etapy:

I. Koncepcja rozwiązania

Na podstawie treści zadania tworzony jest szkic modelu UML struktury danych; koncepcja ta jest uzgadniana z prowadzącym.

II. Model ER

Na podstawie uzgodnionej koncepcji i treści zadania tworzony jest diagram związków encji (ERD).

III. Projekt struktur relacyjnych

Wyniki modelowania ER są przekształcane w model danych relacyjnych, który następnie jest udoskonalany. Na podstawie projektu generowane są pliki DDL, służące do stworzenia struktur w bazie danych. Struktury są wypełniane danymi testowymi.

IV. Końcowe poprawki i uzupełnienia

Struktury danych są poprawiane zgodnie z zaleceniami prowadzącego. Opcjonalnie dodawane są uzupełniające elementy projektu (wyzwalacze, dodatkowe ograniczenia itp.).

Odbiory etapów projektu i terminarz

Odbiory poszczególnych etapów projektu odbywają się "wirtualnie", przy użyciu poczty elektronicznej. Gotowość części projektu do odbioru zgłasza się wysyłając do prowadzącego zajęcia list z zawartością określoną w dalszej części tej instrukcji. Otrzymanie listu przez prowadzącego powinno zostać potwierdzone; w przypadku braku potwierdzenia należy ponowić próbę lub skontaktować się z prowadzącym w celu wyjaśnienia sytuacji.

Uwaga 1: do nadawania przesyłek proszę korzystać wyłącznie z oficjalnego serwera na WEiTI. Adres nadawcy musi zawierać nazwisko wysyłającego. Listy wysyłane z innych serwerów oraz podpisane różnymi "ksywkami" będą ignorowane! Proszę ściśle przestrzegać wytycznych co do tematów listów oraz adresów, na które należy je przesyłać.

Uwaga 2: prowadzący potwierdza otrzymanie prac i sprawdza te prace zwykle dopiero po upływie terminów określonych niżej, wcześniejsze potwierdzenia mogą nie być wysyłane.

Terminy przekazania etapów projektu do odbioru określa tabela (uwaga – zmiana!):

Etap	Termin
I. Koncepcja rozwiązania	2012-04-12
I. Koncepcja rozwiązania – poprawki	2012-04-19
II. Analiza	2012-04-27
II. Analiza – poprawki	2012-05-11
III. Projekt struktur	2012-05-24
IV. Końcowe poprawki i uzupełnienia	2012-06-12

Samodzielność i jakość prac

Prace projektowe muszą być wykonane całkowicie samodzielnie. Niedozwolone jest korzystanie z "osiągnięć" poprzedników, źródeł internetowych, odbywanie konsultacji z kolegami itp. Stwierdzenie niesamodzielności pracy skutkuje niezaliczeniem projektu, bez możliwości poprawki.

Prace świadczące o rażącej ignorancji autora, tj. zawierające błędy szczególnie rażące lub w bardzo dużej liczbie, mogą być ocenione negatywnie bez możliwości poprawki.

Sprawdzenie i pozytywne ocenienie przez prowadzącego wyników danego etapu projektu jest niezbędnym warunkiem przystąpienia do etapu kolejnego.

Instrukcja

Niniejsza instrukcja będzie modyfikowana w miarę rozwoju sytuacji, np. w przypadku stwierdzenia nieprzewidzianych trudności technicznych. Należy zatem pracować z aktualną wersją instrukcji. Ważne zmiany w instrukcji, wprowadzane w czasie semestru, będą wyróżniane kolorem.

Pytania i uwagi do instrukcji należy zgłaszać pocztą elektroniczną do doc. dra inż. Tomasza Traczyka.

Konta uczestników zajęć

Każdy uczestnik zajęć, który chce korzystać z laboratorium, powinien mieć indywidualne konto na serwerze Lab1 w laboratorium 528/529. Oprócz tego każdemu uczestnikowi "z urzędu" zakładane jest konto na serwerze Oracle; konto to ma nazwę BD2A##, gdzie ## jest przydzielonym uczestnikowi numerem z listy rozesłanej pocztą elektroniczną.
Uwaga: w dalszej części instrukcji notacja BD2A## będzie oznaczała tę właśnie nazwę z przydzielonym numer uczestnika.

Awarie

Wszelkie awarie i problemy techniczne należy niezwłocznie zgłaszać pocztą elektroniczną do doc. dra inż. Tomasza Traczyka.
Zgłoszenie musi zawierać szczegółowy opis problemu i okoliczności jego powstania, w tym:

• nazwę i hasło użytkownika Oracle,
• kody (literowo-cyfrowe) błędów,
• komunikaty o błędach (w całości).

Zgłoszenia awarii nie zawierające dostatecznie szczegółowej informacji o zaistniałym problemie nie będą rozpatrywane, a zgłoszenia szczególnie ogólnikowe (jako "niegodne inżyniera") mogą być "premiowane" obniżeniem oceny.
Uwaga: problemy, które nie zostały zgłoszone, nie będą mogły stanowić usprawiedliwienia ewentualnego opóźnienia wykonania części projektu.

Znane problemy

Ponieważ w sem. 12L projekt odbywa się na całkowicie zmienionym serwerze bazy danych, mogą nastąpić różne niespodzianki. Proszę zaglądać do instrukcji, a napotkane problemy pilnie zgłaszać prowadzącemu.

Brak miejsca na dysku Z:

Należy dopilnować, by na dysku Z: było dużo wolnego miejsca.

Dziwne błędy w działaniu narzędzi w laboratorium

- Spróbować wykonać to samo z innego komputera (jeśli to pomoże, to proszę mi przesłać numer komputera na którym działało źle).
- Spróbować wykonać to samo z konta windowsowego (nie oracle'owego!) kolegi.

Ważne kwestie techniczne

Kopie rezerwowe plików projektowych

Pliki z serwera plików Lab1 nie są backupowane. Dlatego w swym dobrze pojętym interesie każdy uczestnik projektu powinien we własnym zakresie wykonywać kopie rezerwowe plików wytworzonych w czasie projektu.

Liczba sesji użytkownika

Ze względu na ograniczone zasoby serwera uprasza się nie utrzymywać wielkiej liczby jednocześnie otwartych sesji połączenia z bazą Oracle. Należy unikać uruchamiania dużej liczby programów równocześnie i zamykać narzędzia w danej chwili niepotrzebne (np. zbędne sesje SQL*Plusa czy SQL Developera itp.).

Instalacje poza laboratorium

Projekt może być wykonywany poza laboratorium, ale koniecznie za pomocą oprogramowania Oracle SQL Developer Data Modeler 3.0.
Struktury danych przedstawione do sprawdzenia muszą być (wraz z danymi przykładowymi) umieszczone w laboratoryjnej bazie danych. Dostęp do tej bazy jest możliwy spoza laboratorium, dane połączenia są następujące: host=ora1.elka.pw.edu.pl, port=1521, SID=iais, ewentualnie Service name=iais.
Niektóre wersje programu SQL*Plus do działania potrzebują wpisu w pliku konfiguracyjnym TNSNAMES.ORA, należy w nim użyć powyższych wartości.

Prowadzący projekt nie udziela konsultacji dotyczących instalacji i uruchamiania oprogramowania na komputerach poza laboratorium.

Konfiguracja środowiska w laboratorium

Ta część dotyczy osób zamierzających korzystać z laboratorium. Przed przystąpieniem do regularnej pracy osoby zamierzające korzystać z narzędzi w laboratorium powinny sprawdzić działanie kont w pracowni 528/529. Jeśli ktoś konta nie ma, a chce z laboratorium korzystać, powinien w ogłoszonym terminie e-mailem zgłosić potrzebę założenia konta prowadzącemu zajęcia.

Lp.	Czynność	Wskazówki	Ważność
1	Sprawdzić działanie konta na serwerze Lab1	Zalogować się do sieci używając nazwy użytkownika i hasła dla serwera Lab1. W przypadku nowego konta zapytać dyżurującego pracownika laboratorium o nazwę i hasło konta. W razie kłopotów poprosić dyżurującego pracownika, by zawiadomił kierownika laboratorium o zaistniałym problemie.	Zalecane
2	Sprawdzić, czy istnieje dysk Z: i czy użytkownik ma w nim prawa zapisu.	Użytkownik powinien mieć dostęp z prawami zapisu do swojego katalogu na dysku sieciowym; dysk ten powinien być przypisany do litery Z:. Jeśli litera Z: nie jest odpowiednio przypisana, dokonać "mapowania dysku sieciowego".	Zalecane
3	Utworzyć katalogi robocze	Na dysku Z: utworzyć katalogi Z:\oracle i z:\oracle\temp.	Zalecane

Przed przystąpieniem do dalszych czynności należy utworzyć odpowiednie skróty, umożliwiające wywoływanie oprogramowania we właściwym kontekście. Programy Oracle, używane w czasie projektu, powinny być wywoływane za pomocą tych skrótów.

Lp.	Czynność	Wskazówki	Ważność
1	Utworzyć folder ze skrótami do oprogramowania	Skopiować na pulpit folder c:\oracle\menu\oracle	Zalecane
2	Zmienić katalog domyślny	We właściwościach skopiowanych skrótów zmienić katalog domyślny ("Rozpocznij w") na katalog własny, w którym będą prowadzone prace nad projektem i w którym użytkownik ma prawa zapisu plików - zapewne na dysku Z:.	Zalecane

Sprawdzenie dostępu do bazy Oracle

Ta część dotyczy wszystkich uczestników zajęć. Przed przystąpieniem regularnej pracy z bazą danych wszyscy powinni sprawdzić działanie konta na serwerze Oracle. UWAGA: serwer Oracle został uruchomiony.

Lp.	Czynność	Wskazówki	Ważność
1	Sprawdzić dostęp do serwera Oracle	Wywołać program SQL*Plus. Połączyć się do bazy, używając przydzielonej nazwy użytkownika Oracle (BD2A##) i takiego samego hasła. Uwaga: hasła są wrażliwe na wielkość liter! W razie problemów niezwłocznie powiadomić pocztą elektroniczną doc. dra inż. Tomasza Traczyka.	Zalecane
2	Zmienić hasło na serwerze Oracle	Używając polecenia password lub zdania SQL alter user ... identified by ...; zmienić hasło na serwerze Oracle.	Zalecane

Konsultacje zrozumienia treści zadania

Zalecane jest zweryfikowanie rozumienia treści zadania przez skonsultowanie się z prowadzącym.

Lp.	Czynność	Wskazówki	Ważność
1	Pytania do prowadzącego	Pytania dotyczące treści zadania można wysyłać e-mailem do doc. dra inż. Tomasza Traczyka lub zadawać osobiście w godzinach konsultacji.	Zalecane

Uwaga: prowadzący nie będzie na tym etapie dokonywał wstępnej oceny diagramów ERD ani ich fragmentów, a tym bardziej kompletnych projektów.

Koncepcja rozwiązania

Na tym etapie wykonać należy szkic modelu klas UML, pokazujący rozumienie zadania. Model ten należy przedstawić prowadzącemu do akceptacji.

Szkic modelu klas UML – wymagania

Model klas UML ma być jedynie szkicem, umożliwiającym uzgodnienie rozumienia zadania.

Wymagania ogólne

Nazwa	Opis	Ważność
Zgodność z zadaniem	Model danych powinien odpowiadać treści zadania i pokrywać cały zakres zadania. Nie jest wskazane rozszerzające interpretowanie treści zadania.	Wymagane
Czytelność	Model musi być czytelny i łatwy do zrozumienia, co osiągnąć można m.in. przez stosowanie czytelnych nazw, zgodnych z terminologią użytą w zadaniu.	Wymagane

Artefakty

Szkic modelu klas powinien zawierać następujące artefakty:

Nazwa	Opis	Ważność
Klasy	Klasy odzwierciedlające całą strukturę danych, jaką autor ma zamiar zaprojektować.	Wymagane
Atrybuty	Wymagane są jedynie najważniejsze atrybuty, np. potrzebne do identyfikacji oraz niezbędne dla zrozumienia koncepcji. Typy danych atrybutów należy określić jedynie w przybliżeniu lub – jeśli narzędzie na to pozwala – nie określać ich wcale. Należy unikać stosowania złożonych typów danych.	Wymagane
Operacje	Nie należy specyfikować operacji (metod) klas.	Wymagane
Asocjacje	Asocjacje powinny dobrze odzwierciedlać istotę rozumienia zadania, zatem wskazane jest użycie – gdzie jest to potrzebne – agregacji czy kompozycji oraz podanie liczności; w przypadkach wątpliwych warto także asocjacje nazwać. Nie należy zaznaczać kierunku asocjacji (bo w tym wypadku nie ma to sensu), natomiast trzeba podać ich liczebności.	Wymagane
Identyfikatory	W modelach obiektowych nie modeluje się identyfikatorów, zatem nie należy także tworzyć atrybutów będących jedynie sztucznymi identyfikatorami. Nie należy też oczywiście modelować kluczy – to nie ten świat pojęć.	Wymagane
Komentarze	Komentarze (notatki) umieszczone na diagramie klas mogą być użyte do wyjaśnienia szczególnych zawiłości; proszę nie nadużywać! Komentarze i dodatkowe opisy umieszczone w treści e-maila będą ignorowane.	Zalecane
Bardziej zaawansowane elementy modelu	Bardziej zaawansowanych elementów modelu klas (dziedziczenia, klas potęgowych, atrybutów asocjacyjnych itp.) należy użyć tylko jeśli ułatwi to prezentację koncepcji rozwiązania.	Opcjonalne

Szkic modelu klas – instrukcja

Szkic modelu klas UML może być utworzony za pomocą dowolnego narzędzia, nawet narysowany i zaskanowany, byle dało się uzyskać wynikowy diagram w postaci pliku graficznego: JPEG, PNG lub GIF, w ostateczności PDF, o wielkości do 100kB, zdatnego do wydrukowania. (Proszę nie przesyłać screen shots, a tym bardziej fotografii, bo są nieczytelne.) Przykładowym narzędziem, którego można użyć, jest Oracle JDeveloper.

Wysyłka szkicu diagramu klas

Diagram klas należy przesłać w postaci pliku graficznego (JPEG, PNG lub GIF, w ostateczności PDF).

Lp.	Czynność	Wskazówki	Ważność
1	Sformatować diagram klas na 1 stronę wydruku	Klasy na diagramie ustawić tak, by cały diagram mieścił się na jednej stronie A4 w ustawieniu pionowym (portrait). Odpowiednio skonfigurować narzędzie, by wygenerowany plik graficzny odpowiadał takiej jednej stronie. Diagramy nie dające się wydrukować na jednej stronie A4 będą odrzucane.	Wymagane
2	Diagram zaopatrzyć w dane twórcy i zadania	Na diagramie, w jednym z górnych rogów, umieścić – np. jako notatkę UML-ową – dane twórcy i zadania: numer konta Oracle w formacie BD2A##, nazwisko i imię, numer zadania, w podanej kolejności! Diagramy bez takiego opisu będą odrzucane.	Wymagane
3	Uporządkować diagram klas	Sprawdzić, czy wszystkie istotne napisy są widoczne, np. nie zostały obcięte przez zbyt małe rozmiary symboli klas. Diagramy będą drukowane na drukarce monochromatycznej, nie należy więc nadużywać kolorów, w szczególności ciemnych kolorów wypełnienia; najlepiej wypełnienie ustawić na przezroczyste lub białe.	Zalecane
4	Wygenerować plik graficzny	Za pomocą używanego narzędzia wygenerować plik graficzny z diagramem, o nazwie bd2a##_I.***, gdzie ## jest numerem konta użytkownika w bazie Oracle, a *** rozszerzeniem odpowiadającym formatowi pliku. Narzędzie skonfigurować tak, by wygenerowany plik był niedużej wielkości, nieprzekraczającej 100 kB. Pliki o złych nazwach, zbyt duże lub w złym formacie będą odrzucane.	Wymagane

Wygenerowany plik należy obejrzeć przed wysłaniem, a zwłaszcza sprawdzić jego wielkość!

Odbiór etapu I

Prowadzący odbiór

Ten etap sprawdza doc. dr inż. Tomasz Traczyk.

Forma odbioru

Plik z diagramem należy przesłać listem elektronicznym jako załącznik.

Lp.	Czynność	Wskazówki	Ważność
1	Wynik etapu I przesłać listem elektronicznym	List wysłać na adres ttraczyk@ia.pw.edu.pl. List musi mieć temat: BD2A##, etap I. W treści listu należy umieścić: imię, nazwisko i nr albumu autora, numer i tytuł zadania oraz nazwę użytkownika Oracle.	Wymagane
2	Dołączyć plik	Dołączyć plik z diagramem jako załącznik do listu elektronicznego (nie pakować programami archiwizującymi).	Wymagane
3	Oczekiwać potwierdzenia	W przypadku braku potwierdzenia interweniować! (Uwaga: prowadzący nie pracuje po nocach ani w niedziele, a poczta jest usługą asynchroniczną bez gwarantowanego czasu dostawy, należy więc zachować spokój i zdrowy rozsądek, i nie ponawiać przesyłki po raptem kilku godzinach!)	Zalecane

Uwagi:

• Proszę dokładnie stosować się do zaleceń co do nazw plików i tytułów listów!
• Listy nie zawierające wymaganych informacji będą odrzucane.
• Wszelkie pytania proszę przesyłać w osobnych e-mailach. Prowadzący nie będzie odpowiadał na pytania zawarte w przesyłce wyników etapu.

Ocena i poprawianie etapu I

Etap I nie jest oceniany "na punkty", ale musi się koniecznie skończyć akceptacją koncepcji przez prowadzącego – bez takiej akceptacji nie można przystąpić do etapu II!

Jeśli pracę opatrzono adnotacją "Do poprawki", obowiązuje jak najszybsze poprawienie koncepcji i przesłanie do ponownego sprawdzenia. Przysługuje jedna poprawka (w szczególnych przypadkach dwie, o ile starczy czasu), przy czym prawo do poprawki jest uzależnione od terminowości przesłania wyniku danego "podejścia": prace spóźnione mogą nie być dopuszczone do poprawiania ze względu na brak czasu.

Forma odbioru poprawek

Plik z poprawionym diagramem klas należy przesłać w sposób analogiczny jak poprzednio, ale list powinien mieć temat: BD2A##, etap I - poprawka 1. W treści listu należy umieścić te same informacje, co przy pierwszym "podejściu"; plik z diagramem powinien zaś być nazwany odpowiednio bd2a##_Ip1.***.

Uwzględnienie uwag prowadzącego

W każdym przypadku uwagi prowadzącego muszą być uwzględnione w czasie realizacji etapu II. Jeśli jednak pracy nie opatrzono adnotacją "Do poprawki", poprawek nie należy osobno przesyłać.

Budowanie modelu ERD

Na tym etapie wykonać należy model związków encji dla problemu opisanego w zadaniu. Model ten należy doprowadzić do postaci gotowej do przekształcenia na struktury relacyjne (do modelu implementacyjnego wg terminologii przyjętej na wykładzie).

Szczegółowy model związków encji – wymagania

Model związków encji, uzyskany na końcu analizy szczegółowej, powinien mieć stopień szczegółowości umożliwiający przekształcenie do wstępnego projektu tabel za pomocą narzędzia.

Wymagania ogólne

Wyniki analizy powinny spełniać m.in. następujące wymagania:

Nazwa	Opis	Ważność
Zgodność z zadaniem	Model danych powinien odpowiadać treści zadania i pokrywać cały zakres zadania. Nie jest wskazane rozszerzające interpretowanie treści zadania.	Wymagane
Czytelność	Model musi być czytelny i łatwy do zrozumienia, co osiągnąć można m.in. przez stosowanie czytelnych nazw, zgodnych z terminologią użytą w zadaniu.	Wymagane
Stosowanie zaleceń projektowych	Tworząc model należy stosować się do zaleceń projektowych podanych na wykładzie.	Wymagane
Prawidłowe użycie narzędzia	Model należy stworzyć za pomocą narzędzia Oracle SQL Developer Data Modeler, właściwie wykorzystując możliwości tego narzędzia.	Wymagane

Artefakty

W wyniku analizy powinny zostać wytworzone następujące artefakty:

Nazwa	Opis	Ważność
Encje i atrybuty	Definicje wszystkich encji przewidzianych w systemie.	Wymagane
Właściwości encji	Określenie właściwości encji, w tym Name, Short Name, Preferred Abbreviation.	Wymagane
Atrybuty	Definicje wszystkich atrybutów wszystkich encji.	Wymagane
Podstawowe właściwości atrybutów	Pełne określenie podstawowych właściwości atrybutów, w tym: nazwa, typ i długości, opcjonalność	Wymagane
Związki	Definicje wszystkich związków.	Wymagane
Właściwości związków	Określenie właściwości związków, w tym stopnia i opcjonalności po obu stronach.	Wymagane
Nazwy związków	Związki nazwane (najlepiej obustronnie) w sposób umożliwiający zrozumienie ich znaczenia.	Zalecane
Identyfikatory	Definicje identyfikatorów, umożliwiające wytworzenie – w wyniku automatycznej transformacji – definicji odpowiednich kluczy.	Wymagane
Pierwotne unikalne identyfikatory	Pierwotny unikalny identyfikator (PUID) zdefiniowany dla każdej encji.	Wymagane
Wtórne unikalne identyfikatory	Wtórne unikalne identyfikatory zdefiniowane, jeśli dodatkowa kontrola niepowtarzalności jest potrzebna.	Zalecane
Dokumentacja	Elementy dokumentacji.	Zalecane
Dokumentacja encji i atrybutów	Opisy encji i atrybutów, stanowiące dokumentację zaprojektowanej struktury.	Zalecane

Szczegółowy model związków encji – instrukcja

Używane narzędzie jest dość nowe, mogą więc zdarzać się różne niespodzianki. Jeśli coś nie działa tak, jak można by się spodziewać, należy pilnie kontaktować się drogą e-mailową z prowadzącym.

Utworzenie diagramu ER

Uwaga: opis dotyczy konfiguracji narzędzia w laboratorium; jeśli ktoś używa narzędzia na własnym komputerze, powinien wykonywane czynności dostosować odpowiednio do lokalnego środowiska.

Lp.	Czynność	Wskazówki	Ważność
1	Wywołać narzędzie Oracle SQL Developer Data Modeler	Ze skopiowanego na pulpit (we wcześniejszym etapie) folderu wybrać ikonę programu Data Modeler i wywołać program. Jeśli w oknie programu nie pojawi się tzw. browser, czyli drzewo pokazujące składniki projektu, wybrać z menu View / Browser. Jeśli w prawej górnej części okna nie pojawi się obszar roboczy narzędzia do tworzenia diagramów ER, kliknąć prawym przyciskiem myszki na pozycji Logical w browserze i wybrać z lokalnego menu pozycję Show.	Wymagane
2	Zapisać nowy projekt	Wybrać File / Save i zapisać nowy projekt pod nazwą BD2A##, w katalogu w którym ma się prawa zapisu (np. na dysku Z:). Powstanie plik BD2A##.dmd oraz podkatalog BD2A## zawierający treść projektu.	Wymagane
3	Opisać diagram	Wybrać z paska narzędzi narzędzie do rysowania notatek (New note) i w lewym górnym rogu obszaru roboczego umieścić notatkę, o treści: ERD BD2A##, zadanie ## gdzie znaki ## należy zastąpić odpowiednimi numerami, w notatce tej należy też umieścić imię i nazwisko autora.	Wymagane
4	Zapisać diagram	Używając opcji File / Save zapisywać projekt co jakiś czas. Należy pamiętać o samodzielnym wykonywaniu kopii rezerwowych plików projektu!	Wymagane

Tworzenie modelu ERD

Czynności opisane w tej części należy wykonywać tak, by spełnić wymagania opisane wcześniej.

Lp.	Czynność	Wskazówki	Ważność
1	Tworzenie encji	Użyć przycisku Entity z paska narzędzi; nakreślić prostokąt w odpowiednim miejscu diagramu; podać nazwę encji i nazwę krótką, zaś w polu Preferred Abbreviation wpisać nazwę w liczbie mnogiej i bez polskich znaków (będzie ona użyta do nazwania tabeli relacyjnej powstałej na podstawie encji).	Wymagane
2	Tworzenie związków	Użyć odpowiedniego przycisku związku z paska narzędzi. Kliknąć w symbol encji po pierwszej, a potem po drugiej stronie związku (najpierw po stronie "jeden", potem po stronie "wiele"). W dialogu opisu związku wpisać nazwy związku i ustalić stopień oraz opcjonalność związku. Kliknąć na obszarze roboczym prawym przyciskiem myszki i włączyć opcję Show / Labels, by uwidocznić nazwy na diagramie.	Wymagane
3	"Prostowanie" związków	Kliknąć na obszarze roboczym prawym przyciskiem myszki i wybrać opcję Straighten Lines.	Zalecane
4	Uszczegółowienie encji	Dwukrotnie kliknąć w symbol encji. Użyć wywołanego dialogu do edycji właściwości encji i atrybutów oraz unikalnych identyfikatorów, zgodnie z wymaganiami podanymi powyżej. Dla atrybutów podać przybliżone typy danych i właściwe długości (użyć Datatype / Logical).	Wymagane
5	Tworzenie podtypów	W celu stworzenia podtypu utworzyć nową encję poza nadtypem, a następnie w polu Super Type wybrać nazwę odpowiedniej encji-nadtypu.	Opcjonalne
6	Dokumentacja	Opisy dla encji i atrybutów wpisywać w pola Comments in RDBMS. Wpisane tam teksty będą w przyszłości zapisane do bazy danych za pomocą wygenerowanych instrukcji SQL COMMENT ON.... W opisach nie należy używać słów encja czy atrybut, gdyż docelowo będą to opisy tabel i kolumn.	Zalecane

Sprawdzenie modelu ERD i przygotowanie go do wysyłki

Po zakończeniu tworzenia modelu ERD, a przed jego wysłaniem do oceny, należy model sprawdzić, analizując krytycznie narysowany diagram. Następnie należy uporządkować jego formę graficzną i przygotować pliki do wysyłki.

Lp.	Czynność	Wskazówki	Ważność
1	Zweryfikować diagram ERD	Sprawdzić diagram ERD pod względem kompletności, czytelności, poprawności nazw itp.	Zalecane
2	Uporządkować formę graficzną raportu	Dopilnować, by wszystkie napisy były widoczne. Przesunąć elementy diagramu jak najbliżej górnej i lewej krawędzi i ustawić je tak, by proporcje rysunku przypominały proporcje pionowo ustawionej kartki papieru formatu A4. Notatkę z danymi autora i zadania pozostawić w lewym górnym rogu.	Wymagane
3	Wygenerować plik z diagramem w konwencji Barkera	Za pomocą opcji File / Print Diagram / To Image File zapisać diagram w formacie PNG. Plik nazwać BD2A##_ERD.PNG. Obejrzeć wygenerowany rysunek, w szczególności sprawdzić, czy nie ma on zbyt dużych marginesów przy górnej i lewej krawędzi i czy da się dobrze wydrukować na pionowo ustawionej kartce papieru.	Wymagane
4	Wygenerować plik z pomocniczą postacią diagramu	Kliknąć w obszar roboczy prawym przyciskiem myszki i włączyć opcję Bachman Notation. Sprawdzić czy wszystkie napisy są widoczne w całości (w szczególności typy danych), ewentualnie zmienić rozmiary symboli (można użyć opcji Resize Objects to Visible). Za pomocą opcji File / Print Diagram / To Image File zapisać diagram w formacie PNG. Plik nazwać BD2A##_DT.PNG. Obejrzeć wygenerowany rysunek. Po wygenerowaniu pliku przełączyć narzędzie z powrotem na notację Barkera.	Wymagane

Odbiór etapu II

Prowadzący odbiór

Modele ERD sprawdza doc. dr inż. Tomasz Traczyk.

Forma odbioru

Pliki z wynikami należy przesłać na adres ttraczyk@ia.pw.edu.pl jako załączniki do listu elektronicznego. List powinien mieć temat: BD2A##, etap II.

W treści listu należy umieścić:

• imię i nazwisko,
• numer i tytuł zadania.

Lp.	Czynność	Wskazówki	Ważność
1	Wysłać pliki (rysunki PNG) na wyżej podany adres	Wypisać w liście wymagane informacje (patrz wyżej). Dołączyć pliki jako załączniki do listu elektronicznego (nie pakować programami archiwizującymi). List wysłać z oficjalnego studenckiego konta e-mailowego.	Wymagane
2	Oczekiwać potwierdzenia	W przypadku braku potwierdzenia interweniować! (Uwaga: prowadzący nie pracuje po nocach ani w niedziele, a poczta jest usługą asynchroniczną bez gwarantowanego czasu dostawy, należy więc zachować spokój i zdrowy rozsądek, i nie ponawiać przesyłki po raptem kilku godzinach!)	Zalecane

Uwagi:

• Ewentualne pytania proszę wysyłać w osobnych listach na adres prowadzącego.
• Proszę dokładnie stosować się do zaleceń co do nazw plików i tytułów listów!
• Listy nie zawierające wymaganych informacji będą odrzucane.
• Listy przesłane z obcych serwerów pocztowych nie będą odbierane.
• Wszelkie pytania proszę przesyłać w osobnych e-mailach. Prowadzący nie będzie odpowiadał na pytania zawarte w przesyłce wyników etapu.

Ocena i poprawianie etapu II

Z etapu II można otrzymać do 20 punktów (na 40 punktów z całego projektu), po 10 dla kategorii: Z – zgodność z zadaniem, P – poprawność modelu ER.

Jeśli pracę opatrzono adnotacją "Do poprawki" lub podobną, obowiązuje niezwłoczne jej poprawienie i przekazanie pracy do ponownego sprawdzenia. Przysługuje jedna poprawka (w wyjątkowych przypadkach dwie), przy czym prawo do poprawek jest uzależnione od terminowego przekazania pierwszego "podejścia" do etapu.

Forma odbioru poprawek

Pliki z poprawionymi wynikami należy przesłać na adres ttraczyk@ia.pw.edu.pl jako załączniki do listu elektronicznego. List powinien mieć temat: BD2A##, etap II - poprawka.
W treści listu należy umieścić te same informacje, co przy pierwszym "podejściu".

Uwzględnienie uwag prowadzącego

W każdym przypadku uwagi prowadzącego muszą być uwzględnione w projekcie przed przystąpieniem do etapu III (ale, jeśli pracy nie opatrzono adnotacją "Do poprawki", rezultatu tych poprawek nie należy osobno przesyłać). Ocena prawidłowości uwzględnienia tych uwag stanowić będzie część punktacji za etap III.

Projekt struktur danych

Projekt struktur danych – wymagania

Jak założono poprzednio, model związków encji, uzyskany na końcu analizy szczegółowej, powinien mieć stopień szczegółowości umożliwiający przekształcenie do wstępnego projektu tabel za pomocą narzędzia. Projektowanie polegać zatem będzie na użyciu tego narzędzia, a następnie na weryfikacji i udoskonaleniu wyników jego działania.

Wymagania ogólne

Nazwa	Opis	Ważność
Uwzględnienie zaleceń oceniającego analizę	Przed przystąpieniem do tego etapu należy model związków encji zmodyfikować tak, by uwzględniał on zalecenia sprawdzającego. Skuteczność tej poprawy stanowi część oceny etapu!	Wymagane
Projekt dostosowany do wybranego DBMS	Szczegóły projektu mają być dostosowane do użytego DBMS Oracle. W szczególności dotyczy to typów danych (należy zastosować odpowiednio własne typy Oracle, a nie typy ze standardu SQL; w szczególności w Oracle nie ma typu INTEGER, a typ NUMBER bez podanej precyzji jest zmiennoprzecinkowy!) oraz nazw obiektów (np. nie mogą przekraczać 30 znaków ani zawierać spacji, nie powinny zawierać znaków narodowych). Ta zasada dotyczy także nazw ograniczeń (kluczy głównych, unikalnych, obcych i ograniczeń check)!	Wymagane
Czytelność	Model musi być czytelny i łatwy do zrozumienia, co osiągnąć można m.in. przez stosowanie czytelnych nazw i zwięzłych opisów.	Wymagane
Stosowanie zaleceń projektowych	Tworząc projekt należy stosować się do zaleceń projektowych podanych na wykładzie.	Wymagane
Prawidłowe użycie narzędzia	Model należy stworzyć za pomocą narzędzia Oracle SQL Developer Data Modeler, właściwie wykorzystując wybrane możliwości tego narzędzia.	Wymagane

Artefakty

W wyniku projektowania powinny zostać wytworzone następujące artefakty:

Nazwa	Opis	Ważność
Projekt tabel i więzów	Definicje wszystkich potrzebnych tabel.	Wymagane
Tabele	Definicje tabel i określenie ich właściwości: nazwa, skrót nazwy.	Wymagane
Kolumny	Definicje wszystkich kolumn i określenie ich właściwości: nazwa, typ danych i długość (ew. skala i precyzja liczby), opcjonalność/obowiązkowość, ew. wartość domyślna, ew. ograniczenie check dla kolumny i/lub wartości dopuszczalne.	Wymagane
Więzy primary key	Definicje PK dla każdej z tabel: nazwa, kolumny składowe (w odpowiedniej kolejności!).	Wymagane
Więzy unique key	Definicje dodatkowych UK: nazwa, kolumny składowe (w odpowiedniej kolejności!).	Zalecane
Więzy foreign key	Definicje potrzebnych FK: nazwa, kolumny składowe (w kolejności zgodnej z odpowiednim PK), modyfikowalność, przenaszalność (transferowalność), ew. przynależność do łuku.	Wymagane
Więzy check	Definicje więzów check – jeśli potrzebne (np. do walidacji łuków, wymuszenia wielkich liter itp.): nazwa, warunek.	Zalecane
Obiekty pomocnicze tabel	Definicje obiektów podrzędnych dla wszystkich tabel.	Wymagane
Indeksy	Definicje niezbędnych indeksów, np. na klucze obce: nazwa, unikalność, lista kolumn (w odpowiedniej kolejności). Indeksy nie powinny się dublować!	Wymagane
Elementy bezpieczeństwa	Tworzenie praw dla użytkowników.	Wymagane
Użytkownicy	Definicja użytkownika BD2A##_APP – użytkownika "końcowego" korzystającego z danych.	Wymagane
Prawa dostępu do tabel	Określenie praw dostępu do tabel dla użytkownika "końcowego".	Wymagane
Komentarze do tabel i kolumn	Krótkie opisy tabel i kolumn we właściwości Comment in RDBMS.	Zalecane

Projekt struktur danych – instrukcja

Czynności projektowe – o ile nie napisano inaczej – wykonywane będą za pomocą narzędzia Data Modeler.

Utworzenie modelu relacyjnego

Lp.	Czynność	Wskazówki	Ważność
1	Utworzenie modelu relacyjnego	Za pomocą opcji Design/Engineer to Relational Model utworzyć wstępną wersję modelu tabel.	Wymagane
2	Opisanie diagramu	Przejść do diagramu modelu relacyjnego. Wybrać z paska narzędzi narzędzie do rysowania notatek (New note) i w lewym górnym rogu obszaru roboczego umieścić notatkę, o treści: BD2A##, zadanie ## gdzie znaki ## należy zastąpić odpowiednimi numerami. W notatce tej należy też umieścić imię i nazwisko autora.	Wymagane
3	Zapisywanie projektu	Używając opcji File / Save zapisywać projekt co jakiś czas. Należy pamiętać o samodzielnym wykonywaniu kopii rezerwowych plików projektu!	Wymagane

Weryfikacja i udoskonalanie projektu

Za pomocą Data Modelera należy przejrzeć, zweryfikować i poprawić projekt, tak by spełnił on podane wyżej wymagania i zalecenia projektowe nauczane na wykładzie. Wybrane szczegóły opisano poniżej. W szczególności należy zwrócić uwagę na poprawność nazw obiektów i typów danych, i dokonać niezbędnych poprawek.

Lp.	Czynność	Wskazówki	Ważność
1	Edycja właściwości kolumn	Podwójne kliknięcie na nazwie kolumny w nawigatorze powoduje otwarcie dialogu właściwości kolumny. Można tam zdefiniować m.in. wartość domyślną oraz listę wartości dopuszczalnych.	Wymagane
2	Dodawanie indeksów	Używając dialogu właściwości tabeli należy dodać indeksy dla kluczy obcych. Nie projektować osobno indeksów dla kluczy głównych i unikalnych. Dopilnować, by indeksy się nie dublowały, tzn. by żaden z kluczy indeksowania (włączając PK i UK!) nie był równy początkowej części innego.	Wymagane
3	Przenaszalność związków i kaskada kasowania	Jeśli któryś ze związków powinien być nieprzenaszalny, należy wyłączyć właściwość Transferable odpowiedniego klucza obcego. W celu utworzenia klucza obcego z klauzulą ON DELETE CASCADE należy zmienić właściwość Delete Rule klucza na CASCADE.	Zalecane

Elementy projektowania fizycznego

Do poprawionego modelu relacyjnego należy utworzyć "model fizyczny" i w nim zapisać pozostałe decyzje projektowe.

Lp.	Czynność	Wskazówki	Ważność
1	Utworzyć "model fizyczny"	Na węźle Physical Model nawigatora kliknąć prawym przyciskiem myszki i wybrać New, z listy wybrać Oracle Database 11g. (Uwaga: utworzony model otwiera się klikając na jego nazwie prawym przyciskiem myszki i wybierając Open.)	Wymagane
2	Utworzyć definicję użytkownika "końcowego"	W węźle Physical Model wybrać pozycję Users i utworzyć definicję użytkownika o nazwie BD2A##_APP.	Wymagane
3	Przyznawanie praw dostępu do tabel	W "modelu fizycznym" otworzyć dialog właściwości dla każdej z tabel i używając przycisku Permissions utworzyć prawa dostępu dla użytkownika BD2A##_APP: Select, Insert, Update i Delete.	Wymagane
4	Ustawienie możliwości odroczenia walidacji więzów	W "modelu fizycznym" dla każdej z tabel wybrać po kolei klucze obce i dla każdego z nich ustawić właściwość Deferrable na Yes.	Zalecane

Generowanie struktur danych

Generowanie struktur danych – wymagania

Artefakty

W tej fazie projektu powinny zostać wytworzone następujące artefakty:

Nazwa	Opis	Ważność
Skrypt tworzący struktury danych	Skrypt tworzący tabele wraz z ograniczeniami i indeksy oraz nadający uprawnienia do obiektów.	Wymagane
Struktury utworzone w bazie danych	Struktury utworzone w bazie danych przez wykonanie wygenerowanych skryptów.	Wymagane

Generowanie struktur danych – instrukcja

Na podstawie projektu należy wygenerować skrypt tworzący obiekty. Skrypt ten należy przejrzeć! Jeśli stwierdzi się w nim usterki, należy poprawić projekt struktur i ponowić generację. Następnie należy uruchomić skrypt i utworzyć struktury w bazie danych.

Generowanie struktur danych

Lp.	Czynność	Wskazówki	Ważność
1	Generowanie skryptu DDL	Za pomocą opcji Generate DDL narzędzia Data Modeler (przycisk z symbolem walca, na pasku narzędzi po prawej stronie) wygenerować skrypt DDL; sprawdzić w zakładce Tables, czy wybrane są wszystkie zaprojektowane tabele. Skrypt starannie przejrzeć. Jeśli jest OK, używając przycisku Save zapisać skrypt pod nazwą bd2a##_ddl.sql.	Wymagane
2	Wykonać skrypt	Używając programu SQL*Plus wykonać jako użytkownik BD2A## wygenerowany skrypt bd2a##_ddl.sql. Instrukcja tworzenia użytkownika powinna spowodować błąd (użytkownik jest już utworzony przez administratora), pozostałe instrukcje powinny się wykonać bezbłędnie. W razie wystąpienia błędów usunąć (DROP) utworzone obiekty, dokonać poprawek w projekcie i powtórzyć kolejne czynności.	Wymagane

Sprawdzenie wyników etapu III i przygotowanie ich do wysyłki

Po zakończeniu tworzenia struktur danych, a przed wysłaniem ich do oceny, należy sprawdzić jego poprawność, analizując krytycznie wygenerowany skrypt i struktury w bazie danych. Następnie należy uporządkować jego formę graficzną i przygotować pliki do wysyłki.

Lp.	Czynność	Wskazówki	Ważność
1	Krytycznie obejrzeć wyniki w bazie danych	Za pomocą programu Oracle SQL*Developer obejrzeć utworzone w bazie struktury. Zwrócić szczególną uwagę na poprawność nazw, typów danych, więzów integralności oraz indeksów. Uwaga: sprawdzający projekt będzie oceniał struktury oglądając je właśnie w bazie danych.	Zalecane
2	Uporządkować formę graficzną diagramu modelu relacyjnego	Dopilnować, by wszystkie napisy były widoczne. Przesunąć elementy diagramu jak najbliżej górnej i lewej krawędzi i ustawić je tak, by proporcje rysunku przypominały proporcje pionowo ustawionej kartki papieru formatu A4. Notatkę z danymi autora i zadania pozostawić w lewym górnym rogu.	Wymagane
3	Wygenerować plik z diagramem modelu relacyjnego	Za pomocą opcji File / Print Diagram / To Image File zapisać diagram w formacie PNG. Plik nazwać bd2a##_rel.png. Obejrzeć wygenerowany rysunek, w szczególności sprawdzić, czy nie ma on zbyt dużych marginesów przy górnej i lewej krawędzi i czy da się dobrze wydrukować na pionowo ustawionej kartce papieru.	Wymagane

Odbiór etapu III

Prowadzący odbiór

Model struktur danych sprawdza doc. dr inż. Tomasz Traczyk.

Treść odbioru

Do odbioru należy przedstawić:

• diagram struktury danych w postaci pliku PNG;
• wygenerowany skrypt DDL;
• struktury utworzone w bazie danych.

Forma odbioru

Pliki z wynikami należy przesłać na adres ttraczyk@ia.pw.edu.pl jako załączniki do listu elektronicznego. List powinien mieć temat: BD2A##, etap III.

W treści listu należy umieścić:

• imię, nazwisko i nr albumu studenta,
• numer i tytuł zadania,
• nazwę i hasło użytkownika Oracle.

Lp.	Czynność	Wskazówki	Ważność
1	Wysłać pliki na wyżej podany adres	Wypisać w liście wymagane informacje (patrz wyżej). Dołączyć pliki jako załączniki do listu elektronicznego (nie pakować za pomocą programu archiwizującego).	Wymagane
2	Oczekiwać potwierdzenia	W przypadku braku potwierdzenia interweniować (po rozsądnym czasie)!	Zalecane

Uwagi:

• Prowadzący będzie oceniał utworzone w bazie struktury. Należy więc pozostawić tam odpowiednią zawartość.
• Proszę dokładnie stosować się do zaleceń co do nazw plików i tytułów listów!
• Listy nie zawierające wymaganych informacji będą odrzucane.
• Wszelkie pytania proszę przesyłać w osobnych e-mailach. Prowadzący nie będzie odpowiadał na pytania zawarte w przesyłce wyników etapu.

Ocena i poprawianie etapu III

Z etapu III można otrzymać do 10 punktów. Na ocenę tę istotnie wpływa poprawność uwzględnienia uwag do etapu II.

Nie jest przewidywane osobne poprawianie etapu III. Uwagi prowadzącego muszą jednak być uwzględnione przed przystąpieniem do etapu IV, pod rygorem niezaliczenia całego projektu! Ocena prawidłowości uwzględnienia tych uwag stanowić będzie ważny element oceny etapu IV.

Poprawianie struktur i dane testowe

Zaprojektowaną strukturę danych należy poprawić w narzędziu Data Modeler i wygenerować ponownie, a następnie wypełnić danymi testowymi.

Poprawianie struktur

Poprawianie struktur – wymagania

W tej fazie projektu powinny zostać wytworzone następujące artefakty:

Nazwa	Opis	Ważność
Poprawione struktury w bazie danych	Struktury danych poprawione wg wskazówek prowadzącego.	Wymagane

Poprawianie struktur – instrukcja

Jeśli struktury danych wymagają poprawienia, należy je usunąć z bazy danych, poprawić ich definicje i wygenerować je ponownie.

Lp.	Czynność	Wskazówki	Ważność
1	Usunięcie struktur z bazy danych	Usunąć struktury za pomocą odpowiednich instrukcji SQL DROP lub za pomocą narzędzia SQL Developer.	Wymagane
2	Poprawienie definicji	Definicje tabel, więzów i indeksów poprawić w narzędziu Data Modeler, wykonując czynności jak w poprzednim etapie.	Wymagane
3	Utworzenie struktur w bazie danych	Wygenerować skrypty tworzące struktury danych i utworzyć te struktury w bazie, wykonując czynności jak w poprzednim etapie.	Wymagane

Dane testowe

Dane testowe – wymagania

W tej fazie projektu powinny zostać wytworzone następujące artefakty:

Nazwa	Opis	Ważność
Dane testowe	Dane testowe wpisane w utworzone struktury w bazie danych.	Wymagane
Skrypt tworzący dane testowe	Skrypt zawierający instrukcje INSERT, tworzące dane testowe. Uwaga: dla danych typu data i/lub czas użyć jawnych funkcji konwersji (np. TO_DATE), a nie formatu domyślnego. Pamiętać o instrukcji COMMIT!	Wymagane
Dane testowe w bazie	Sensowne (choć raczej nieliczne) dane testowe umieszczone w bazie.	Wymagane

Dane testowe – wymagania

Należy utworzyć sensowne dane testowe.

Lp.	Czynność	Wskazówki	Ważność
1	Napisać skrypt tworzący dane testowe	Za pomocą dowolnego edytora tekstowego utworzyć skrypt o nazwie BD2A##_DANE.SQL, zawierający zdania INSERT tworzące dane testowe. Skrypt ten wykonać za pomocą programu SQL*Plus jako użytkownik BD2A##.	Wymagane

Elementy uzupełniające strukturę danych

Do zaprojektowanej struktury danych można stworzyć dodatkowe elementy uzupełniające, takie jak sekwencje, wyzwalacze i perspektywy.

Uzupełnianie struktury danych

Celem jest uzupełnienie struktury danych o mechanizmy automatycznego wypełniania kluczy sztucznych, ograniczenia proceduralne, zabezpieczenia dostępu itp.

Elementy uzupełniające strukturę – wymagania

W tej fazie projektu powinny zostać wytworzone następujące artefakty:

Nazwa	Opis	Ważność
Synonimy	Definicje synonimów w narzędziu Data Modeler i synonimy utworzone w bazie danych.	Wymagane
Sekwencje	Definicje sekwencji w narzędziu Data Modeler i sekwencje utworzone w bazie danych.	Zalecane
Wyzwalacze	Definicje wyzwalaczy w narzędziu Data Modeler i wyzwalacze utworzone w bazie danych.	Zalecane
Wyzwalacze wypełniające sztuczne klucze główne	Wyzwalacze podstawiające wartości z odpowiednich sekwencji do kolumn sztucznych kluczy głównych.	Zalecane
Inne wyzwalacze	Wyzwalacze realizujące inne funkcje, np. ograniczenia proceduralne. Uwaga: proszę nie przesadzać, a w szczególności proszę zwrócić uwagę na to, by za pomocą wyzwalaczy nie realizować funkcjonalności, które daje się osiągnąć za pomocą ograniczeń deklaratywnych i/lub odpowiednio zaprojektowanej struktury danych.	Opcjonalne
Komentarze do programów	Kod elementów proceduralnych (np. wyzwalaczy) wyczerpująco skomentowany, w tym podany cel tworzenia danego elementu.	Zalecane
Perspektywy	Definicje perspektyw, np. ograniczających dostęp do danych użytkownikowi BD2A##_APP, w narzędziu Data Modeler i utworzone w bazie danych.	Opcjonalne

Elementy uzupełniające strukturę – instrukcja

Elementy uzupełniające należy zaprojektować w narzędziu Data Modeler, a następnie wygenerować skrypty tworzące je w bazie danych.

Lp.	Czynność	Wskazówki	Ważność
1	Otworzyć "model fizyczny"	Kliknąć prawym przyciskiem myszki w węzeł Physical Models i wybrać Open.	Wymagane
2	Utworzyć definicję użytkownika – właściciela obiektów	Wybrać węzeł Users i utworzyć definicję użytkownika o nazwie BD2A##.	Wymagane
3	Zdefiniować synonimy dla użytkownika nieuprzywilejowanego	W węźle Synonyms utworzyć synonimy dla wszystkich tabel (i ewentualnie perspektyw) projektu. Synonim nazwać tak samo, jak nazywa się wskazywany obiekt, w polu User wybrać użytkownika BD2A##_APP, w polu Object Owner wpisać BD2A##, zaś w polu Public pozostawić wartość No.	Wymagane
4	Wygenerować skrypt tworzący elementy uzupełniające	Za pomocą opcji Generate DDL narzędzia Data Modeler (przycisk z symbolem walca, na pasku narzędzi po prawej stronie) wygenerować skrypt DDL: po wciśnięciu przycisku Generate zgasić zaznaczenie na najwyższym poziomie drzewa (przy Oracle Database...). Następnie na dole dialogu wybrać zakładkę Synonyms i na niej zaznaczyć wszystkie stworzone synonimy. Podobnie postąpić dla innych typów utworzonych elementów uzupełniających. Wygenerować skrypt, a następnie starannie go przejrzeć. Jeśli jest OK, używając przycisku Save zapisać skrypt pod nazwą bd2a##_syn.sql.	Wymagane
5	Wykonać skrypt	Używając programu SQL*Plus wykonać jako użytkownik BD2A##_APP wygenerowany skrypt bd2a##_syn.sql. Uwaga: pamiętać o tym, że użytkownik ten ma osobne hasło, jeśli więc go nie zmieniono, to jest ono takie, jak hasło początkowe użytkownika BD2A##!	Wymagane
6	Zaprojektować inne rodzaje elementów uzupełniających struktury danych	W odpowiednich węzłach "modelu fizycznego" utworzyć i odpowiednio zdefiniować sekwencje, wyzwalacze itp.	Zalecane
7	Wygenerować skrypt tworzący elementy uzupełniające	Za pomocą opcji Generate DDL narzędzia Data Modeler (przycisk z symbolem walca, na pasku narzędzi po prawej stronie) wygenerować skrypt DDL: po wciśnięciu przycisku Generate zgasić zaznaczenie na najwyższym poziomie drzewa (przy Oracle Database...). Następnie na dole dialogu wybrać zakładkę Synonyms i na niej sprawdzić, czy wyłączone jest zaznaczenie wszystkich synonimów. Dla innych typów utworzonych elementów uzupełniających wybrać odpowiednie zakładki i włączyć zaznaczenia. Wygenerować skrypt, a następnie starannie go przejrzeć. Jeśli jest OK, używając przycisku Save zapisać skrypt pod nazwą bd2a##_add.sql.	Zalecane
8	Wykonać skrypt	Używając programu SQL*Plus wykonać jako użytkownik BD2A## wygenerowany skrypt bd2a##_add.sql. Wynik tego działania obejrzeć za pomocą programu SQL Developer.	Wymagane

Testowanie struktur danych

Zaprojektowaną i wypełnioną danymi strukturę danych należy przetestować za pomocą odpowiednio skonstruowanych zdań SQL, realizujących zadawanie zapytań i próby naruszania więzów.

Testy struktury danych

Celem jest przetestowanie zaprojektowanej struktury danych, a w szczególności ograniczeń integralności.

Testy struktury danych – wymagania

Należy wypróbować struktury przez zadawanie zapytań i próby naruszania więzów.

Nazwa	Opis	Ważność
Zapytania testowe	Dające się wykonać na danych testowych sensowne zapytania SELECT (kilka), nawiązujące do treści zadania.	Wymagane
Testy ograniczeń	Zdania DML (INSERT, UPDATE, DELETE) testujące skuteczność wybranych więzów integralności.	Wymagane

Testy struktury danych – instrukcja

Lp.	Czynność	Wskazówki	Ważność
1	Przetestować dane testowe za pomocą zapytań	Utworzyć skrypt o nazwie BD2A##_TEST.SQL, zawierający zdania SELECT testujące dane. Zdania te powinny nawiązywać do treści zadania. Na początku skryptu umieścić dyrektywy: set echo on set linesize 300 set trimspool on set pagesize 500 spool BD2A##_TEST.LIS zaś na końcu dyrektywę: spool off Skrypt ten wykonać za pomocą programu SQL*Plus jako użytkownik BD2A##.	Wymagane
2	Napisać zdania DML testujące ograniczenia	Napisać skrypt o nazwie BD2A##_DML.SQL, zawierający zdania DML testujące działanie wybranych ograniczeń. Na początku skryptu umieścić dyrektywę spool BD2A##_DML.LIS, zaś na końcu dyrektywę spool off. Skrypt ten wykonać za pomocą programu SQL*Plus jako użytkownik BD2A##.	Wymagane
3	Testować dostęp przez synonimy	Skrypt BD2A##_TEST.SQL wykonać za pomocą programu SQL*Plus jako użytkownik BD2A##_APP i zaobserwować wyniki. Działanie powinno być identyczne, jak dla użytkownika BD2A##, tj. wszystkie zapytania powinny się wykonać poprawnie.	Zalecane

Odbiór etapu IV

Prowadzący odbiór

Wyniki etapu IV sprawdza doc. dr inż. Tomasz Traczyk.

Treść odbioru

Do odbioru należy przedstawić umieszczone w bazie danych poprawione struktury danych, elementy uzupełniające oraz dane testowe. Przesłać należy testujące je zdania SQL wraz z wynikami testów.

Forma odbioru

Pliki z wynikami należy przesłać na adres ttraczyk@ia.pw.edu.pl jako załącznik do listu elektronicznego. List powinien mieć temat: BD2A##, etap IV.

W treści listu należy umieścić:

• imię, nazwisko i nr albumu studenta,
• numer i tytuł zadania,
• nazwy i hasła użytkowników Oracle BD2A## i BD2A##_APP.

Lp.	Czynność	Wskazówki	Ważność
1	Wysłać pliki na wyżej podany adres	Wypisać w liście wymagane informacje (patrz wyżej). Dołączyć pliki .SQL i .LIS jako załączniki do listu elektronicznego. Nie pakować plików programem pakującym!	Wymagane
2	Oczekiwać potwierdzenia	W przypadku braku potwierdzenia interweniować!	Zalecane

Uwagi:

• Listy nie zawierające wymaganych informacji będą odrzucane.
• Wszelkie pytania proszę przesyłać w osobnych e-mailach. Prowadzący nie będzie odpowiadał na pytania zawarte w przesyłce wyników etapu.

Ocena i poprawianie etapu IV

Z etapu IV można otrzymać do 10 punktów. Na ocenę tę istotnie wpływa poprawność uwzględnienia uwag prowadzącego do wyników etapu III. Ze względu na kończący się semestr nie ma możliwości poprawiania etapu IV.