PB Vyšší odborná škola a Střední škola managementu, s.r.o. Absolventská práce Jan Vydrář

Transkript

1 PB Vyšší odborná škola a Střední škola managementu, s.r.o. Absolventská práce 2005 Jan Vydrář 1

2 PB Vyšší odborná škola a Střední škola managementu, s.r.o. Nad Rokoskou 111/7, Praha 8 Obor: Aplikace výpočetní techniky Název absolventské práce: Návrh databázového systému pro správu kontaktů firmy Školní rok: 2004/2005 Vypracoval: Jan Vydrář Vedoucí absolventské práce: Ing. Pavel Enderle 2

3 Prohlášení: Prohlašuji, že jsem absolventskou práci na téma Návrh databázového systému pro správu kontaktů firmy vypracoval samostatně. Použitou literaturu a podkladové materiály uvádím v přiloženém seznamu literatury. V Praze dne

4 Obsah: Úvod Popis společnosti Základní údaje Rozdělení na divize Postavení SUN divize na trhu Podmínky řešení Požadavky ze strany SUN divize Požadavky na funkčnost Rozšiřitelnost systému Požadavky na ovládání a vzhled Autentizace Omezující podmínky HW podmínky Nástin možných řešení Nákup hotového řešení Vytvoření vlastního systému Výběr řešení Vlastní aplikace Struktura dat Popis vazeb mezi datovými entitami Popis tabulek Tabulka firma: Tabulka sidlo: Tabulka lide: Tabulka pracuje: Tabulka zamereni: Tabulka telefon: Tabulka poznamka: Tabulka uzivatele: Tabulka logy: Integrita dat Popis zdrojového kódu Popis adresářové struktury aplikace Vzhled a ovládání aplikace Okno přihlášení Základní obrazovka - Administrátor Základní obrazovka uživatel Základní uživatelská obrazovka Výběr z firem Základní uživatelská obrazovka Výběr z kontaktů Základní uživatelská obrazovka Nová firma Základní uživatelská obrazovka Nová pobočka Základní uživatelská obrazovka Nový kontakt Práce s detailem firmy Práce s detailem pobočky Práce s detailem kontaktu

5 Vkládání poznámek Používání odkazu Zpět Odhlášení z aplikace Informační a varovná hlášení...41 Závěr...42 Resume...43 Použité zdroje...44 Literatura...44 Internetové zdroje...44 Seznam tabulek a vyobrazení...45 Seznam tabulek...45 Seznam obrázků...45 Přílohy

6 Úvod Cílem této práce je vytvořit databázi pro správu kontaktů, pro firmu Avnet s.r.o., ve které jsem v současné době zaměstnán. Díky dobré znalosti prostředí jsem schopen analyzovat a zpracovat přesně to, co firma potřebuje. Důvodem, proč jsem si tuto práci vybral, je skutečnost, že databázový systém pro správu kontaktů v této firmě citelně chybí. Takovýto systém by zcela jistě přinesl zjednodušení a zrychlení práce identifikačními údaji o partnerech. V dnešní době, kdy neexistuje centralizovaný systém a každý zaměstnanec má databázi svých kontaktů. Tento stav je dlouhodobě neudržitelný a přináší zbytečné dodatečné náklady. Komerční systémy, které jsou v současné době nabízeny na trhu, nejsou bohužel vyhovující. Většinou nevyhovují z hlediska nedostatečných funkcí, rozšiřitelnosti, možnosti provozu na více operačních systémech nebo z hlediska nákladů na tento systém. V dobách, kdy ještě neexistovaly počítače, se všechny evidence vedly v sešitech nebo knihách. Každý sešit sloužil pro evidenci různých druhů událostí, subjektů či objektů. Takto byly vedeny i údaje o kontaktech a to jak soukromých tak obchodních. Jeden řádek zápisu představoval jeden kontakt, popř. aktualizaci již evidovaných kontaktů. Sloupce sešitu označovaly atributy těchto kontaktů. Z výše uvedeného vyplývá, že řádky zápisů v sešitech se z principu nedají nijak přeskupovat - třídit (jsou na papíře). Informace zjišťujeme tak, že různými sešity listujeme a děláme si výpisky. V těchto sešitech vidíme předchůdce dnešních databází. V minulosti byla v každé firmě kartotéka dodavatelů a odběratelů a také osoba, případně celé oddělení, které se o tuto databázi staralo. Největším problémem byla aktualizace dat, která byla časově náročná, občas až nemožná. V mnoha větších firmách mělo podobnou kartotéku dokonce každé oddělení zvlášť a vznikala velká redundance dat, případně ne všechna data byla dostupná ve všech kartotékách. Výsledkem byla situace, kdy při přejímce zboží do skladu nemělo finanční oddělení informace, na jakou adresu má poslat fakturu. Náklady na takovouto správu kontaktů dosahovaly astronomických výšek. Do úvahy je nutno brát personální náklady (mzdové náklady, náklady na vybavení pracovního místa, apod.), náklady na vybavení kartotéky, zabezpečení proti živelným pohromám, atd. Data udržována v kartotéce je téměř nemožné zálohovat, takže při ztrátě kartotéčního záznamu, nebylo možné tyto záznamy znovu bez větších dodatečných nákladů obnovit. Vysoké náklady představovaly i reklamace, protože díky špatné aktualizaci dat vznikalo mnoho chyb, které firma musela 6

7 zaplatit např. náklady na poštovné v případě vrácení zásilky, telefonování na špatné číslo a následné zjišťování čísla správného. Vyhledání jednoho záznamu bylo časově náročné a bylo k němu potřeba zvlášť vyškoleného pracovníka specialistu. I když v kartotéce existoval systém řazení podle relativně stálých faktorů (např. IČO), nebo podle jiných znaků, nebyla zde možnost setřídit záznamy podle jiných kritérií. Toto mělo za výsledek velmi složité vyhledávání podle jiných parametrů než byl primární klíč. Po čase s přibývajícími obchodními partnery narůstala kartotéka do rozměrů, které již nebylo možné tolerovat. I samotné vyhledávání v těchto kontaktech bylo problematické. Spolu s vývojem výpočetní techniky prošla vývojem i správa kontaktů. V současné době se setkáme většinou s elektronickou podobou sešitů - databázemi. To souvisí se vzrůstajícím počtem obchodních vztahů, rozvojem informačních technologií a se změnou přístupu k partnerovi. Všechny tyto skutečnosti zapříčinily rozvoj směrem k centrální správě kontaktů. K relevantním informacím má zaměstnanec přístup v reálném čase a odkudkoli. Zároveň tento zaměstnanec nepotřebuje k vyhledání potřebných údajů žádné zvláštní znalosti a dovednosti. Dnes již není možné shromažďovat ve firmě údaje o partnerech v podobě adresy a telefonního čísla, ale o úspěchu firmy rozhoduje mnoho dalších faktorů. Kromě vyhledání obchodního partnera a uložení základních údajů o něm, je daleko důležitější jeho udržení a výchova k loajalitě vůči naší firmě, které nedosáhneme bez znalosti podrobných údajů například o jeho dřívějších nákupech nebo o našich nabídkách, které jsme mu v historii předložili. Partnera je třeba poznat a zjistit, co přesně potřebuje, aby byl na trhu úspěšný. Potřebujeme porozumět jeho potřebám a musíme o něm shromažďovat údaje, které využijeme ve svém kontaktu s ním při nabídce dalších souvisejících služeb. Tyto údaje jsou také velice důležité pro tvorbu motivačního programu pro obchodní partnery tak, aby byly motivováni prodat co nejvíce našeho zboží a na základě toho získali různé slevy a bonusy. Bez vhodného informačního systému není firma schopna toto nabídnout. Přístup údajům musí být rychlý, efektivní (náklady na zjištění údajů nesmí překročit přínosy) a objektivní (v databázi najdu přesně ty údaje, které potřebuji a které jsou aktuální). Stranou nezůstává ani otázka bezpečnosti uložených dat a to jak bezpečnosti vzhledem ke zničení či narušení konzistence dat, zničení hardwarového systému, tak k možnosti odcizení důvěrných informací, ke kterým seznam kontaktů firmy patří. 7

8 1 Popis společnosti 1.1 Základní údaje Společnost Avnet Partner Solutions Česká republika je dceřinou společností americké korporace Avnet Inc., která je jedním z největších světových distributorů pasivních polovodičů, elektromechanických komponent, počítačů a jejich příslušenství. Nadnárodní společnost Avnet Inc., založená v roce 1953, patří dnes v USA k podnikům Fortune TOP 500. Své zastoupení má v USA, Kanadě, Mexiku, Evropě, Austrálii, Jižní Africe, Asii a na Novém Zélandu. V fiskálním roce /2004 dosáhla firma obratu téměř mil. USD, což představuje nárůst o 13,2% oproti předchozímu roku. Čistý příjem byl 72.9 mil. USD. V současné době zaměstnává více než 9900 pracovníků. Avnet Inc. dodává hlavně průmyslovým zákazníkům a VARům (řešení pro prodejce s přidanou hodnotou). Organizační struktura Avnet Inc.: Obrázek 1 - organizační struktura Avnet Inc. Avnet CM, k níž patří také Avnet Partner Solutions, nabízí celé spektrum služeb souvisejících s distribucí hardware. Cílem firmy je stát se nejúspěšnějším technickým 1 Fiskální rok končí v červnu 8

9 distributorem a to nejen v Evropě, ale po celém světě. Ve střední a výhodní Evropě působí společnost na Slovensku, v Polsku, v Maďarsku a v České republice. Společnost Avnet Partner Solutions v České republice vznikla již v roce 1996 a od té doby se velmi rychle rozvíjí. V roce 2003 se firma Avnet Partner Solutions. umístila na sedmnáctém místě v žebříčku TOP 100 IT firem v České republice s obratem převyšujícím 1,2 mld. Kč. Firma v současné době zaměstnává cca 25 zaměstnanců. Avnet s.r.o Počet zaměstnanců Obrat (v mil. Kč) Tabulka 1 - vývoj obratu a počtu zaměstnanců Avnet s.r.o. Jediným společníkem Avnet Partner Solutions (společnost s ručením omezeným) je Avnet Holding Germany GmbH s vkladem Kč. Statutárním orgánem společnosti je jednatel. Avnet Partner Solutions se zabývá spolupráci mezi výrobci a svými partnery, kteří pak zboží nebo služby prodávají koncovým zákazníkům. Hlavní činnost spočívá v prodeji a ve službách s přidanou hodnotou. Mezi tyto služby patří logistika, distribuce, marketing, zajištění finančních prostředků a technická podpora. Na českém trhu působí také firma Avnet Applied Computing s.r.o., která je součástí Avnet Inc., ale je od společnosti Partner Solutions oddělená. 1.2 Rozdělení na divize Společnost Avnet Partner Solutions respektuje divizní organizační strukturu společnosti Avnet Inc. a dále se v České republice dělí na dvě základní divize podle zaměření na divizi SUN a divizi IBM: Obrázek 2 - rozdělení na divize 9

10 Divize IBM se specializuje na produkty firmy IBM a to jak z hardwarového tak softwarového hlediska. Divize SUN mimo prodeje hardwarových a softwarových produktů firmy Sun Microsystems provozuje také Partner iforce Ready centrum, které slouží pro podporu řešení náročných úloh v oblasti návrhu a implementace projektů. Společnost Avnet Partner Solutions má divizionální organizační strukturu uspořádanou na základě nabízených produktů, která má tu výhodu, že přibližuje péči přímo zákazníkovi. Tzn. že pokud má zákazník zájem pouze o produkty společnosti SUN, bude přímo kontaktovat odpovědnou osobu v divizi SUN, kde jsou odborníci, kteří mu dokáží pomoci. Na druhou stranu divizní organizační struktura má i své nevýhody jako je neefektivní využívání zdrojů či upřednostňování zájmů divize (SUN a IBM jsou velkými konkurenty na trhu) před zájmy celé společnosti, což může být v konfliktu. 1.3 Postavení SUN divize na trhu Sun Microsystems zaujímá pozici celosvětového lídra na trhu UNIXových serverů z hlediska tržeb ale i počtu prodaných kusů. Například za rok 2003 tvořily servery SUN 52% dodaných serverů, tzn. že každý druhý dodaný UNIXový server na světě je od SUNu. Tato pozice na trhu poskytuje obchodním partnerům SUNu vysokou podporu a zajišťuje jak garanci nejvyšší kvality tak i silného partnera v zádech. 10

11 2 Podmínky řešení 2.1 Požadavky ze strany SUN divize Systém pro správu kontaktů bude aplikace určená pro potřeby divize SUN společnosti Avnet Partner Solutions Požadavky na funkčnost SUN divize očekává, že tato správa kontaktů jim poskytne aktuální a dokonalý přehled v kontaktech na dodavatele a odběratele. Samozřejmostí je vedení veškerých kontaktních údajů o těchto osobách a možnost jejich aktualizace. V aplikaci by mělo být zabráněno vytváření duplicitních informací o kontaktech. Vzhledem k množství partnerů je nutná i možnost vyhledávání podle zvolených parametrů. Aplikace by měla umožnit: Zakládat, vést a aktualizovat údaje kontaktních osob a firem Zakládat, vést a aktualizovat veškeré fakturační údaje o partnerech a dodavatelích Práce v reálném čase Přístup ke kontaktům 24 hodin denně Přístup ke kontaktům odkudkoli ze sítě Internet Současný přístup více osob do aplikace najednou Vyhledávání podle parametrů a fulltextové vyhledání Možnost tisku jednoduchých sestav kontaktů Nezávislost na platformě, systém musí být schopen fungovat jak pod MS Windows tak pod Linuxem, Mac OS a Solarisem Doplňkové funkce aplikace: Možnost podívat se zpět do historie kontaktů. Příjemné uživatelské rozhraní 11

12 2.1.2 Rozšiřitelnost systému Správa kontaktů by měla jít rozšířit o další pole a to co nejjednodušším způsobem. Program by měl obsahovat funkce, pomocí kterých se budou ovládat databázové vstupy a výstupy, tj měl by být nezávislý na databázovém systému, který zpracovává vlastní data. Tato podmínka je zde především proto, aby bylo možno operativně přejít na jiný databázový systém pokud by stávající již nebyl dále vyvíjen, nebo pokud by obsahoval bezpečnostní chyby, které by ohrozily chod systému. Samotná databáze by měla být nekonečně rozšiřitelná, protože počet záznamů bude neustále růst a nesmí se stát, že bude databáze zcela zaplněna a nebude možné do ní doplňovat další údaje. Toto všechno je nutné uvážit také z hlediska diskového prostoru, který bude databáze zabírat Požadavky na ovládání a vzhled Ovládání by mělo být dostatečně intuitivní a jednoduché především pomocí grafických tlačítek, formulářů nebo odkazů. GUI by mělo být přiměřené, jednoduché bez zbytečných rozptylujících prvků Autentizace Autentizace je ověření identity uživatele, tedy jeho totožnosti. Metod autentizace existuje několik, ale pro naší aplikaci jsou aktuální: použití hesla použití certifikátů veřejných klíčů. Autentizace heslem Mnoho bezpečnostních incidentů v síti je způsobeno nedostatky při autentizaci heslem. Často se stává, že systémoví administrátoři nekonfigurují systém tak, aby: vyžadoval pravidelnou změnu hesla uživatele heslo muselo obsahovat kombinaci alfanumerických znaků heslo nebylo možné opakovaně použít Další oblastí, kde jsou mezery, je kázeň uživatelů, kteří si musí zvyknout na pravidla pro práci s přihlašovacím heslem. To znamená, že by neměli volit snadno odhalitelná hesla, 12

13 neměli by sdělovat své heslo dalším osobám, nechávat je zapsané na svém pracovišti a v žádném případě nesmějí opustit své pracoviště pokud jsou přihlášeni do systému. Autentizace pomocí veřejných klíčů Příkladem použití certifikátů veřejných klíčů je doporučení X.509, které definuje poskytování autentizačních služeb v rámci adresářových služeb X.500. Certifikáty jsou jakési potvrzení o platnosti veřejných klíčů. Tato platnost je stvrzena podpisem důvěryhodné certifikační autority na každém certifikátu. Certifikáty jsou uloženy ve veřejném adresáři, ke kterému mají přístup všichni. Požadavky na aplikaci Aplikace musí bezpodmínečně mít zabezpečenou autentizaci a umožnit tak omezení přístupu jednotlivých osob pouze k potřebnému fragmentu dat. Je nutné vytvořit minimálně 2 stupně oprávnění pro přístup k datům. Administrátorský administrátor má přístup ke všem uživatelským oprávněním, která může sám upravovat, dále má možnost zasahovat do již uložených dat, Uživatelský přístup k datům pro čtení i zápis, ale nemožnost data odstraňovat, pouze měnit jednotlivé položky, toto nastavení je vhodné například pro obchodní zástupce, kteří do databáze mohou zakládat nové kontakty, který získají Ostatní - neautorizovaní uživatelé nesmějí mít k datům žádný přístup, k datům nesmí mít přístup nikdo neoprávněný. čtení zápis nastavení Administrátor X X X Uživatel X X Ostatní Tabulka 2 - Stupně oprávnění Je nutné zajistit šifrovaný přenos informací a to v obou směrech, jak směrem od serveru k přihlášenému uživateli, tak ve směru opačném, aby nebylo možné komunikaci a přenos citlivých údajů jakkoli odchytit, případně dešifrovat. Dalším bodem ochrany je zajištění vnitřní sítě a informačního systému proti útokům či neoprávněným zásahům zvenčí z prostředí internetu. Prvním krokem bude úvodní přihlašovací stránka pro přístup do vnitřního systému. Pro přístup bude povolen pouze port 13

14 443/TCP pro protokol https, a port 22/TCP pro vzdálený šifrovaný přístup přes SSH, všechny ostatní porty budou zablokovány z obou směrů. Toto bude mít na starost firewall, který bude předřazen před serverem na kterém poběží systém pro správu kontaktů. Neméně důležitou stránkou bezpečnosti systému je ochrana a archivace dat proti případným přímým, fyzickým poškozením serveru, proto data budou pravidelně zálohována. Je také nutné zrcadlení datových pevných disků pro případ selhání jednoho z nich. Systém musí disponovat možností záznamu informací a to jak informací o přihlášení uživatele, tak o změnách které daný uživatel provedl. 2.2 Omezující podmínky HW podmínky Ze strany Sun divize firmy Avnet s.r.o. bude pro účely systému pro správu kontaktů vyhrazen jeden server značky Sun typ LX50. Vnitřní konfigurace bude následující: CPU Intel Pentium III 1.4 GHz, 1GB RAM ECC, 2x HDD 36 GB, možnost HW raidu, 1x Lan 10/100. Firma disponuje dostatečně rychlým připojením k internetu (1Mbit/1Mbit). Server bude připojen za firemním firewallem a je možné aby měl přidělenu veřejnou IP adresu. Pro zálohování bude možné využít některého z dalších zařízení firmy. Obrázek 3 - struktura připojení serveru do internetu 14

15 3 Nástin možných řešení 3.1 Nákup hotového řešení Na dnešním softwarovém trhu je k dispozici mnoho produktů, které řeší správu kontaktů. Tato řešení jsou většinou součástí větších softwarových balíků například CRM řešení. Většina softwarových firem si je vědoma zájmu podniků o tyto programy a proto vytvářejí nové a nové, stále dokonalejší a větší softwarové balíky. Výrobci tohoto softwaru většinou myslí i na to, že většina firem nepotřebuje všechny funkce jejich balíku. Některé funkce jsou proto dodávány ve formě přídavných modulů, které je možné dokoupit, ale i tak je základní software drahý a obsahuje velké množství funkcí které firma nepotřebuje. Nákup hotového řešení zahrnuje i možnost naprogramování zcela nové aplikace externí firmou. Toto řešení bývá časově náročné a nákladné. 3.2 Vytvoření vlastního systému Naprogramování vlastního řešení přinese při kvalitní výchozí analýze nejvyšší užitek. Pokud zaměstnanec ve firmě již pracuje, zná detailně firemní potřeby. Výhodou by měla být i snazší správa aplikace, protože ten kdo aplikaci vytvoří bude přesně vědět jak funguje. 3.3 Výběr řešení Firmou Avnet bylo zvoleno řešení pomocí vytvoření vlastního systému kontaktů. Jde o nejvhodnější způsob realizace systému pro správu kontaktů, protože bude vytvořena zaměstnancem, který firmu dobře zná. Tím odpadne dlouhodobá fáze analýzy, která by externímu subjektu trvala delší dobu a výsledek by nebyl tak jistý. Zároveň firma zavrhla nákup hotového řešení, protože na trhu momentálně není systém, který by přesně splňoval požadavky firmy Avnet. 15

16 Obrázek 4 - Skript na straně serveru Nejvhodnější je provedení ve formě webové aplikace, která bude vhodná pro snadný provoz v prostředí internetu/intranetu. Pro výhody, které poskytuje jsem pro realizaci vybral skriptovací jazyk PHP verze 4.3. Server zpracovává zdrojové kódy (tzv. PHP skripty) a klientovi zasílá výstup formou HTML dat. Proto lze na klientské straně použít libovolný (i starší) prohlížeč webových stránek a není třeba pořizovat samostatný program. PHP řadíme do skupiny skriptovacích jazyků, které pracují na straně serveru. Jazyk PHP podporuje spolupráci s velikým množstvím databází, ke kterým programátor přistupuje přes unifikované příkazy. Odstiňuje tak programátora od specifikací jednotlivých databázových systémů a aplikaci lze v případě potřeby poměrně snadno upravit pro spolupráci s jinou databází. Jako systém řízení báze dat (SŘBD) jsem si vybral databázový systém MySQL. Aplikace je v současné době provozována na serveru webového hostingu Klenot ( kde je nainstalován databázový server MySQL. Se stejným nastavením se počítá při nasazení ve firmě Avnet. Výhody tohoto řešení jsou zřejmé. Zpracování všech požadavků probíhá na straně serveru a ke klientovi jsou přenášena pouze výsledná data ve snadno srozumitelné formě HTML dokumentů. Takové řešení neklade vysoké nároky na koncovou stanici, kde lze použít běžný počítač vhodný pro připojení k síti Internet vybavený programem pro zobrazování WWW stránek. Zásadní výhodou je ovšem cena systému pro provoz aplikace. Veškeré programové prostředky lze získat bezplatně a v rámci tzv. Open Source software. Na straně serveru je to operační systém Unixového typu (např. Linux), dále HTTP server Apache podporující jazyk PHP i databázový server MySQL. Na straně klienta je to kromě operačního systému už jen webový prohlížeč. 16

17 4 Vlastní aplikace 4.1 Struktura dat Popis vazeb mezi datovými entitami Data jsou uložena v databázi MySQL ve formě několika tabulek, mezi kterými jsou vztahy 1:N s cizím klíčem. Při návrhu datové struktury jsem vycházel z následujícího konceptuálního schématu. Obrázek 5 - ERD diagram 17

18 4.2 Popis tabulek Tabulka firma: Tato tabulka v sobě uchovává informace o firmě. Jedná se o údaje základní a to název, IČO, DIČ, webovou adresu pro komunikaci a firemní globální . Protože každá firma může mít více poboček, jsou adresy a další údaje vázané na jednotlivé pobočky odděleny v tabulce sidlo. Sloupec Typ Nulový Popis id int(10) auto_increment ne Primární klíč nazev varchar(255) ne Název firmy ico varchar(32) ano IČO firmy dic varchar(32) ano DIČ firmy web varchar(255) ano Webová adresa varchar(255) ano Tabulka 3 - firmy Tabulka sidlo: Tabulka sidlo obsahuje údaje o jednotlivých pobočkách firmy. Vazba na tabulku firma je zprostředkována pomocí sloupce firma_id, který obsahuje odkaz na primární klíč tabulky firma. Sloupec Typ Nulový Popis id int(11) auto_increment ne Primární klíč firma_id int(11) ne ID firmy z tabulky firma adresa varchar(255) ano První řádek adresy mesto varchar(128) ne Druhý řádek adresy psc varchar(8) ano Poštovní směrovací číslo stat varchar(128) ano Stát ve kterém je pobočka varchar(255) ano na pobočku Tabulka 4 - sidlo 18

19 4.2.3 Tabulka lide: Tabulka lide obsahuje detailní informace o jednotlivých kontaktech, jedná se zejména o Jméno, příjmení a ovou adresu. Kontakty jsou spojeny s danou pobočkou (pod kterou spadají) pomocí tabulky pracuje. U každého kontaktu je také položka zaměření, která je odkazem na primární klíč do tabulky zamereni. Zabráníme tak redundanci dat a navíc sjednotíme dostupná zaměření do jednoho seznamu. Sloupec Typ Nulový Popis id int(10) auto_increment ne Primární klíč jmeno varchar(25) ano Jméno prijmeni varchar(25) ne Příjmení zamereni int(11) ano ID z tabulky zamereni web varchar(255) ano webová adresa varchar(255) ano ová adresa titulpred varchar(16) ano Titul před jménem titulza varchar(16) ano Titul za jménem Tabulka pracuje: Tabulka pracuje je spojovacím článkem mezi tabulkou lide a sidlo. Její funkce spočívá v přiřazení lidí k pobočkám ve kterých pracují. Obsah tabulky je tvořen příslušnými primárními klíči z tabulek lide a sidlo. Sloupec Typ Nulový Popis id int(11) auto_increment ne Primární klíč lide_id int(11) ne ID člověka z tabulky lide sidlo_id int(11) ne ID sídla z tabulky sidlo Tabulka 5 - pracuje 19

20 4.2.5 Tabulka zamereni: Data z tabulky zamereni slouží pouze k načítání jednotlivých popisů zaměření kontaktů. Pomocí této tabulky odstraňuji redundanci dat a zároveň připravuji data pro možnost hledání podle zaměření. Sloupec Typ Nulový Popis id int(10) auto_increment ne Primární klíč zamereni varchar(32) ne Zaměření Tabulka 6 - zamereni Tabulka telefon: Tabulka telefon obsahuje telefonní čísla a to jak na pobočky firem, tak i na jednotlivé kontakty. Díky zavedení zvláštní tabulky na telefonní čísla je možné přidat libovolný počet těchto čísel ke každému z kontaktů. Datový typ telefonního čísla byl úmyslně zvolen jako znakový, protože je pak možné zapsat znaménko plus např Sloupec Typ Nulový Popis id int(11) auto_increment ne Primární klíč sidlo_id int(10) ano ID sídla z tabulky sidlo lide_id int(10) ano ID člověka z tabulky lide cislo varchar(32) ne Telefonní číslo Tabulka 7 - telefon Tabulka poznamka: Tabulka poznamka obsahuje poznámky a to jak poznámky k jednotlivým kontaktům, tak i poznámky k firmám a jejich pobočkám. U poznámky je vždy datum a čas a v sloupci uzivatel_id je uveden jednoznačný identifikátor který určuje uživatele systému, který poznámku vložil. 20

21 Sloupec Typ Nulový Popis id int(11) auto_increment ne Primární klíč datum datetime ne Datum a čas poznamka text ne Text poznámky firma_id int(11) ano ID firmy lide_id int(11) ano ID člověka sidlo_id int(11) ano ID sídla uzivatel_id int(11) ne ID uživatele který poznámku zapsal Tabulka 8 - poznamka Tabulka uzivatele: V tabulce uzivatele jsou uloženy informace o uživatelích samotného systému pro správu kontaktů. Ve sloupci login jsou přihlašovací jména, ve sloupci heslo je pak uloženo zašifrované heslo. Položka lide_id je odkazem na primární klíč do tabulky lide, tj uživatel systému musí být nejprve založen jako kontakt a pak je teprve možné založit jeho účet pro přístup. Sloupec admin slouží k odlišení mezi uživatelem a administrátorem, který má přístup ke správě uživatelských účtů a k záznamům o činnosti jednotlivých uživatelů v databázi. Sloupec Typ Nulový Popis id int(10) auto_increment ne Primární klíč login varchar(25) ne Přihlašovací jméno heslo varchar(128) ne Heslo lide_id int(10) ne ID z tabulky lide admin enum(y/n) ne Administrátor ano/ne Tabulka 9 - uzivatele Tabulka logy: Tabulka logy slouží pro sledování celé aplikace. Jsou zde ukládány záznamy o všech důležitých akcích. Podle údajů z této tabulky lze dohledat všechny akce počínaje přihlášením do systému, přes zakládání firem, kontaktů, přidávání poznámek až po úpravy dat v databázi. 21

22 Sloupec Typ Nulový Popis id bigint(20) auto_increment ne Primární klíč uzivatel_id int(10) ne ID uživatele cas datetime ne Čas zapsání poznámky akce text ne Popis vykonané akce Tabulka 10 - logy Integrita dat Databázový systém MySQL neumožňuje komplexní řešení integrity dat, většina integritních omezení tedy musí být zajišťována programátorem při psaní PHP skriptů. V tomto konkrétním případě je na úrovni databáze hlídána pouze neprázdnost dat (NOT NULL) a jedinečnost primárních klíčů příkazem AUTO INCREMENT. Všechna ostatní omezení, jako například správná délka řetězců, datový typ vkládaných informací a podobně je zajištěna na úrovni programové. V kódu skriptů je však navíc kontrolována i neprázdnost dat, takže databázový server řídí pouze unikátnost přidělovaných primárních klíčů. Také referenční integrita je řešena na programové úrovni. Při změně záznamů program změní příslušné záznamy ve všech dotčených tabulkách. 22

23 4.3 Popis zdrojového kódu Celá aplikace je naprogramována v jazyku PHP v kombinaci s HTML. Pro uchovávání proměnných jsou použity session proměnné. Životnost těchto proměnných je nastavena pomocí PHP na 20 minut, tj po 20ti minutách nečinnosti bude vyžadováno nové přihlášení uživatele. Hesla uživatelů jsou uchovávána v zašifrovaném stavu, tak aby je nebylo možné zjistit ani při zjištění obsahu tabulky ve které jsou tato hesla uložena. Pro šifrování hesel je použita hashovací funkce MD5 (Message Digest 5). Při přihlášení uživatele do systému se porovnává otisk uložený v databázi s otiskem, který je vypočítán z uživatelem zadaného hesla. Každý hashovací algoritmus generuje otisk o určité délce v případě MD5 je otisk dlouhý 128 bitů (32 znaků). Tato délka je pevná, takže nezávisí na vstupním textu, ze kterého se hash počítá. Z hlediska bezpečnosti se v současnosti doporučuje používat hashovací algoritmy, které mají výstup 160 a více bitů. Používání hashovacích funkcí v PHP má určitou nevýhodu oproti využití v ostatních jazycích. PHP skript je totiž interpretován až na serveru, takže po internetu putují hesla v otevřené podobě. Aby nešlo heslo odchytit, je nutné komunikaci mezi počítačem a serverem zabezpečit - například využitím https. Chybová hlášení jsou vždy volána přes funkce, tak aby nemohl nikdo zjistit přímá data z tabulek a mít dostatek informací pro útok na aplikaci. Celá aplikace je rozdělena do několika adresářů. Důvodem pro toto rozdělení je bezpečnost. Pro uživatele je viditelný pouze adresář htdocs, ve kterém jsou obsaženy pouze výkonné kódy. Nastavení, vkládané funkce a šablony vzhledu jsou odděleny v dalších adresářích, takže k nim uživatel nemá přístup. Vzhledem k objemu zdrojových kódů aplikace není smysluplné je tu všechny vypisovat. Kompletní zdrojové kódy aplikace jsou na přiloženém CD Popis adresářové struktury aplikace Adresář config slouží k uložení konfiguračních souborů. Jsou zde uloženy základní soubory database.php a server.php. Soubor database.php definuje přístup k databázi, soubor server.php nastavuje kódování HTML, titulek okna a také diskovou cestu k šablonám vzhledu. 23

24 Adresář htdocs obsahuje soubory s výkonným kódem aplikace. Soubor je většinou rozdělen na dvě logické části. V první části se nejdříve vykoná kód, pak se přesměruje na šablonu Druhá přijme zpět odeslaný formulář z šablony a vykoná opět kód pro zpracování přijatých dat. V adresáři include jsou soubory s funkcemi, které se vkládají do php kódu. V souboru functions.php jsou hlavní funkce, které aplikace používá. V podadresářích auth a dtb jsou umístěny soubory, které obsahují funkce pro ověřování uživatelů proti údajům z databáze a také funkce pro práci s databází. Adresář i18n obsahuje soubor s jazykovou mutací aplikace. V konfiguračním souboru aplikace lze jazyk zvolit. Výchozí jazyk je čeština. Posledním adresářem je adresář template. Ten v podadresářích obsahuje šablony vzhledu, které jsou použity při vykreslování stránky. Jako výchozí je zde připravena šablona default. Pro definici vzhledu aplikace používá kaskádové styly. 24