Abstract - Datavetenskap

Inventariedatabas för SystemDataNätet
Författare:
Marcus Eriksson
Handledare:
Thomas Johansson (Umeå Universitet)
Jan-Åke Olofsson (Skanova Networks)
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
0. FIGURFÖRTECKNING: ................................................................................................... 4
1. ABSTRACT: ......................................................................................................................... 6
1. ABSTRACT: ......................................................................................................................... 6
2. SAMMANFATTNING: ....................................................................................................... 6
3. INLEDNING: ....................................................................................................................... 7
4. PROBLEMBESKRIVNING: .............................................................................................. 8
5. FÖRUTSÄTTNINGAR: ...................................................................................................... 8
6. DATABASER: ...................................................................................................................... 8
6.1 DATABASTYPER: ................................................................................................................ 9
6.1.1 Hierarkisk databas: .................................................................................................... 9
6.1.2 Nätverksdatabas: ........................................................................................................ 9
6.1.3 Relationsdatabas: ....................................................................................................... 9
6.1.4 Objektorienterad databas: .......................................................................................... 9
6.2 OLIKA DATABASER AV RELATIONSTYP: .............................................................................. 9
6.2.1 Access: ........................................................................................................................ 9
6.2.2 Oracle: ...................................................................................................................... 10
7. PROGRAMMERINGSSPRÅK: ....................................................................................... 10
7.1 VAL AV PROGRAMMERINGSPARADIGM:............................................................................ 10
7.1.1 Procedurella: ............................................................................................................ 10
7.1.2 Objektorienterade:.................................................................................................... 11
7.1.3 Script: ....................................................................................................................... 11
7.2 OLIKA PROGRAMMERINGS SPRÅK AV OBJEKT ORIENTERAD TYP: ...................................... 11
7.2.1 C++: ......................................................................................................................... 11
7.2.2 Java: ......................................................................................................................... 11
7.3 JAVA: ............................................................................................................................... 11
8. IMPLEMENTATION: ...................................................................................................... 12
8.1 JAVA KOMPONENTER:....................................................................................................... 12
8.1.1 Java Servlets: ............................................................................................................ 12
8.1.2 Java JDBC ................................................................................................................ 13
8.1.2.1 JDBC-ODBC brygga (Typ 1): ........................................................................... 13
8.1.2.2 Delvis Java, delvis tillverkar drivrutin (Typ 2): ................................................. 14
8.1.2.3 Mellanlager databasaccesserver (Typ 3): ........................................................... 14
8.1.2.4 Ren Java drivrutin(Typ 4): ................................................................................. 15
8.1.3 SQL: .......................................................................................................................... 15
8.1.3.1 Statement: ........................................................................................................... 15
8.1.3.2 PreparedStatement .............................................................................................. 15
8.1.3.3 CallableStatements ............................................................................................. 16
8.1.4 Java Mail: ................................................................................................................. 16
8.1.4.1 Session:............................................................................................................... 16
8.1.4.2 Authenticator: ..................................................................................................... 16
8.2 ORACLE: .......................................................................................................................... 16
8.2.1 JDBC-Drivrutin: ....................................................................................................... 16
2/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.2.2 Oracle kontakt strategier: ........................................................................................ 17
8.2.2.1 En kontakt per transaktion: ................................................................................ 17
8.2.2.2 Dedikerad kontakt: ............................................................................................. 17
8.2.2.3 Sessions kontakt: ................................................................................................ 18
8.2.2.4 Cached kontakt: .................................................................................................. 18
8.2.3 Oracle detektering och låsning: ............................................................................... 18
8.2.3.1 Låsning: .............................................................................................................. 18
8.2.3.2 Detektering: ........................................................................................................ 19
8.2.4 OracleSQL: ............................................................................................................... 20
8.3 MITT FÖRSLAG TILL PROGRAMSTRUKTUR: ....................................................................... 20
8.3.1 Användare: ............................................................................................................... 21
8.3.2 HTML-sida: .............................................................................................................. 22
8.3.3 Java Applikation: ...................................................................................................... 22
8.3.4 Databas: ................................................................................................................... 24
9. UTVECKLINGSVERKTYG ............................................................................................ 27
9.1 APACHE TOMCAT 4.0.1: ................................................................................................... 27
9.2 TSW WEBCODER INTERNATIONAL 2: .............................................................................. 27
9.3 JCREATOR LE 2.0: ........................................................................................................... 29
10. SAMMANFATTNING: ................................................................................................... 30
11. REFERENSER: ................................................................................................................ 30
12. TACK: ............................................................................................................................... 30
BILAGA 1. ANVÄNDARHANDLEDNING: ...................................................................... 31
INLOGGNING: ......................................................................................................................... 31
PROFILER: .............................................................................................................................. 31
Beställare: ......................................................................................................................... 31
Mottagare: ......................................................................................................................... 34
Entreprenör: ...................................................................................................................... 38
Systemadministratör: ......................................................................................................... 39
3/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
0. Figurförteckning
Fig. 1 SDN-nätets uppbyggnad ............................................................................................................................... 7
Fig. 2 Anrop till webb applikation .........................................................................................................................12
Fig. 3 Anropsstruktur JDBC-ODBC brygga ..........................................................................................................13
Fig. 4 Anropsstruktur delvis Java, delvis tillverkardrivrutin ..................................................................................14
Fig. 6 Anropsstruktur ren Java drivrutin ................................................................................................................15
Fig. 7 Anropsstruktur mot Oracle databas .............................................................................................................17
Fig. 8 Anropsstruktur i programmet. ......................................................................................................................21
Fig. 9 Anropsstruktur i Java applikation ................................................................................................................22
Fig. 10 Förklaring över session ..............................................................................................................................23
Fig. 11 Nodtabell ...................................................................................................................................................24
Fig. 12 Beställningstabell .......................................................................................................................................24
Fig. 13 INP-beställningstabell ................................................................................................................................25
Fig. 14 Användartabell ...........................................................................................................................................25
Fig. 15 Tabell över sökbara nodtyper.....................................................................................................................25
Fig. 16 Tabell för godkända entreprenörer .............................................................................................................25
Fig. 17 Relationsschema ........................................................................................................................................26
4/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
5/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
1. Abstract:
The purpose of this master thesis is to develop a program that handle orders of ADSL1-,
HDSL1-magasin and other elements, from the order being placed through the receipting by
the planer to the building by the entrepreneur and finally the node being put into function.
In a practical sense the assignment was solved by use of “Rapid Prototyping” which means a
fast development of a trial program which in turn was used as a framework för the final
product. This way of working demands a close co-operation between developer and client. In
this case the request from Skanova Networks was a product to create an inventory of the
nodes in one of their networks, and there by simplifing the processing och orders to the
network. The final solution was webbased to accomidate reachability and use for the the
clients who in turn use the services of Skanova Networks.
The program is implemented with the help of “Java 2 Enterprise Edition” (Servlet, JavaMail
and JDBC), development work was done with help of Microsoft Access 97 were as the
implementation was done with “Oracle 8.1.5”. The Servlet was initiated with help of
“Apache Tomcat 4.0.1”.
To fully understand the material of this report a small knowledge in the following areas of
programming are required, Java- and SQL-syntax, a certain in HTML-programming is also
advantageous
2. Sammanfattning:
Detta examensarbete har kommit till för att skapa ett program för att behandla beställningar
av ADSL2-, HDSL2-magasin och andra element. Från det att order beställs genom behandling
av planerare och byggande av entreprenör till slutgiltig initiering av noden.
Rent praktiskt har uppgiften lösts med hjälp av s.k. ”Rapid Prototyping” d.v.s. snabb
utveckling av ett försöksprogram som sedan använts som mall för att skapa den slutgiltiga
produkten. Ett sådant arbetssätt förutsätter ett nära samarbete mellan utvecklare och den
presumtiva kunden. I detta fall var kunden Skanova Networks vars önskemål var en produkt
som skulle skapa en förteckning av de noder som ingår i ett av deras nät, och därigenom
förenkla bearbetningar av beställningar till detta nät. Den slutgiltiga produkten blev
webbaserad för att förenkla åtkomst och användande för de kunder som i sin tur nyttjar
Skanova Networks tjänster.
Programmet implementerades med hjälp av ”Java 2 Enterprise Edition” (Servlet, JavaMail
och JDBC), utvecklings arbete skedde med hjälp av Microsoft Access meddans
implementationen gjordes med hjälp av ”Oracle 8.1.5”. Dessa ”Servlet” initierades med hjälp
av “Apache Tomcat 4.0.1”.
1
ADSL (Asymmetric Digital Subscriber Line) and HDSL (High bit-rate Digital Subscriber Line) are a way for
communication to the Internet throe regular copper-wire, twisted pair, to reach a higher speed. Digitalizing the
signal before it hits the copper does this.
2
ADSL (Asymmetric Digital Subscriber Line) och HDSL (High bit-rate Digital Subscriber Line) är ett sätt att
leverera hög hastighets Internet via vanlig koppar tråd, twisted pair. Digitalisering av signalen före den kommer
till kopparen orsakar detta.
6/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Vid läsande av detta examensarbete underlättar det märkbart om läsaren är kunnig i Java- och
SQL-syntax, samt ett visst kunnande i HTML-programmering underlättar.
3. Inledning:
Skanova är en bifirma till Telia som drivrutin och utvecklar Sveriges största nät för telefoni-,
Internet- och bredbandstjänster. Det rikstäckande fibernätet förbinder totalt 3000 orter med ett
fibernät på totalt 2 miljoner kilometer och utökas för närvarande med upp till 5 000 – 10 000
kilometer per vecka[1], Systemdatanätet(SDN) är en del av detta nät. SDN tillhandahåller
kommunikation internt inom Skanova där all kommunikation utanför nätet skall gå via SDN
Extranet(SXN), vilket är ett nät som tillför SDN säker kommunikation mot yttervärlden. SDN
har som huvuduppgift att tillhandahålla underhåll av Skanovas tjänster t.ex. ADSL- och
HDSL-magasin.
ADN2
SDN
TAP1
SXN
Övriga1
AP
Syste
Server
m
Syste
Server
m
Nät-
elemen
t
Fig. 1 SDN-nätets uppbyggnad
Mitt examensarbete genomförs våren och sommaren 2002 vid Skanova i Umeå, och skall
tillföra förenklad administration av beställningar mot SDN samt en inventariedatabas av vilka
platser där det existerar en SDN-nod.
Anledningen till att jag valde detta examensarbete var bland annat att jag fick möjlighet att
utveckla mitt kunnande inom Java och SQL, vidare fick jag en inblick i HTML, dynamiskHTML och JavaScript.
1
TAP (Teknisk arbetsplats) Används bland annat för att övervaka SDN-nätet, AP Arbetsplats.
ADN (Administrativa nätet) Benämningen på Skanovasövergripande nät.
2
7/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
4. Problembeskrivning:
SDN används för att underhålla de tjänster som Skanova har, för att detta skall vara möjligt
skall en SDN-nod finnas på den plats som en tjänst skall upprättas på. Detta betyder att för
varje ny tjänst som skall upprättas på en ort, skall en sökning för tillgänglig SDN-nod
utföras. Om en sådan nod är icke existerande på platsen skickas en beställning om
utbyggnad. För närvarande finns inget lämpligt program för att automatisera dessa
beställningar, ej heller någon enskild förteckning för alla SDN-noder.
Mitt arbete var att utvärdera olika lösningar till problemet.






Utvärdera lämplig teknik och struktur för en inventariedatabas över SDN-noder.
Samla in information till inventarie databasen.
Utveckla en metod för uppdatering och bearbetning av data i databasen.
Undersöka existerande lösningar till liknande problem, och hur de kan appliceras på
detta problem.
Föreslå en lämplig lösning för SDN.
Realisering av databas med medföljande webb applikation (i möjligaste mån).
För att lösa dessa frågeställningar börjar jag med teorin bakom de delar som måste ingå i
programmet vilka är programmeringsspråk och databaser. Utifrån dessa teorier kommer
jag att välja komponenter, med tanke på de som passar bäst för uppgiften. Efter detta
kommer jag att presentera de komponenter ur dessa programmeringsspråk och databaser
som jag kommer att använda, med information om olika sätt att använda dessa på och vilka
val som är möjliga. Efter detta lägga fram hur ett program för denna uppgift bör se ut.
Avslutningsvis kommer jag att ge en förklaring till de verktyg jag har använt under
utvecklingen och en användarhandledning till den prototyp som jag har skapat för att
undersöka de flaskhalsar som kan uppkomma i programmet.
5. Förutsättningar:
En hårt arbetande student(undertecknad) med erfarenhet av C, C++ och
databasprogrammering och viss kunskap i Java och JavaBeans.
Data från en databas vid namn NOD som innehåller en förteckning på alla de noder som
finns i Sverige. Denna databas finns lagrad som en Oracle relationsdatabas och
administreras av KI Consulting. Anledningen till att jag nämner företaget är att de är ett
utvecklingsföretag som bl.a. tillhandahåller ett verktyg för skapa automatiska
uppdateringar i en databas.
6. Databaser:
Under 60- och 70-talet upptäckte en rad firmor att den kostnad som kom med att avlöna
folk som lagrade och indexerade filer hade blivit för stor och att det borde finnas ett bättre
sätt att lösa problemet. Där för lades stora mängder pengar ner under denna period för att
lösa problemet och man kom upp med en rad nymodigheter som ännu i denna dag är
aktuella. De tre översta av nedanstående databastyper kom till under denna tid[8].
8/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
6.1 Databastyper:
6.1.1 Hierarkisk databas:
De flesta filsystem är ett exempel på en hierarkisk databas, d.v.s. en trädstruktur där
varje nod endast har en förälder, vilket gör att det blir svårt att skapa flera-till-flera
relationer[2].
6.1.2 Nätverksdatabas:
Hypertext är ett exempel på principen bakom nätverks databaser, skiljer sig från
hierarkiska databaser genom att varje nod kan ha fler än en förälder. Gör flera-tillflera relationer enklare att skapa, men strukturen blir komplicerad[2].
6.1.3 Relationsdatabas:
Arbetar med tabeller och filter för sammankopplade tabeller. Använder som, namnet
avslöjar, relationer mellan olika tabeller. Ger ett enkelt sätt att representera flera-tillflera relationer[2].
6.1.4 Objektorienterad databas:
Information lagras i objekt, vilka kan ha komplexa knytningar till andra objekt.
Uppbyggnaden kan liknas vid pekare i C och referenser i Java[2].
Val mellan dessa typer:
Eftersom den information som finns i NOD-databasen är lagrad i en relationsdatabas
faller det naturliga valet på denna typ av databas, vidare så kommer man längre fram
att se att det finns bruk för flera-till-flera relationer i programmet. Detta bidrar till
valet av en relationsdatabas. Den overhead som en objektorienterad databas skulle
medföra ligger inte i proportion till det extra arbete som behövs för att föra över
informationen från en redan existerande databas.
6.2 Olika databaser av relationstyp:
Grunden för relationsdatabaser är matematisk relation, mängdlära och första ordningens
predikatlogik och fördes fram år 1970 av Dr. Edgar F. Codd.
Det nya med denna modell var att inga föredefinierade relationer existerar mellan två
tabeller, vilket medförde att användarna inte behövde veta hur informationen var lagrad
för att kunna söka i den[7].
Nedan följer en beskrivning av de databasprogram som jag har undersökt för denna
uppgift.
6.2.1 Access:
Denna produkt bygger på Microsofts populära databasmotor ”Microsoft Jet Engine”,
vilket gör en funktionalitet mot en rad olika filformat, eftersom motorn stöder Open
Database Connectivity(ODBC), vilken är den ledande standarden för att arbeta med
databaser. Förutom en motor som ger möjligheten att arbeta med flera olika fil
format, tillhandahåller Access också en rad grafiska verktyg för att skapa en databas
med tillhörande frågor, makron och rapporter[3].
9/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Access tillhandahåller ett väldigt enkelt verktyg för att både skapa och använda en
databas, man skapar väldigt enkelt en databas som kan användas med Java. Dock så
är det väldigt lång accesstid då man använder ODBC-JDBC bryggan och att använda
en annan drivrutin kostar pengar.
6.2.2 Oracle:
En av de mest använda databasprogrammen, som erbjuder en rad olika funktioner för
större databaser. Använder två strukturer; en fysisk och en logisk där den logisk på
ett ungefär representerar det schematiska uppläggningen av databasen. Vidare så
finns möjligheten att manipulera lagringsutrymmet[3].
Oracle är ett svårt verktyg att använda, och framför allt konfigurera, men då man väl
har fått igång databasen så är den väldigt enkel att använda bl.a. för att den levereras
med en speciell JDBC drivrutin.
Oracle vs. Access
Detta val var väldigt enkelt att göra.
 Access skulle kosta pengar, vilket Oracle som Telia har koncernavtal med är
gratis.
 Noddatabasen är uppbyggd med hjälp av Oracle.
 I framtiden, om en fortsatt implementation skulle göras, fanns målet att använda
Telia Message Bus(TMB). Vilket är en informationskanal för att skicka data
inom Telia, denna kanal skapas med hjälp av ett program som heter Tibco
Integration Manager, vilken arbetar med Oracle och ett fåtal andra databaser,
dock ej Access. Ett försök gjordes att i denna implementation använda TMB det
föll dock på kostnad, 70 000:- kostade det att låta KI Consulting skapa
kopplingen.
Valet föll p.g.a. detta på Oracle.
7. Programmeringsspråk:
Programmeringsspråk har utvecklats väldigt fort under senare år, allt började 1954 med
Fortran som mest användes som ett vetenskapligt språk, till dagens objektorienterade
språk.
7.1 Val av programmeringsparadigm:
Då man väljer programmeringsspråk skall man vara noga med att välja ett som
tillhandahåller den funktionalitet som önskas då det medför väldigt mycket extra arbete
att upprätta kommunikation mellan två olika programmeringsspråk.
7.1.1 Procedurella:
Den mest använda typen i redan existerande program med exempel som Fortran,
Pascal, Cobol och C. Problemet delas upp i individuella procedurer och funktioner,
vanligtvis på ”top-down” maner, data delas dock inte upp utan stannar i
huvudkroppen.
10/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
7.1.2 Objektorienterade:
Det objektorienterade paradigmet är för närvarande det mest använda av alla
utvecklings metoder. Detta paradigm kan ses som en rad objekt innehållande data
och metoder som kommunicerar mellan varandra. Detta ger en naturligare
programstruktur, dock kan programmets gång vara svårare att följa[4].
7.1.3 Script:
Det finns en rad programmeringsspråk som kan användas för att skapa applikationen
i fråga t.ex. PHP, Python, Perl och JSP, alla dessa är dock Scriptspråk. Scriptspråk
kompileras inte, vilket medför att man icke kan dölja koden.
Funktionella vs. OO vs. Script.
Eftersom det i första hand skall vara en webbapplikation, lämpar sig icke
procedurella språk för detta program eftersom dessa saknar något egentligt stöd för
webben. Då återstår scriptspråk och objektorienterade språk. Scriptspråken kan vara
väldigt svåra att sätta sig in i, speciellt Perl med vilket man kan göra väldigt mycket
på få rader kod men som har en väldigt hög inlärningströskel.
Det som dock fällde avgörandet vad gäller språk var tidigare erfarenhet. Jag har
tidigare utvecklat program i C++ och känner mig därför mer införstådd i den
utvecklingsform som följer med denna typ av språk.
7.2 Olika programmerings språk av objekt orienterad typ:
7.2.1 C++:
Ett av de mest använda objekt orienterade språken, som är bakåtkompatibel med C,
vilket ger en väldigt enkel övergång från funktionell programmering, p.g.a. likheter i
syntax. Har dock inget större stöd för webbprogrammering.
7.2.2 Java:
Ett ”nytt” programmeringsspråk som har lånat mycket av sin syntax från C/C++, har
också ett mycket väl utvecklat stöd för webbprogrammering.
Java vs. C++:
Java har ett större stöd för webbprogrammering vilket är en avgörande faktor för
detta examensarbete. Ser man vidare så har Oracledatabasen ett inbyggt stöd för Java
från version 8.1.5 vilket ytterligare gör den mer lämpad.
7.3 Java:
Java är ett programmeringsspråk som egentligen utvecklades för att användas i
hemelektronik men introducerades istället som ett gratisspråk när datoranvändandet tog
fart under 90-talet. Språket blev snabbt populärt och licenser köptes av bl.a. Oracle och
Apple.
Språket är till skillnad från C++ helt igenom objektorienterat, (går inte att skriva på
annat sätt), med stark typkontroll. Detta tillsammans ger, att man får ett språk som vid
utvecklingen skapar mindre fel[6].
11/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8. Implementation:
Tidigare har jag berättat vilka komponenter som jag har valt till implementationen av
denna uppgift. Nästa steg är att göra en så kallad ”Rapid prototyping” för att upptäcka dom
problem som kan uppkomma. Nedan följer en djupare genomgång av de delar som
programmet är uppbyggt av.
Summering:
 Oracledatabas för lagring av order och användarinformation.
 Java för att skriva applikationen (JDBC, JavaMail, Servlet).
 HTML för användargränssnittet.
Jag har icke nämnt HTML tidigare, detta beror på att det är mer av ett nödvändigt ont för
att förmedla informationen som tas fram och inga större finesser används.
8.1 Java komponenter:
Den funktionallitet som Javaprogrammet skall stödja är; Ta emot och skicka HTMLkod, söka i databas och skicka mail.
Det finns tre olika sätt för Java att ta emot och skicka HTML-kod, alla dessa har dock
en sak gemensamt och detta är Servlet3. Så för att förenkla arbetet har jag valt att arbeta
med Servlets utan något inslag av Java Server Page (JSP) eller JavaBeans.
Databasaccess är en av de grundläggande delarna av programmet för detta har Java en
väl utvecklad API4 som kallas JDBC. Mailfrågan var den del som jag själv trodde skulle
skapa mest problem men med hjälp av Java Mail, går det att enkelt skapa ett program
för ändamålet.
8.1.1 Java Servlets:
Java Servlets är ett API4 för att behandla anrop från webbklienter och tillhandahåller
ett enkelt sätt att förmedla resultat från operationer tillbaka till klienten.
Exempel:
Ett anrop kommer från en användare till webbservern, denna kontrollerar mot
”servlet context” om det finns någon webbapplikation som korresponderar mot
detta anrop. Om applikationen i fråga existerar skickas anropet vidare till
”webbcontainern”. När denna väl kommit till ”webbcontainern” bestäms vilken
applikation som skall behandla den, om det är JSP, Servlet eller annan statisk
resurs. Detta sker med hjälp av URL mönster. Om det var en servlet som skulle
behandla anropet skickas både anropet och en ”ström”, som gör det möjligt för en
servlet att dynamisk svara på anropet.
Web Browser
Web Server
J2EE Web Container
Web Application
HTTP request
JSP?
Servlet Context
Servlet?
HTTP Response
Fig. 2 Anrop till webb applikation
3
Små plattformsoberoende program på serversidan som gör det möjligt att skapa affärslogik i HTTP processer.
”Application program interface” kod som används för att lösa en uppgift utan att behöva veta alla detaljer hur
detta sker.
4
12/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.1.2 Java JDBC
En API4 som gömmer de leverantörsspecifika accessmetoderna mot databasen, vilket
ger ett enkelt gränssnitt för utvecklare, det problem som kan följa med detta är
laddandet av drivrutin för databasen[5].
Det finns fyra olika typer av drivrutins som kan användas för kommunikation mot
databasen.
Innan man väljer vilken typ av drivrutin som skall användas bör man kontrollera
vilka typer som tillverkaren tillhandahåller. Det är inte säkert att alla fyra typer
tillhandahålls.
8.1.2.1 JDBC-ODBC brygga (Typ 1):
- Eftersom ODBC bygger, till viss del, på Call Level Interface (CLI) för att
kommunicera med databasen. Kan denna brygga arbeta mot alla databaser
som stödjer CLI, vilket är de flesta.
- Rent praktiskt blir denna drivrutin inte speciellt effektiv eftersom det blir
många steg som anropen skall översättas[5].
Java application
JDBC API
Databas
JDBC-ODBC
Brygga
ODBC API
ODBC lager
Fig. 3 Anropsstruktur JDBC-ODBC brygga
”Application program interface” kod som används för att lösa en uppgift utan att behöva veta alla detaljer hur
detta sker.
4
13/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.1.2.2 Delvis Java, delvis tillverkar drivrutin (Typ 2):
- Använder en blandning av Java implementerad och tillverkar specifik
drivrutin. Med denna konstellation blir det ett steg mindre än JDBC-ODBC
bryggan.
- Man får tillgång till alla de metoder som är tillverkar specifika.
- Effektivare än JDBC-ODBC bryggan[5].
Java Applikation
JDBC API
JDBC Driver
Tillverkar Specifik API
Databas
Fig. 4 Anropsstruktur delvis Java, delvis tillverkardrivrutin
8.1.2.3 Mellanlager databasaccesserver (Typ 3):
- Ger möjligheten att koppla flera Javaklienter till flera olika databasservrar
- Anropet går genom JDBC drivrutin till en mellanlageraccesserver, vilken
slutför anropet via ytterligare en drivrutin.
- En av fördelarna med denna typ är att en del detaljerna kring kontakten med
databasen kan döljas[5].
Java applikation
Databas
JDBC API
JDBC Driver
JDBC Driver Server
Fig. 5 Anropsstruktur databasaccesserver
14/41
Native Driver
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.1.2.4 Ren Java drivrutin(Typ 4):
- Tillverkarspecifik drivrutin som kopplas direkt mot databasen.
- Den effektivaste drivrutinen[5].
Java Applikation
Databas
JDBC API
JDBC DRIVER
Fig.6 Anropsstruktur ren Java drivrutin
8.1.3 SQL:
SQL är det standardiserade språk som används för att arbeta med en databas, Java
tillhandahåller tre olika sätt att sända dessa frågor till databasen.
8.1.3.1 Statement:
- En textsträng skickas via kontakten direkt till databasen till exempel.
- String fnamn = ”hubba”;
java.sql.ResultSet rs =
statement.executeQuery(”SELECT LASTNAME ”+
”FROM USER WHERE FIRSTNAME =”+
’”+fnamn+”’;”);
- Problemet med denna sökning är att varje gång en fråga skall ställas måste
strängen kontrolleras mot strukturen på databasen.
8.1.3.2 PreparedStatement
- Ett anrop behandlas en gång och frågetecken lämnas för att kunna föra in
värden till frågan till exempel.
String fnamn = ”hubba”;
PreparedStatement prep=
c.prepareStatement("SELECT LASTNAME FROM USER”+
”WHERE FIRSTNAME = ?");
prep.setString(1, fnamn);
java.sql.ResultSet rs = prep.executeQuery();
- Är effektivare om man skall skicka flera frågor eller göra ”batch”uppdateringar.
- Gränsen när PreparedStatement är effektivare än Statement går vid 65
anrop[5].
15/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.1.3.3 CallableStatements
- Ett anrop lagras på databasen för att snabbt kunna exekveras.
- Detta sätt att anropa databasen är dock inte det snabbaste, som man lätt kan
tro, detta beror på att man får en extra accesstid för att anropa det lagrade
anropet.
- Det fall det kan löna sig att använda lagrade anrop är när man skall göra
komplicerade anrop som involverar flera del anrop. Då kan lagrade anrop
användas för att slippa skicka resultatet från delanrop tillbaka till
anropsprogrammet[5].
8.1.4 Java Mail:
Java Mail API fungerar på ett liknande sätt som JDBC. Det abstraherar bort
sändandet och mottagandet för ett visst protokoll och tillhandahåller istället ett antal
generiska kommandon som fungerar på de flesta protokoll.
8.1.4.1 Session:
- Skall inte förväxlas med Servlet Sessions, utan är en helt fristående del från
denna.
- Innehåller kontakt information till mailservern, dock ingen inloggnings
information.
8.1.4.2 Authenticator:
- Ger möjligheten att bygga en autentiserare som kan arbeta mot mailservern
och/eller en egen inloggnings procedur.
Dessa är de två viktigaste för att kunna sätta skicka mail med hjälp av Java.
8.2 Oracle:
Som jag har nämnt tidigare så är Oracle en av de största tillverkarna av databasprogram. Vad som gör den extra lämplig för att använda med Java är att den har ett
inbyggt stöd genom att tillhandahålla en OracleSQL klass.
För att skapa en kontakt i programmet mot databasen krävs en drivrutin, dessa finns av
flera olika typer och lämpar sig för olika typer av program. Nedan följer en uppräkning
av de olika drivrutiner som finns för Oracle.
8.2.1 JDBC-Drivrutin:
Det finns två typer av Javadrivrutin som tillhandahålls av Oracle, dessa är av Typ 2
och Typ 4, d.v.s. delvis Javadrivrutin och ren Javadrivrutin. Oracle har skapat två
drivrutin till varje typ, två för klient sidan och två för server sidan. Utöver dessa finns
Sun’s egen JDBC-ODBC brygga[6].
Klient:
- JDBC delvis Java drivrutin.
- JDBC Java drivrutin.
Av dessa lämpar sig ren Java drivrutin bäst till de flesta program, eftersom den ger
samma, och ibland högre, prestanda mot databasen. Enda tillfället när delvis Java
drivrutinen ger bättre prestanda än Java är vid CallableStatements.[6].
16/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Server
- JDBC delvis Java drivrutin.
- JDBC server sida Java drivrutin.
Om man har möjligheten att få direkt kontakt med databasen är delvis Java
drivrutinen effektivast, medan man för program där webbservicen och databasen
ligger på olika servrar bör man använda server sida Java drivrutin, av samma orsaker
som ovan[6].
JDBC Java Drivrutin
JDBC delvis Java
drivrutin driver
Oracle Call interface
ODBC drivrutin
JDBC-ODBC drivrutin
Oracle Listener
Oracle Databas
Fig. 7 Anropsstruktur mot Oracle databas
Den del som alla drivrutiner måste kommunicera med är Oracle Listener som bland annat
lagrar vilka som kontaktar databasen och vilka ändringar som görs.
Eftersom man i denna uppgift inte tillåter att klienten direkt ansluter till databasen, utan går
via en servlet, och databasservern kommer att finnas på samma dator som webbservern
lämpar sig delvis Java drivrutinen (typ 4) för server bäst.
8.2.2 Oracle kontakt strategier:
Efter man har hittat den drivrutins typ som passar bäst för just detta program kommer
man till frågan: Hur skall kontaken mellan program och databas ske?
8.2.2.1 En kontakt per transaktion:
- Varje Servlet öppnar en ny kontakt för varje transaktion som skall göras och
stänger den när transaktionen är klar.
- Den mest använda transaktionsstrategin, och den mest ineffektiva.
8.2.2.2 Dedikerad kontakt:
- Varje Servlet öppnar en ny kontakt och stänger den när servleten stängs.
- Den mest kostsamma av alla strategier, eftersom ett stort antal kontakter
kommer att vara öppna mot databasen samtidigt.
- Ett annat problem som kan uppstå är att lagra vilken användare som har gjort
vilka ändringar.
17/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.2.2.3 Sessions kontakt:
- Varje ny användare öppnar en kontakt som sedan är öppen till dess att
användaren loggar ut.
- Kräver även den ganska många kontakter.
- Bör användas med ”sessionbinding” för att kunna känna av när en session
stängs, detta scenario kan uppstå om en användare går ifrån en sida utan att
logga ut.
8.2.2.4 Cached kontakt:
- För varje program finns en pool med kontakter till en databas som dynamiskt
öppnar och stänger kontakter till en databas, beroende på hur lång tid det var
sedan en kontakt senast användes.
- Den mest effektiva metoden.
- Det problem som kan uppstå med denna strategi är att det blir svårare att
identifiera vilka som har gjort ändringar i databasen[6].
Ett av de krav som ställdes på programmet var att alla ändringar som sker i databasen
skall lagras. Detta kan tyckas tala emot en Cache med kontakter, men eftersom varje
enskilt värde som ändras skall lagras kommer användaren att vara tvungen att sätta
en signatur på den data som ändras. Detta kommer att ge en, i värsta fall, fördubblad
mängd skrivning till databasen, men det är ett av kraven för systemet.
8.2.3 Oracle detektering och låsning:
Ett viktigt avsnitt då man arbetar med databaser är integritet, säkerställa att
uppdateringar inte skriver över varandra, t.ex.
”Användare A läser rad 1, var efter också användare B rad 1. Därefter skriver B
värdet 37 till raden var efter användare A skriver värdet 15 till raden”
Ovan har vi ett scenario där användare B förväntar sig att finna värde 37 på raden,
men det har blivit över skrivet. För att rätta till detta problem finns det ett antal
möjligheter.
8.2.3.1 Låsning:
 Implicit låsning:
- Hanteras automatiskt av programmet.
- Vid varje ändring av databasens innehåll, låser transaktionen databasen mot
andra uppdateringar. Vilket betyder att en annan transaction kan läsa
innehållet i raden men inte uppdatera det.

18/41
Radlåsning:
- Hanteras i SQL-frågorna som skickas mot databasen.
- Om en transaction skall läsa en rad, för att sedan uppdatera den, kan
användaren skicka med ett ”FOR UPDATE” i SQL frågan. Detta låser hela
raden till transaktionen är gjord.
- Detta skulle kunna lösa problemet om man lade till alternativet ”NOWAIT”,
vilken gör att en transaction inte väntar oändligt länge för att få låsningen.
- Det krävs mycket arbete från programmeraren för att få detta att fungera och
det finns effektivare sätt.
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14

Tabellåsning:
- Hanteras i SQL frågan.
- Väldigt ovanligt sätt att bearbeta databasintegritet och skall bara användas
som en sista utväg, eftersom det försämrar prestanda för programmet.
Låsning löser problemet som ställts upp ovan, men ett annat problem kan
uppkomma.
”Användare A läser rad 1 och låser denna rad för uppdateringar, Användare B
läser efter detta, värdet på samma rad försöker skriva uppdatering, det går ej
eftersom raden är låst. A skriver efter detta på raden och släpper låsningen
varefter även B skriver in ett nytt värde på raden”
Detta scenario kan lösas med detektering.
8.2.3.2 Detektering:
 Uppdateringsräknare
- Till varje rad läggs en räknare som visar vilket nummer den nuvarande
uppdateringen har i tur ordningen. Detta betyder att en uppdatering kan
kontrollera om det skett en uppdatering mellan det att sessionen har läst data
till dess den skall skriva data.
- Löser problemet kräver dock extra kod för att det skall fungera.
- Räknas som ett pessimistiskt angreppssätt.

Jämförelse med alla värden
- Före varje uppdatering av databasen kontrolleras det om det gjorts några andra
uppdateringar genom att jämföra alla värden som lästs in mot de som finns i
databasen.
- Löser problemet, kräver mindre extra kod.
- Räknas också som ett pessimistiskt angreppssätt

Jämföra alla värden som skall uppdateras:
- Vid en uppdatering kontrolleras endast primärnyckeln och dom fält som skall
uppdateras mot databasvärdet.
- Detta ger ett mindre antal misslyckande transaktioner.
- Svårt för programmeraren att skapa ”WHERE” fältet.
För att kunna garantera dataintegritet bör man kombinera detektering och låsning, för
denna diskussion finns det två olika sätt att angripa problemet.
Pessimistiskt:
”Det finns en stor chans att två transaktioner kommer att skriva över varandra”
Optimistiskt:
”Det är inte vanligt att två transaktioner skriver över varandra”
19/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Jag börjar med de två pessimistiska tillvägagångssätten.

”SELECT FOR UPDATE NOWAIT”:
- Varje transaktion låser raden den skall behandla och spärrar den för alla andra
transaktioner.
- Eftersom en transaktion som försöker få tillgång till en rad som är låst får ett
”exception” så finns det ingen möjlighet för den att skriva över en
uppdatering.
- Kräver mycket kod, alla transaktioner måste följa reglerna för att integriteten
skall behållas.
- Ett problem som kan uppstå är att en icke avslutad transaktion kan uppehålla
en rad i oändlig tid.

Pessimistisk detektering och implicit låsning:
- Implicit låsning hanteras automatiskt av databasen, det enda som läggs till här
är en kontroll som uppdateringsstämpeln.
- Detta löser problemet och ger enkla SQL frågor.
- Dock tillkommer problemet att underrätta användaren om uppdateringen har
misslyckats.
Optimistiskt
 Optimistisk detektering med implicit låsning:
- Nyckeln och de värden som skall modifieras sparas och används sedan för att
kontrollera om en uppdatering skett på raden.
- Man måste fortfarande underrätta användare om att en uppdatering
misslyckats, men detta kommer att hållas till ett minimum.
Av dessa tre möjliga val passar sig den optimistiska bäst för denna uppgift, eftersom
systemet inte kommer att utsättas för hård belastning och det information som
hämtas oftast skall användas för att läsas.
8.2.4 OracleSQL:
Oracle tillhandahåller ett antal extra funktioner utöver de som redan finns Java SQL.
Dessa är dock av mindre betydelse för detta program. Den enda funktion som kan
vara intressant att använda är ”defineColumnType”, med vilken man kan definiera
hur strukturen ser ut i databasen. Anledningen till att göra detta är att frågorna inte
behöver anropa databasen om vilken struktur den har, vilket drastiskt sänker
accesstiden för en fråga[5].
8.3 Mitt förslag till programstruktur:
Jag har tidigare berättat vilka programmeringsspråk som skall användas och varför, då
undrar säkert vän av ordning vilken struktur programmet bör ha. För att besvara detta
börjar vi från början.
Det bör påpekas att detta förslag inte är samma som den implementation som förklaras i
bilagan, utan endast en förklaring till hur implementation borde se ut för att uppfylla alla
krav.
20/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Nedan visas en enkel bild av hur informationsflödet bör sker i programmet.
Java Applikation
HTML sida
Önskemål
Respons
Data
SQL
Databas
ResultSet
Fig. 8 Anropsstruktur i programmet.
En användare skickar sina önskemål via en HTML sida till en Java Applikation som lagrar
dessa önskemål i databasen, en bekräftelse går sedan tillbaka till användaren.
8.3.1 Användare:
Det finns fyra typer av användare som har behörighet till olika nivåer i programmet.
Beställare:
- Skall kunna söka efter noder där det skulle behövas en SDN-nod.
- Ska fylla i en beställning på vad noden skall användas till.
- Denna beställning lagras i databasen och ett mail skickas.
Mottagare:
- Tar emot mail, som är en bekräftelse på att en beställning kommit in.
Kontrollerar då med tidigare beställningar om det finns en möjlighet att bygga
en grupp med SDN-noder.
- Om en sådan grupp existerar samlas dessa under en beställning med ett unikt
INP nummer.
- Viss konfigurering sker som förhandsjobb innan beställningen går vidare till
entreprenören.
- När klarrapportering ankommit från entreprenören, kan INP beställningen
flyttas till klara jobb.
Entreprenör:
- Entreprenören tar emot INP beställningen, och ser vilka noder som innefattas i
denna beställning.
- Om någon av noder inte går att bygga förs detta in i databasen med en
kommentar om varför, detta meddelas per mail till mottagaren.
- När en beställning är klart, klarrapporteras den till mottagaren.
Administratör:
- Har möjlighet att skapa nya användare.
- Kan gå in i databasen och redigera den.
- Har möjligheten att söka fel.
- Skall kunna skapa sorterade utdrag ur databasen för utskrift.
Eftersom dessa användare kommer att ha olika rättigheter till databasen, bör man
implementera fyra olika cache med kontakter för varje användargrupp. Detta betyder
att det vid varje tillfälle kommer att finnas minst fyra aktiva kontakter till databasen.
21/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.3.2 HTML-sida:
Här sker interaktionen mellan användare och Java-applikationen, dess innehåll bör
genereras dynamiskt av Java programmet. För att komma åt behövs ”cookies”
eftersom HTML, per definition, är tillståndslöst. ”Cookies” gör det möjligt att skapa
en identifikations möjlighet för programmet och därigenom möjligt för applikationen
att tilldela användaren resurser som skall vara öppna under hela användarens session
i programmet.
8.3.3 Java Applikation:
Skall innehålla logiken som behandlar den information som kommer in. Denna har
byggts upp på ett Objektorienterat sätt där det existerar ”Handlers”, objekt med data
och metoder, för användaridentitet och interaktion med databasen.
HTML-sida
Önskemål
Java Applikation
Request
Handler
Anrop
Databas
SQL fråga
Fig. 9 Anropsstruktur i Java applikation
Javaapplikationen i sig består av ett antal servlets som interagerar via HTML-sidan,
d.v.s. en servlet skapar dynamiskt en HTML-sida som innehåller information för att
anropa andra servlets. Ur säkerhetsaspekt kan detta tyckas vara en mindre bra
lösning. Ett sätt att lösa detta är att använda sessions, som jag har nämnt tidigare.
Dessa sessions skapas när en användare loggar in i systemet och terminerar när
antigen en användare loggar ut eller om en session inte använts under en längre tid.
Under programmets exekvering kan inte en användare använda systemet utan att vara
tilldelad en giltig session. Nu används inte session enbart till att kontrollera
giltigheten för en användare, objekt kan också bindas till en session så att de finns
med till nästa servlet som användaren kommer till.
22/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Servlet 1 skapar en Handler (Handler 1).
Servlet 1
Marcus Eriksson
Handler 1 lagras i session
Handler1
17-07-14
Servlet 1
Handler 1 arbetar med
databasen och är tillslut klar
Användar info
Användar info
Session
Handler 1
Servlet 1 skapar en HTML
Sida, och dör sedan.
Användaren anropar nästa
servlet med hjälp av
HTML-sidan.
Session
Servlet 2 använder handler 1 från session.
Servlet 2 skapas
Servlet 2
Handler1
Servlet 2
Användar info
Användar info
Handler 1
Session
Session
Fig. 10 Förklaring över session
Handlers:
Olika Handlers bör sköta all kontakt som sker med databasen, detta för att skapa
en modularisering av kommunikationen. Om varje servlet skulle kommunicera
mot databasen skulle samma kod skrivas flera gånger och ändringar skulle vara
svåra att implementera. För handlers skall det implementerat en cache med
kontakter mot databasen. Som nämnts tidigare är detta det effektivaste sättet ta
tillvara databasresurserna.
Mitt angreppssätt för att strukturera handlers går ut på att det finns en
övergripande ”search handler” som används för att söka efter flera rader av data,
denna data kan sedan sökas igenom för att hitta enstaka rader som lagra i ett
objekt av samma typ som tabellens rader.
När man väl hittat den rad man söker efter, kan denna laddas in i en Handler som
tillhandahåller metoder för att manipulera raden i fråga och lagra den i databasen.
Den faktiska lagringen på disk bör inte ske direkt varje gång, utan informationen
skall sättas in i en cache, tills tillräckligt mängd data har accumulerats. Detta ger
att senare sökningar mot samma mängd data sker snabbare och man får en
snabbare exekvering av programmet, dock med nackdelen att data kan gå
förlorad, vilket kan rättas till med hjälp av loggning av ändringar i databasen.
23/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
8.3.4 Databas:
En av de viktigaste egenskaper som denna databas skall tillhandahålla är loggning
av ändringar som sker i databasen, vad som ändrades av vem och när. Detta krav
kommer i konflikt med implementationen av kontakter med hjälp av ”cache”. För
att lösa detta skall det för varje rad finnas ett uppdateringsfält där användarnamn
och datum skall föras in på den person som har gjort ändringen.
Detta upplägg skulle ge denna struktur på NOD-databasen.
Fig. 11 Nodtabell
Detta är dock inte all den information som finns i NOD-databasen, utan bara den
mängd som behövs för att skapa programmet.
Efter beställaren sökt och hittat noden i NOD-databasen, görs en beställning.
Denna beställning lagras i beställnings-tabellen i databasen.
Fig. 12 Beställningstabell
Det bör påpekas att anledningen till denna mängd av rader, är att
beställningsprotokollet för *DSL och SDH inte är lika.
24/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
När ett antal beställningar kommit in skall dessa sammanföras baserat på FOområde5, varefter de skall konfigureras för att sedan skickas till en entreprenör.
Tabellen för detta ser ut på följande sätt.
Fig. 13 INP-beställningstabell
Nästa tabell som finns i denna databas är användartabellen, som innehåller dom
personer som har rättigheter att använda programmet.
Fig. 14 Användartabell
Det som finns kvar nu att förklara är två mindre tabeller. Den första av dessa
tabeller innehåller de noder som är sökbara för beställarna.
Fig. 15 Tabell över sökbara nodtyper
Och den andra vilka företag som är tillåtna att beställa till.
Fig. 16 Tabell för godkända entreprenörer
Dessa tabeller, som sammantaget blir databasen för programmet, uppfyller de krav
som ställs. Alla ändringar kommer att loggas eftersom varje skrivning kommer att
ändra stämpeln och tidigare skrivna värden kommer att lagras av databasen som textfil.
5
FO-område är den senaste indelning som Telia har på Sverige, andra typer av indelningar finns också i
databasen dessa på region och TLO, alla har dock det gemensamt att de bygger på geografi.
25/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Relationerna i databasen ser ut på följande sätt.
Fig. 17 Relationsschema
26/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
9. Utvecklingsverktyg
Eftersom en huvudsakliga uppgiften var att utvärdera teknik och struktur för
inventariedatabasen, har inte valet av utvecklings verktyg varit det viktigaste.
9.1 Apache Tomcat 4.0.1:
Referensimplementation för Servlets och Java Server Page(JSP), vilken på ett enkelt sätt
sätter upp strukturen för att skapa Servlets.
9.2 TSW Webcoder International 2:
Ett grafiskt verktyg för webbdesign, fungerar väldigt bra. Utveckling sker med hjälp av
förprogrammerade knappar eller med hjälp av ren HTML kodning, vilket programmet hjälper
till att skapa.
Vidare så finns det tre olika ”vyer” som hjälper till under utvecklings arbetet.
27/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Där ”Edit” tillhanda håller plats för HTML-programmering, ”Preview” ger en bild av vad
man har programmerat hittills och ”QuickEdit” ger ett grafiskt gränssnitt för att placera
komponenter på sidan, denna funktion stöds inte fullt ut av programmet men har, vad jag har
märkt, aldrig krånglat.
Det finns ytterligare funktioner som förenklar designen, bl.a. en editor för olika Scriptspråk.
Och ett val för att skicka webbsidan via FTP.
28/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
9.3 JCreator LE 2.0:
En enkel editor för Java som ger en bra överblick på vilka funktioner som ingår i ett program
och även vilka program som ingår i ett projekt.
Ger också stöd vid kompilering och exekvering av programmen, man kan bl.a. specificera
behovet av mer utförliga felmeddelanden.
29/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
10. Sammanfattning:
Detta avslutar min rapport på det examensarbete som jag har arbetat med på Skanova,
som sista del har jag valt att göra en kort resumé på det arbete jag har gjort.
Det förslag till implementation som jag har framfört är byggt med grundtanken att
vidare utveckling skall vara möjligt. T.ex. har jag valt Oracle databasen för att den är en
av de få databaser som Tibco Integration Manager, som används på Telia för att
kommunicera med databaser inom koncernen, arbetar mot. Vidare var ett av kraven att
programmet skulle vara webbaserat vilket talade för att använda Java, vilken har ett bra
stöd för just sådan programmering, att sedan Oracle har egna bibliotek för interaktion
mellan Java och Oracle försämrar inte heller läget. Ser man sedan det sätt, på vilket jag
har implementerat programmet i Java ser man att möjligheterna för vidare utveckling är
goda eftersom all kommunikation med databasen är modulariserad, så även resultaten
från databassökningarna.
Som slutord vill jag nämna att arbetet med detta projekt har varit väldigt lärorikt och
intressant. Och har givit mig mycket inför ett framtida arbete med liknande projekt.
11. Referenser:
1. Skanova Networks AB [email protected]: Om Skanova:
Presentation, www.skanova.com/index.asp?lev=32 (2002-06-25).
2. Ulfhielm, Ulf: KTH/ISK Databasteknik 8p, 2001,
http://www2.isk.kth.se/kursinfo/6b4019/FoV-2001/Overhead/DB3OH-Nr04-dbms.ppt
(2002-07-02)
3. Elmasri Navathe, Fundamentals of database systems, tredje upplagan, Addison-Wesley,
2000
4. Schach, R. Stephen, Classical and Object-oriented Software engineering, tredje upplagan,
McGraw-Hill, 1996
5. Allamaraju, Subrahmanyam et al ,Professional Java Server Programming, J2EE 1.3
Edition, Wrox, 2001
6. Bales, Donald, Java Programming with Oracle JDBC, 1st Edition, O’Reilly, 2002
7. Greenwald, Rick, Oracle Essentials, 1st Edition, O’Reilly, 1999
8. http://wwwinfo.cern.ch/db/aboutdbs/history/industry.html, A Brief History of Databases
(2002-08-05)
12. Tack:
Jag skulle vilja tacka Jan-Åke Olofsson och alla andra på Skanova som har kommit med
värdefulla synpunkter på arbetet som har hjälpt mig att fullborda detta examens arbete.
Tack även till Johan Furberg som har hjälpt mig där mina kunskaper i Java inte har räckt till.
Vill även tack min handledare på Universitetet Thomas Johansson som har hjälpt mig med
denna rapport.
30/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Bilaga 1. Användarhandledning:
Innan vi gör djupare in på användarhandledningen bör det på pekas att denna implementation
inte har samma funktionallitet som den som beskrivits i rapporten, detta för att tid inte har
funnits för att implementera allt. Men det kanske kommer i version 1.1.
Inloggning:
Vid inloggningen kontrolleras användarnamnet och lösenordet mot dess
motsvarighet i databasen, lösenordet i sig kommer ej upp i klar text utan vid fråga
mot databasen får man endast ett svar om lösenordet stämmer eller ej. Om lösenordet
stämmer skapas en session för användaren, där användarnamnet lagras. Skulle
användaren inte göra något under 5 minuter kommer sessionen automatiskt att
avslutas, för att en annan användare inte skall kunna göra ändringar i databasen och
lagra dessa under annat namn än sitt eget.
Profiler:
Det finns fyra olika typer av användare som alla har olika vägar genom programmet, jag
kommer att gå igenom dessa i tur och ordning.
Beställare:
Det första sida som beställaren kommer till är sök sidan.
31/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Här kan användaren skiva in en ort för den nod som skall sökas efter, eller klicka på
stations signatur för att söka efter nodens betäckning.
Eftersom SDN noder endast kan sättas på platser där det finns Ö, ÖK eller ÖS
noder är endast dessa sökbara, om man lämnar blankt kommer programmet att
returnera alla noder med dessa typer. Jag kommer nu att göra en sökning HJÖ
ÖS och blankt för Nod typ betäckning.
Man ser här att det finns en ÖS nod i Hörnsjö och man skulle kunna få fram samma
resultat om man endast sökte på Hörnsjö. Man kan nu antingen välja att söka efter en
ny nod med hjälp av samma sökfält som fanns i de tidigare bilderna eller välja att
börja behandla beställningen för Hörnsjö. Vi går vidare och behandlar beställningen
för Hörnsjö.
Man får nu fram denna bild, den kan tyckas onödig men är väldigt viktig om man vid
sökningen fått fram flera olika noder som kan vara rätt. Här ser man den fullständiga
adressen för noden. Om det var rätt nod trotts allt går man vidare med hjälp av
submittknappen.
32/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Här kan man välja om beställningen gäller ett ADSL-, HDSL-magasin eller ett SDH
nätelement. Dessa val kommer nu att gås igenom i tur och ordning.
Här ser man att en del av uppgifterna är för tryckta t.ex. Beställarens namn telefon
och e-post som har lagrats i sessionen då man loggade in. Vidare är även det objekt
som beställningen gäller förtryckt.
Beställningsformuläret för HDSL ser ut på samma sätt med samma fält som skall
fyllas. SDH formuläret däremot är inte av samma typ.
33/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Mottagare:
Mottagaren är den på Skanova som tar emot beställningen från kunden, start sidan för
denna person ser ut på följande sätt.
Första valet av dessa är samma sökning som för beställare med den skillnad att
alla typer är sökbara, detta för att en mottagare skall kunna se om det redan finns
en SDN nod på orten6.
6
Från början var det tänkt att programmet automatiskt skulle undersöka om det fanns en SDN nod på noden med
hjälp av x och y koordinater. Detta visade sig icke var genomförbart eftersom alla noder inom en stad hade
samma x och y koordinater.
34/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Sökning av beställning är den viktigaste funktionen för mottagaren eftersom det är
här man hittar dom beställningar som har kommit in och har möjlighet att se hela
beställningen.
Här har man möjlighet att specificera vilken typ av nod som skall sökas efter och
söka efter dessa med hjälp av beställningsnummer, beställare, nod signatur och FOområde. Nedan följer resultatet på en sökning av FO-området NA.
Här har man nu möjligheten få mer information om beställaren och, om
beställningen ingår i en INP7-beställning, gå till denna. Bilder av hur INPbeställningen ser ut kommer senare.
7
INP-beställning är en samling av beställningar inom samma FO område som satts ihop för att de skall
behandlas samtidigt.
35/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Nästa alternativ som existerar för mottagaren är sökning efter användare, detta
alternativ finns för att mottagaren skall kunna kontakta beställaren av en speciell
order.
Man kan här söka efter antigen användarnamn eller namn, där namn inkluderar
förnamn och efternamn. Resultatet från denna sökning ser ut på följande sätt.
Detta är också den bild man skulle få om man sökte begärde information om en
användare från en beställning.
Vidare så finns möjligheten för mottagaren att skapa entreprenör- och beställaranvändare, dock kan nya entreprenörer endast komma från företag som sedan
tidigare har rättigheter att ta emot beställningar.
36/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Nästa möjlighet som finns för mottagaren är sökning efter INP-beställningar, detta är
dock ett något missvisande namn efter som man vid sökning mot en icke existerande
INP nummer får möjligheten att skapa en ny INP beställning.
Om man gör en ny beställning kommer de beställningar upp som inte är tilldelade
något INP-nummer, sorterade efter FO område.
Om man lägger till denna beställning får man en kvittens på att registreringen är
gjord och möjligheten att gå till beställningen.
Här har mottagaren möjlighet att indikera vilken konfigurering som är gjord, se mer
ingående på de beställningar som ingår, ta bort enskilda beställningar, ta bort INP
numret och även klarrapportera beställningen.
37/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Entreprenör:
Entreprenören är den som bygger noderna i en INP-beställning, hur entreprenören får
vetskap om beställningen är icke klart i detta skede, dock så bör en funktionsbrevlåda
vara en enkel lösning på det problemet.
De val som entreprenören har är följande:
De olika valen ger följande:
 Hämta INP
- Hämtar de INP-beställningar som är skickade till det företag som
entreprenören arbetar på.
 Sök INP
- Ger möjligheten att söka efter INP-beställningar som skickats till företaget,
har dock ej implementerats klart ännu.
 Hämta noder
- Har ej implementerats ännu men skall ge möjligheten att hämta de noder
som tidigare behandlats av företaget, men ännu ej är klara.
 Sök noder
- Har ej heller blivit implementerat, men skall göra samma som ovan med
den skillnad att det man söker efternoder.
Det första valet ser ut som följer:
Man ser här vilket FO-område INP-beställningen tillhör, när den beställdes och
när den klarrapporterades.
38/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Man kan gå vidare och se på beställningen mer i detalj:
Här har man nu möjligheten att ändra lovat datum och även att lägga
kommentarer till de noder som ingår i beställningen.
Systemadministratör:
Har följande val:

Lägg till användare:
- Här har användaren möjlighet att lägga till nya användare, av alla fyra
typer.
 Ta bort användare:
- Ta bort någon av de redan existerande användarna.
 Ändra sökbara nodtyper:
- I början kan endast noder av typ Ö, ÖS och ÖK sökas efter, det kan vara
aktuellt vid ett senare tillfälle att ändra detta.
 Sök fel:
- Det finns en möjlighet att fel kan uppstå i databasen, här finns en sökning om
det finns några fel i databasen.
39/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Det första av dessa val ser ut som följer:
Här fyller man i på samma som tidigare dom uppgifter som behövs, märk också
att det nu finns fyra val på användartyp i stället för två.
Nästa val ser ut som följer:
Man markera vilka användare man vill ta bort och trycker sedan ta bort
användare.
Vidare så har systemadministratören möjligheten att ta bort eller lägga till sökbara
nodtyper.
40/41
Examensarbete 20p
Inventariedatabas för Systemdatanätet
Marcus Eriksson
17-07-14
Det som visas vid valet av någon av dessa möjligheter är en lista med nodtyper.
Nästa möjlighet som finns för systemadministratören är sökning av fel, som ovan
får man ett antal val att välja mellan.
Kort förklaring på de olika val som finns.
 INP utan noder:
- Kontrollerar om det finns en INP-beställning som inte har några noder
tilldelade till sig.
 Nod med icke giltigt INP nummer:
- Om man tagit bort ett INP nummer finns möjligheten att ändringen inte är
gjord på alla noder.
 Nod med icke giltig beställare:
- Om en beställare blivit fråntagen sina rättigheter, finns möjligheten att en
beställning ligger kvar i dennes namn.
 Samma FO på alla noder i INP-beställning:
- Ett av kraven från entreprenörerna är att alla noder som ingår i en INP
beställning skall finnas inom samma FO, detta är bara en kontroll för detta.
Alla val ovan söker efter fel men det finns inga metoder för att rätta till felen,
detta måste göras direkt i databasen.
41/41