Żewłakw Tmasz Wś Krzysztf Bazy Danych 2 Semestr 2011L System zarządzania treścią. 0. Etap 0: Słwny pis prjektu. System zarządzania treścią. Aplikacja umżliwiająca łatwą aktualizację i edycję strn tekstwych serwisu za pmcą wizualneg edytra treści (umżliwia t wygdne twrzenie i frmatwanie dkumentów bez znajmści HTMLa) raz publikację tych treści w internecie. Zarządzanie treścią serwisu dbywa się pprzez wygdny panel dstępny z pzimu strny www, który jest dstępny wyłącznie dla użytkwników psiadających dpwiednie uprawnienia. Użytkwnicy w systemie są pdzieleni na rle z uwagi na zakres prac. Administratr p zalgwaniu się d systemu, mże każdemu zarejestrwanych użytkwników nadad dpwiedni stpie uprawnie. Aplikacja zstanie wyknana w technlgii PHP z użyciem bazy danych PstgreSQL. Szkielet aplikacji będzie party framewrk ZendFramewrk. 1. Etap 1: Prjekt bazy danych. 1.1. Diagram ER.
1.2. Opis związków na diagramie ER. 1.3. Opis encji.
1.4. Analiza wymagań funkcjnalnych i niefunkcjnalnych. Wymagania funkcjnalne ID Nazwa Opis Prirytet 1. Autryzacja użytkwników użytkwnik mże się zalgwad za pmcą 1 indywidualneg lginu raz hasła. P zalgwaniu użytkwnik w zależnści d typu knta zyskuje dpwiednie uprawnienia d zarządzania treścią. 2. Zarządzanie użytkwnikami mżliwśd twrzenia użytkwników 2 uprawinych d edycji zasbów serwisu 3 pzimy uprawnie 3. Mżliwśd publikwania, użytkwnik mże ddawad własne 1 edycji i usuwania własnych treści kmentarze, redaktr pnadt mże ddawad własne psty, natmiast administratr ma mżliwśd ddawania strn. 4. Wizualny edytr treści mżliwśd wizualnej edycji treści za pmcą 3 edytra typu WYSIWYG. 5. Filtracja kmentarzy kmentarze niezalgwanych 2 użytkwników muszą zstad zatwierdzne przez administratra/redaktra przed publikwaniem. 6. Lgwanie akcji wszystkie akcje wyknywane na strnie są 3 lgwane w bazie danych. 7. Knfiguracja ustawie system umżliwia zmianę knfiguracji w zależnści d platfrmy na jakiej jest uruchminy 1 Wymagania niefunkcjnalne Bezpieczestw system musi zapewnid bezpieczestw użytkwników nikt nie mże mied bezpśrednieg dstępu d ich danych w bazie p za kierwnikiem instytutu raz administratrem. Niezawdnśd system pwinien byd dstępny ciągle raz zapewniad spójnśd wprwadzanych danych. Wysce niepżądane są pmyłki we wprwadzaniu tematu pracy. Przyjazny interfejs aplikacja pwinna byd łatwa w użytku, przejrzysta raz estetycznie wyglądająca. Intuicyjnśd bsługi jest bardz pżądana. System pmcy system pwinien byd wypsażny w kmentarze przy każdym z pól wybru. Mżliwśd rzwju systemu pwinna byd mżliwśd dpisywania nwych mdułów, raz zmiany wyglądu.
1.5. Diagram lgiczny. 1.6. Skrypt DDL. W sbnym pliku: baza.sql
2. Etap 2: Prjekt aplikacji. 2.1. Hierarchia menu. Administracja Kategrie Przeglądaj Edytuj Usu Ddaj Strny Przeglądaj Edytuj Usu Ddaj Psty Przeglądaj Edytuj Usu Ddaj Przeglądaj kmentarze Usu Kmentarz Użytkwnicy Przeglądaj Edytuj Usu Ddaj Strna Psty Przeglądaj Kmentuj Strny Przeglądaj 2.2. Szkielet aplikacji. Psty mduł umżliwiający wyświetlanie, ddawanie, edycję raz usuwanie pstów wyświetlanych później na strnie głównej. Strny mduł umżliwiający wyświetlanie, ddawanie, edycję raz usuwanie strn infrmacyjnych. Użytkwnicy mduł bsługujący rejestrację, lgwanie raz zarządzanie kntem użytkwników raz nadawanie im dpwiednich uprawnie dstępu d panelu zarządzania treścią. Kmentarze mduł umżliwiający ddawanie kmentarzy, wstępną mderację raz umżliwiający usuwanie kmentarzy. Lgi mduł umżliwiający przeglądanie w czytelnej frmie lgów z działa pdczas użytkwania aplikacji. Opcje mduł umżliwiający dstswywanie pcji działania aplikacji d własnych preferencji.
2.3. Pdział realizacji funkcjnalnści między strnę serwera i klienta. Klient Wyświetlanie pstów, mżliwśd ich edycji raz usunięcia, Mżliwśd kmentwania pstów raz ich mderacji, Obsługa edycji, mdyfikacji raz ddawania pstów, strn i użytkwników. Wstępna walidacja wprwadzanych danych, Wyświetlanie przyjazneg interfejsu. Serwer Pbieranie, edycja raz usuwanie rekrdów w bazie danych zarządzanie bazą danych, Obsługa sesji użytkwnika, Pełna walidacja danych, Obsługa żąda danych. Lgwanie zdarze i akcji. 2.4. Spsób realizacji wymuszania integralnści danych. W tabelach zstały pdefiniwane pwiązania na bazie kluczy bcych. Ddając wartści d tabeli, w przypadku tabeli z kluczami bcymi, schemat bazy wymusza na nas ddawanie wartści jedynie zgdnych. Ddatkw tabele płączne danym kluczem bcym są w tych samych mmentach usuwane. Przykładw, ddając pst d kategrii musimy wybrad jedną z aktualnie zdefiniwanych. Natmiast jeśli usuwamy kategrię, również wszystkie wpisy z kategrii są usuwane. 2.5. Indeksy w bazie danych. Indeksy zstały nałżne w celu szybszeg wyszukiwania infrmacji w tabelach. Znajdują się ne na następujących plach: categries.id cmment_status.id cmments.id lgs.id ptins.name pages.id psts.id priviliges.id publish_statuses.id users.id
2.6. GUI.
3. Etap 3: Implementacja. 3.1. Aplikacja. Dstępna pd adresem http://prjekty.ws.in/bd/ 3.2. Prcedury wbudwane i triggery. FUNKCJE Funkcja usuwająca kmentarze zawierające dane słw CREATE OR REPLACE FUNCTION delcmmentwithwrd(slw character) RETURNS blean AS BEGIN --INSERT INTO user_cnnectin_data (ip, user_id) VALUES (_ip, _user_id); DELETE FROM cmments WHERE cntent LIKE '%' slw '%'; IF FOUND THEN RETURN true; ELSE RETURN false; END IF; END; LANGUAGE plpgsql VOLATILE COST 100; Funkcja zliczająca ilść pstów i strn stwrznych przez użytkwnika. CREATE OR REPLACE FUNCTION getcunt() RETURNS numeric AS DECLARE cunter NUMERIC(5,0); tmp NUMERIC(5,0); BEGIN SELECT COUNT(*) INTO cunter FROM psts; SELECT COUNT(*) INTO tmp FROM pages; cunter := cunter + tmp; RETURN (cunter) ; END; LANGUAGE plpgsql VOLATILE COST 100;
Funkcja zliczająca punkty użytkwnika CREATE OR REPLACE FUNCTION getpints(userid numeric) RETURNS numeric AS DECLARE pints NUMERIC(5,0); tmp_pints NUMERIC(5,0); BEGIN SELECT COUNT(*) INTO pints FROM psts WHERE "authr" = USERID; pints := pints * 3; SELECT COUNT(*) INTO tmp_pints FROM pages WHERE "authr" = USERID; tmp_pints := tmp_pints * 4; pints := pints + tmp_pints; RETURN (pints) ; END; LANGUAGE plpgsql VOLATILE COST 100; Triggery Trigger ustawiający dmyślną kategrię dla pstów z usuwanej kategrii CREATE TRIGGER delete BEFORE DELETE ON categries FOR EACH ROW EXECUTE PROCEDURE bdelete(); REATE OR REPLACE FUNCTION bdelete() RETURNS trigger AS DECLARE idk NUMERIC(5,0); BEGIN SELECT id INTO idk FROM categries WHERE name = 'brak kategrii'; UPDATE psts SET categry = idk WHERE categry = OLD.id; RETURN NULL; END; LANGUAGE plpgsql VOLATILE COST 100;
Trigger pełniący rlę lggera. CREATE TRIGGER lg AFTER INSERT OR UPDATE OR DELETE ON psts FOR EACH ROW EXECUTE PROCEDURE lg_add(); CREATE OR REPLACE FUNCTION lg_add() RETURNS trigger AS BEGIN IF (TG_OP = 'DELETE') THEN insert int lg(ip, date, actin, descr) values (new.authr, nw(), 'delete', ld.title); RETURN OLD; ELSIF (TG_OP = 'UPDATE') THEN insert int lg(ip, date, actin, descr) values (new.authr, nw(), 'update', new.cntent); RETURN NEW; ELSIF (TG_OP = 'INSERT') THEN insert int lg(ip, date, actin, descr) values (new.authr, nw(), 'insert', new.title); RETURN NEW; END IF; RETURN NULL; END; LANGUAGE plpgsql VOLATILE COST 100; Trigger sprawdzający pprawnść adresu mail użytkwnika. CREATE TRIGGER vadilate_mailt BEFORE INSERT ON users FOR EACH ROW EXECUTE PROCEDURE vadilate_mail(); CREATE OR REPLACE FUNCTION vadilate_mail() RETURNS trigger AS BEGIN IF NEW.email NOT LIKE '%@%' THEN RAISE EXCEPTION '% bledny mail', NEW.email; END IF; RETURN NEW; END; LANGUAGE plpgsql VOLATILE COST 100;