Implementacja prototypu modułu dostępu do danych SkOs przy pomocy protokołu LDAP

Transkrypt

1 Implementacja prototypu modułu dostępu do danych SkOs przy pomocy protokołu LDAP Wojciech Kowalczyk, Przemysław Curzytek 1 grudnia Częśćkonceptualna 1.1 Sformułowanie zadania projektowego SkOs, a mówiąc dokładniej Skład Osobowy- stanowi bardzo popularną bazę danych i doskonałe źródło podstawowych informacji na temat pracowników Akademii Górniczo-Hutniczej. Jest on przydatny w szczególności dla studentów, podczas wpisywania nazwisk i tytułów naukowych wykładowców do indeksów oraz kiedy zajdzie potrzeba uzyskania pewnych porad i skonsultowania się w sprawach naukowych drogą mailową, czy też odbycia bezpośredniej rozmowy w pokoju pracownika. Jednak oprócz studentów z tej bazy danych korzystają również pracownicy AGH oraz innych uczelni, a także osoby trzecie, które z różnych przyczyn potrzebują się skontaktować z daną osobą. Cały system SkOs został wykonany jako praca dyplomowa przy użyciu następujących technologii: Apache+PostgreSQL+PHP. Naszym zadaniem jest zaimportowanie istniejących danych do stworzonej przez nas bazy danych, a następnie postawienie serwera wykorzystującego protokół dostępu do katalogu, LDAP(Lightweight Directory Access Protocol). Spróbujemy również stworzyć prosty interfejs webowy dostępu do bazy danych przy wykorzystaniu popularnego frameworka webowego, Django. 1.2 Analiza stanu wyjściowego Projekt stanowi rozszerzenie, a zarazem alternatywę istniejącego na uczelni systemu SkOs. Dane zgromadzone w tej bazie są efektem kilkuletniej pracy administratorów tegoż systemu. Dla celów naszego projektu niezbędna jest możliwość zaimportowania zgromadzonych danych oraz ich późniejszego aktualizowania. Wiąże się to jednak z koniecznością wyrażenia zgody przez władze uczelni, ponieważ w bazie będą przetwarzane rzeczywiste dane osobowe. Dlatego też najprawdopodobniej w bazie nie znajdą się dane prywatne, takie jak adres zamieszkania, czy telefon prywatny. Istniejąca baza danych została przeanalizowana na podstawie udostępnionych zapomocąstrony 1 danychpersonalnych.niesątojednakwszystkieinformacjezawartewtej bazie. Reszta danych, jak na przykład lista osób administrujących poszczególne obszary bazy jest niedostępna. Jakkolwiek struktura SkOs wydaje się przejrzysta i nie mieliśmy problemu ze stworzeniem projektu naszej bazy danych. Pojawiają się jednak obawy, co do stworzonej tabeli unit, w której zostaną umieszczone poszczególne jednostki administracyjne AGH. Założeniem tej 1 1

2 1 CZĘŚĆ KONCEPTUALNA 2 tabeli jest możliwość rekursywnego przeszukiwania od najniższych szczebli do najwyższych w hierarchii struktur uczelni. Rozwiązanie takie uważamy w tej sytuacji za najprostsze, jednak nie wiemy jak zostało to zrealizowane w istniejącym systemie. 1.3 Analiza wymagań użytkownika Użytkownik systemu będzie chciał uzyskać interesujące go informacje używając interfejsu webowego pozwalającego na współpracę z serwerem. Będzie wysyłał do procesu postmastera żądania typu SELECT. Ponieważ tworzona baza danych jest przeznaczona wyłącznie do odczytu danych, należy położyć szczególny nacisk na prędkość wyszukiwania. Dobrym sposobem na uzyskanie takiego efektu będzie stworzenie indeksów, które w znaczący sposób zwiększają prędkość przeszukiwania danych w stosunku do typowego szukania sekwencyjnego. PostgreSQL jest jednak wyposażony w mechanizm automatycznego dodawania indeksu dla kolumny zdefiniowanej jako klucz główny. Prawdopodobnie będzie to wystarczające dla naszej niewielkiej bazy danych, choć bez większych konsekwencji będzie można dodać kilka innych indeksów. Może to jedynie spowolnić wprowadzanie i aktualizację danych, jednak czynności te będą wykonywane co pewien ustalony okres. 1.4 Określenie scenariuszy użycia i identyfikacja funkcji Baza danych SkOs ma jedynie charakter informacyjny. Użytkownik(host) nie może w żaden sposób modyfikować istniejących danych, ani dopisywać nowe. Może jedynie wyszukiwać pracowników AGH na podstawie dostępnych kryteriów, m.in. nazwisko, imie, grupa, stanowisko, funkcja, jednostka. Kryteria te są identyczne jak w przypadku istniejącego już systemu. Również uprawnienia administratora systemu są bardzo ograniczone. Nie może bowiem zmieniać zaimportowanych danych, zgodnie z ustawą o ochronie danych osobowych. Będzie natomiast odpowiadał za konfigurację systemu i czuwał nad poprawnym przebiegiem procedury importu danych, tak by nie doszło do naruszenia spójności, atomiczności i izolacji danych. Wyszukiwanie osób według kryteriów: 1. Wyszukiwanie podstawowe: (a) Nazwisko (b) Imię (c) Tytuł 2. Wyszukiwanie zaawansowane(= Wyszukiwanie podstawowe +): (d) Grupa (e) Stanowisko (f) Funkcja (g) (h) Jednostka (i) Pawilon (j) Pokój

3 1 CZĘŚĆ KONCEPTUALNA 3 (k) Telefon (l) Ciało kolegialne Ze względu na bardzo duże restrykcje nałożone na użytkowanie bazy danych diagramy DFD, STDiFHDsątrywialne. 1.5 FHD Functional Hierarchy Diagram 1. System zarządzania danymi osobowymi pracowników AGH 1.1 Ewidencja pracowników Wyszukiwanie pracownika Aktualizacja danych pracownika Dodanie pracownika Usunięcie pracownika Należy tutaj jednak zaznaczyć, że operacje dodawania, usuwania, czy też aktualizowania danych nie są przeprowadzane bezpośrednio przez administratora systemu, lecz w momencie importu i aktualizacji z bazy danych SkOs. 1.6 STD State Transition Diagram

4 1 CZĘŚĆ KONCEPTUALNA ERD Entity Relationship Diagram 1.8 DFD Data Flow Diagram diagram kontekstowy

5 1 CZĘŚĆ KONCEPTUALNA 5 diagram zerowy(systemu)