KHLim. Databasesysteem voor het beheer van een schoolinventaris

KHLim

Databasesysteem voor het beheer van een schoolinventaris

Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi 5/14/2009

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi

Voorwoord In dit voorwoord willen wij onze dank betuigen aan alle personen die direct en indirect hebben meegewerkt aan de verwezenlijking van deze bachelorproef. Hierbij denken wij vooral aan KIDS, die het mogelijk heeft gemaakt dat wij deze bachelorproef hebben kunnen doen. Ook danken wij Kris Aerts, waarbij we altijd terechtkonden met problemen en vragen. Langs deze weg willen wij ook graag onze ouders bedanken. Zij hebben ons de mogelijkheid gegeven om de opleiding voor Bachelor industriële wetenschappen, Elektronica-ICT tot een goed einde te brengen. Vooral hun morele maar ook financiële steun appreciëren wij ten zeerste. Tenslotte willen wij ook nog iedereen bedanken die niet vermeld is maar toch steun en hulp heeft verleend.

1


Inhoudstabel Voorwoord .................................................................................................................................................... 1 Lijst van figuren ............................................................................................................................................. 4 1 Opdracht .................................................................................................................................................... 5 1.1 Situering .............................................................................................................................................. 5 1.2 Globale probleemstelling .................................................................................................................... 5 1.3 Doelstellingen ..................................................................................................................................... 5 2. Werkplanning ............................................................................................................................................ 6 2.1 Lastenboek ...................................................................................................................................... 6 2.2 Databaseontwerp............................................................................................................................ 6 2.3 Logica en presentatie ...................................................................................................................... 7 3. Lagenmodel ............................................................................................................................................... 7 3.1 Databaselaag ....................................................................................................................................... 8 3.2 Database-abstractielaag ..................................................................................................................... 8 3.3 PHP-laag .............................................................................................................................................. 8 3.4 JSON-laag ............................................................................................................................................ 8 3.5 DHTML............................................................................................................................................... 10 4. Database ................................................................................................................................................. 11 4.1 Het ER-Schema .................................................................................................................................. 11 4.1.1 Product ....................................................................................................................................... 11 4.1.2 Categorie .................................................................................................................................... 11 4.1.3 Herstelling .................................................................................................................................. 12 4.2Vergelijking databasereplicatie.......................................................................................................... 12 4.2.1 Mysql replicatie .......................................................................................................................... 12 4.2.2 Db4O replicatie .......................................................................................................................... 13 4.2.3 MS SQL ....................................................................................................................................... 14 5. Klassen en functies.................................................................................................................................. 14 5.1 Opbouw klassen ................................................................................................................................ 15 5.1.1 Overzicht .................................................................................................................................... 15 5.1.2 Product ....................................................................................................................................... 15

2

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi 5.1.3 Eigenschap ................................................................................................................................. 16 5.1.4 Herstelling .................................................................................................................................. 16 5.1.5 Categorie .................................................................................................................................... 16 5.2 Functies ............................................................................................................................................. 17 5.3 Datastroom ....................................................................................................................................... 17 6 Beveiliging ................................................................................................................................................ 19 7 Gebruikersomgeving ................................................................................................................................ 19 8 Resultaat .................................................................................................................................................. 19 9 Bibliografie ............................................................................................................................................... 21 Bijlagen........................................................................................................................................................ 22 Bijlage 1: Lastenboek .............................................................................................................................. 22 Doelstelling: ........................................................................................................................................ 22 Schematische voorstelling: ................................................................................................................. 22 Algemene werking: ............................................................................................................................. 22 Scannen: .............................................................................................................................................. 23 Database: ............................................................................................................................................ 23 Interface (GUI) .................................................................................................................................... 23 Enkele aandachtspunten: ................................................................................................................... 23 Bijlage 2 ER-schema database ................................................................................................................ 25

3


Lijst van figuren Figuur 1: Gegevens in de database controleren ........................................................................................... 5 Figuur 2: Planning volgt uit het lastenboek .................................................................................................. 6 Figuur 3: Databaseontwerp volgt uit databasesysteem en ER-schema ....................................................... 6 Figuur 4: Beknopt van database tot Presentatie .......................................................................................... 7 Figuur 5: Lagenmodel.................................................................................................................................... 8 Figuur 6: JSON in samenwerking met PHP en Javascript .............................................................................. 9 Figuur 7: Objectenstructuur........................................................................................................................ 15 Figuur 8: Product heeft vader- en kindproducten ...................................................................................... 15 Figuur 9: ProductEigenschap is een uitbreiding van eigenschap en bevat typeEigenschap ...................... 16 Figuur 10: Datastroom ................................................................................................................................ 18

4


1 Opdracht 1.1 Situering Op KIDS bevinden zich vele klaslokalen met hierin een groot aantal elektrische apparaten. Er werd een database-applicatie ontwikkeld om een overzicht te bewaren over de verschillende apparaten en hun locaties. De database moet ook in staat zijn gegevens over de apparaten zelf bij te houden.

1.2 Globale probleemstelling De opdracht van deze proef is dat er een databank of inventaris per lokaal gemaakt wordt waarin informatie terug te vinden is over alle aanwezige voorwerpen. Met behulp van een database kan men bijhouden welke voorwerpen zich in welk lokaal bevinden en welke voorwerpen aan elkaar gekoppeld zijn. Zo hoort bijvoorbeeld bij elke pc een muis en een toetsenbord en is ook elke pc gekoppeld aan een een bepaald lokaal.. Door alle gegevens die in de database staan, kunnen we controleren of er te veel of te weinig voorwerpen aanwezig zijn in een lokaal. De database houdt ook een geschiedenis bij van wijzigingen die aangebracht werden aan een object, hoe oud het object is en welke herstellingen het object heeft ondergaan. Het geheel is abstract ontworpen zodat het niet enkel computers en toebehoren inventariseert. We kunnen alle voorwerpen opnemen in het systeem en voorzien van een barcode.

Gegevens

Database

Controle Logboek

Figuur 1: Gegevens in de database controleren

1.3 Doelstellingen De doelstelling van deze bachelorproef is het ontwerpen van een database die voorwerpen kan bijhouden met elk hun specifieke eigenschappen, logboek, herstellingen etc. Alle voorwerpen moeten eenvoudig op te vragen zijn uit de database aan de hand van een unieke barcode of de locatie van deze voorwerpen. De beste oplossing zou zijn dat men continu een verbinding heeft met een gemeenschappelijke database. Maar in KIDS is er geen mogelijkheid om overal draadloos internet te voorzien door de storingen die deze geeft bij de gehoorapparaten en andere draadloze toestellen van de kinderen. 5

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi Via meerdere laptops moet men voorwerpen kunnen wijzigen. Wanneer men een vaste connectie heeft kunnen al deze veranderingen gerepliceerd worden met de hoofdserver. Een belangrijk aspect bij de keuze van het databasetype is dus het kunnen uitvoeren van een correcte replicatie.

2. Werkplanning De werkplanning bestaat uit 3 grote delen. Ten eerste maken we een lastenboek. Vervolgens buigen we ons over het database-ontwerp, namelijk de keuze van het databasesysteem en het ER-schema. Tenslotte maken we de logica- en presentatielaag. 2.1 Lastenboek Het lastenboek is een soort van contract met de opdrachtgever waarin staat wat hij verwacht van het systeem. Hiermee voorkomen we latere discussies over het afgeleverd resultaat. Na de goedkeuring van dit lastenboek kunnen we aan de slag met het ontwerpen van het programma.

Lastenboek

Planning

Figuur 2: Planning volgt uit het lastenboek

In bijlage 1 vindt u het lastenboek dat we voorgesteld hebben aan KIDS. 2.2 Databaseontwerp Het databaseontwerp bestaat uit 2 grote delen. Namelijk de keuze welk databasesysteem we gaan gebruiken en het ER-schema opstellen. Bij de keuze van het databasesysteem dienen we rekening te houden met verschillende factoren. Ten eerste moet het systeem replicatie ondersteunen. Ten tweede staan we even stil bij de licentieprijzen. Als laatste bekijken we hoe deze keuze ook de keuze van het serversysteem beïnvloedt. Het ontwerp van het ER-schema geeft de tabellen met velden en de relaties tussen tabellen weer.

Database systeem

ERSchema

Database ontwerp

Figuur 3: Databaseontwerp volgt uit databasesysteem en ER-schema

6

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi Als databasesysteem kozen we voor MS SQL. De hoofdreden hiervoor is dat MS SQL goede replicatiemogelijkheden heeft. MS SQL is ook een marktleider is in zijn soort. Tenslotte wasPHP ook mogelijk in samenwerking met MS SQL. Bijlage 2 toont het ER-schema. 2.3 Logica en presentatie Met de logica- en presentatielaag bieden we de gebruiker de mogelijkheid om de database te beheren. Na de vraag van een gebruiker weet de logicalaag op welke plaats in de database hij de informatie moet ophalen. Hij vat deze gegevens samen en geeft deze door aan de presentatielaag die dit op zijn beurt op een overzichtelijk weergeeft aan de gebruiker.

Database

Logica

Presentatie

Figuur 4: Beknopt van database tot Presentatie

De opdracht was om de presentatielaag weer te kunnen geven in een webbrowser. We nemen aan dat deze geïnstalleerd is op de meeste computers. De gebruiker dient dus niet speciaal voor deze toepassing software te installeren. We gebruiken dan ook enkel HTML en Javascript. Voor de logicalaag kozen we voor PHP. Deze taal leunt dicht aan bij de programmeertalen die we al onderwezen kregen. PHP is ook geen al te moeilijke taal, en je vindt er veel documentatie over op het internet. Dit maakt de stap voor het aanleren van deze taal kleiner. Een streke troef van PHP is dat PHP uitstekend gebruikt kan worden in samenwerking met databasesystemen.

3. Lagenmodel We kunnen het volledig systeem opdelen in 5 lagen: de databaselaag, de database-abstractielaag, een laag met PHP- klassen en -functies, de JSON dataoverdracht en de DHTML-laag. Elke laag werkt onafhankelijk van de andere lagen zodat een laag gemakkelijk aangepast kan worden zonder daarbij andere lagen te moeten wijzigen. Zo is het bijvoorbeeld mogelijk dat je de PHP-laag gaat vervangen door een laag met een betere code of zelfs een andere programmeertaal.

7


DHTML JSON PHP klassen en functies database-abstractie database Figuur 5: Lagenmodel

3.1 Databaselaag In deze laag worden alle gegevens bijgehouden in een relationele database. Via sql is het mogelijk om commando’s te sturen naar deze laag. Hierdoor kunnen er gegevens uit de database gehaald worden. En kunnen ook gegevens opgeslagen worden in de database. Meer informatie vind je terug in het hoofdstuk database.

3.2 Database-abstractielaag Om niet gebonden te zijn aan één type database is er een abstractielaag voorzien. Hierdoor moet de bovenliggende PHP-laag niet aangepast worden als men een andere database wilt gebruiken. Via enkele instellingen in de abstractielaag is het mogelijk om vlot over te schakelen naar een andere database.

3.3 PHP-laag De PHP-laag vormt de link tussen de database-abstractielaag en de JSON-dataoverdracht. Hierbij worden er gegevens uit de database gehaald. Deze worden door middel van object georiënteerd programmeren omgezet in objecten. In de bovenliggende lagen worden deze objecten gebruikt.

3.4 JSON-laag JSON staat voor JavaScript Object Notation. Dit is een manier om data uit te wisselen tussen de server en de client.

8


PHP object

Javascript object

JSON

Figuur 6: JSON in samenwerking met PHP en Javascript

In combinatie met AJAX biedt dit een sterk geheel, dit leggen we verder uit in het hoofdstuk DHTML. Bij AJAX (Asynchronous Javascript And XML) verwacht je eerder XML, maar JSON is gemakkelijker te gebruiken voor deze toepassing dan XML. Omdat de gegevens uitgewisseld worden in de vorm van Javascript-expressies kunnen deze ingelezen worden in een script door de JSON-expressie te evalueren. Het resultaat hiervan kan je behandelen als dataobjecten, dit biedt een groot voordeel.

var myObject = eval('(' + myJSONtext + ')'); Er zijn voor de meeste programmeertalen functiebibliotheken beschikbaar voor het lezen en schrijven van JSON-expressies. Hierdoor hoeven we maar 1 functie te gebruiken om iets om te zetten naar JSON.

$return->id=”id01”; $return->naam=”naam01”; echo json_encode($return); Het object dat we de JSON-functie laten omzetten bevat precies de data die de javascript verwacht. Als dat niet zo is zal de javascript deze data niet behandelen. Zo een object is volgens de volgende structuur opgebouwd:

{

string

:

waarde

, Zodat je een volgende expressie kunt krijgen:

{"id":"id01","naam":"naam01"} Een object kan ook andere datatypes bevatten zoals een array:

9

}


[

waarde

]

, 3.5 DHTML Dynamic HTML is geen programmeertaal, maar een manier om dynamische en interactieve webpagina’s te maken. Het omvat HTML, JavaScript, DOM en CSS. Samen wordt dit een soort van programma dat in de browser draait. Het voordeel is dat je hiervoor niets extra moet installeren om het programma te gebruiken. De inhoud en het uiterlijk van de webpagina kunnen veranderen zonder dat de pagina herladen wordt. Een essentiële voorwaarde voor interactiviteit is dat de onderdelen (en de eigenschappen van elk onderdeel) van de webpagina afzonderlijk benaderd kunnen worden. Het World Wide Web Consortium (W3C) heeft daarom een standaard opgesteld onder de naam Document Object Model. Zo krijgen we een dynamische webpagina door:

HTML • De programeertaal HTML te gebruiken, en de standaarden volgen zodat het programma compatibel is op verschillende browsers.

CSS • De stijl van elementen wordt bepaald door CSS (Cascading Style Sheets)

Events • De elementen kunnen reageren op gebeurtenissen (events). Dit maakt het mogelijk dat het document kan reageren op acties van de gebruiker via muis en toetsenbord.

DOM • De elementen kunnen bereikt worden door het Document Object Model.

10


4. Database 4.1 Het ER-Schema 4.1.1 Product Het middelpunt van de database is de tabel “Product”. Hierin stelt iedere rij een fysisch voorwerp voor. De producten krijgen in deze tabel ook metteen een categorie. Die algemene informatie bevat voor dit product. Meer uitleg over categorie volgt in puntje 4.1.2. Alle producten hebben een status die weergeeft of een product bv. een reserveproduct is of niet meer in gebruik is. De status van een product wordt nooit verwijderd, enkel toegevoegd. Door dan te zoeken naar de laatst toegevoegde status kan men de huidige status vinden. Dit heeft als voordeel dat de dataseeen geschiedenis bijhoudt van de status van een product. De volgende tabel van product is de tabel “parent_product”. Hierin staan de lokaties van alle producten. Gaande van harde schijven die in een pc zitten tot lokalen van een gebouw. Net zoals bij de tabel “product_status_dienst” worden hier nooit rijen verwijderd enkel toegevoegd. De laatst toegevoegde rij is de huidige lokatie van een product. Om eigenschappen toe te voegen aan een product is er de tabel “product_eigenschap”. Hierin krijg je weer hetzelfde systeem als bij de vorige 2 tabellen. Namelijk dat de laatst toegevoegde eigenschap de meest recente is. Deze tabel zorgt er ook voor dat een eigenschap van de tabel “Eigenschap” meerdere malen opnieuw gebruikt kan worden. De 3 tabellen “parent_product”, “product_status_dienst” en “product_eigenschap” kunnen perfect gerepliceert worden zonder dat er gegevens verloren gaan. 4.1.2 Categorie De categorie is een leidraad voor de producten. Hierin zitten de instellingen van wat toegelaten is en wat niet alsook alle eigenschappen die een product kan hebben. Om alle categorieen overzichtelijk te houden. Hebben we gekozen voor een boomstructuur. De gebruiker bepaalt dan zelf hoe hij deze boom met alle categorieën opbouwt. De categorieboom heeft niets te maken met welke voorwerpen mogen voorkomen in andere voorwerpen. Deze controle staat namelijk in een andere tabel genaamd “Categorie is toegelaten”. Hier kan bijvoorbeeld het koppel ‘pc’ met parent ‘lokaal’ instaan wat wil zeggen dat een pc in een lokaal mag geplaatst worden. Om later te weten welke kolommen de gebruiker wil zien is er de tabel “zichtbare_eigenschappen”. In deze tabel staan de type eigenschappen die de gebruiker wil zien van een bepaalde categorie. Bij de categorie ‘pc’ kan je dan bijvoorbeeld de types ‘Lokaal Nr’, ‘PC Naam’, ‘Besturings Systeem’ en ‘HDD grootte’ zichtbaar maken. Merk op dat in deze tabel niet enkel type eigenschappen van de categorie ‘pc’ in staan maar ook type eigenschappen van andere categorieen zoals ‘lokaal’ en ‘harde schijf’.

11

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi Dit leidt ons naar de volgende tabel namelijk de tabel “type_eigenschap”. Ieder type behoort tot een categorie en bezit de instellingen van de eigenschappen van dit type. Bijvoorbeeld de eigenschappen van het type ‘barcode’ zijn uniek en worden verplicht in te vullen bij het aanmaken van een product. Ook kunnen de eigenschappen van een type de functie naam krijgen. Op verschillende plaatsen in de layout ga je dan deze naam te zien krijgen als identificatie voor een bepaald product. 4.1.3 Herstelling Een herstelling, zoals de naam het al laat vermoeden, houdt alle herstellingen bij. Iedere herstelling wordt uitgevoerd op een bepaald product door een bepaalde informaticus. Een herstelling heeft net zoals het product een status die aangeeft hoever het staat met een herstelling. En tenslotte kan je aan een herstelling informatie toevoegen in de tabel “Detail”.

4.2Vergelijking databasereplicatie Eén van de vereisten was dat het systeem continu moet kunnen blijven werken, ook als er geen connectie met de server is. Daarom hebben we gekozen om op iedere portable een database en een PHP-server te installeren. Hierdoor werken we volledig lokaal en is er geen behoefte aan ethernet. Nadien zorgen we met een juiste replicatie dat alle wijzigingen doorgestuurd worden naar alle databases. Deze replicatie moet voldoen aan bepaalde voorwaarden. We hebben de replicatie van verschillende databasesystemen getest vooraleer een keuze te maken. 4.2.1 Mysql replicatie Opstelling Het opstellen van de database gebeurde geheel via het ingeven van commando’s. Op het internet vind je vele tutorials die de werking hiervan uitleggen. Hoe repliceren De verbinding mag niet verbroken worden als de replicatie bezig is. Wanneer dit toch gebeurt, krijg je twee databases die niet langer identiek zijn. Wijzigingen die gedaan worden als er geen verbinding is worden namelijk niet meer gerepliceerd. Ook niet als de verbinding hersteld wordt. Toch loopt de replicatie niet vast. Dit probleem kan opgelost worden door eerst de replicatie te stoppen op beide databases alvorens de verbinding te verbreken. Dezelfde rij op meerdere database aanpassen Als in 2 verschillende databases dezelfde rij verwijderd wordt loopt de replicatie vast en moet handmatig het laatste “drop”-commando op beide masters overgeslagen worden. De replicatie probeert namelijk op beide databases een rij te verwijderen die niet meer bestaat.

12

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi Als dezelfde rij op 2 databases veranderd is, worden de veranderingen zowel van database 1 naar database 2 als van database 2 naar database 1 doorgestuurd. Beide databases krijgen tijdens de replicatie de waarde van de andere database door en hebben daardoor mogelijk niet meer dezelfde waarde. Meer dan 2 databases laten repliceren Bij Multimaster-replicatie met behulp van MySQL worden alle databases in een cirkel met elkaar verbonden waarbij de wijzigingen in een bepaalde richting doorgestuurd worden. Dit heeft tot gevolg dat de replicatie niet meer werkt indien men (zonder instellingen te veranderen) een database weg neemt. Ook als er een database bijgevoegd wordt moeten op de vorige evenals op de volgende database in de cirkel de instellingen aangepast worden. 4.2.2 Db4O replicatie Opstelling Bij Db4O komt er geen SQL meer aan te pas, alles is geprogrammeerd in Java. Ook is deze database geen gewone relationele database maar wel een objectgeoriënteerde database. Dit maakt het mogelijk Javaobjecten op te slaan in de database. Hoe repliceren Db4O doet enkel een replicatie als de gebruiker of het programma dat vraagt. Hierdoor kan je zonder problemen de verbinding verbreken tussen 2 databases. Moest je toch proberen te repliceren krijg je een TimeOut Exception. Dezelfde rij op meerdere database aanpassen Als men tijdens het repliceren probeert dezelfde rij op 2 databases te veranderen zal de replicatie niet lukken en krijg je een Exception. Hiervoor zijn er al een aantal oplossingen voorzien die eenvoudig te programmeren zijn zoals het consequent overschrijven van links naar rechts of omgekeerd, het object overslaan of de replicatie stoppen. Maar hier kan men ook persoonlijke code aan toevoegen die doorlopen wordt wanneer er een fout optreedt. Meer dan 2 databases laten repliceren Om een nieuwe laptop te configureren voor replicatie bij MySQL moeten we een aantal instellingen veranderen. Bij Db4O zijn er zowel op de laptop als op de server geen instellingen nodig. Bij de eerste replicatie wordt alles in orde gebracht. Het gebruik van meer dan één portable is bij dit systeem geen probleem.

13

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi 4.2.3 MS SQL Opstelling Het instellen van MS SQL verschilt veel van de voorgaande omdat men hier werkt met een grafische omgeving. Om een SQL-server in te stellen en de database te repliceren is er een wizard aanwezig. Nadat hier enkele instellingen ingegeven zijn is de database ingesteld. Hoe repliceren De werking heeft enkele gelijkenissen met Db4O. Bij MS SQL gebeurt pas replicatie als de gebruiker dat beslist. Er is dus geen probleem als de verbinding verbroken wordt. Dezelfde rij op meerdere database aanpassen Wanneer bij MS SQL op 2 verschillende databases dezelfde rij veranderd is krijgt de laatst gewijzigde rij voorrang. De replicatie geeft wel een melding dat er een conflict is geweest maar met de standaard instellingen loopt de replicatie gewoon door. Als je 2 keer dezelfde rij gaat verwijderen is er geen probleem. Meer dan 2 databases laten repliceren Replicatie bij MS SQL werkt met 2 leden. Namelijk één of meerdere subscribers en een publisher. De publisher is meestal een vaste server die vaak online is. Subscribers zijn pc's die willen repliceren met de publisher. Meerdere portables configureren is bij MS SQL geen probleem.

5. Klassen en functies De PHP-laag vormt de link tussen de database-abstractielaag en de JSON-dataoverdracht. Hierbij worden er gegevens uit de database gehaald en door middel van objectgeoriënteerd programmeren omgezet in objecten. In de bovenliggende lagen worden deze objecten gebruikt.

14


5.1 Opbouw klassen 5.1.1 Overzicht

Figuur 7: Objectenstructuur

Bovenstaand schema verduidelijkt de opbouw en de relaties van de klassen met elkaar. 5.1.2 Product Het beschouwde product bevat een aantal producteigenschappen en mogelijk een aantal herstellingen die het product heeft ondergaan.

Vaderproduct Product

Kindproduct

Kindproduct

Kindproduct

Figuur 8: Product heeft vader- en kindproducten

15

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi Een product behoort tot een categorie. Elk product heeft een vaderproduct en mogelijk meerdere kindproducten zoals weergegeven in bovenstaand schema. Een computer kan bijvoorbeeld als vaderproduct een klaslokaal hebben en als kindproducten een harde schijf en een muis. 5.1.3 Eigenschap De klasse eigenschap heeft een type eigenschap en een waarde. Bijvoorbeeld een eigenschap van een computer kan als type “Eigenaar” hebben en als waarde “Mr. Janssen”.

ProductEigenschap Is Eigenschap

heeft

TypeEigenschap

Figuur 9: ProductEigenschap is een uitbreiding van eigenschap en bevat typeEigenschap

ProductEigenschap is een uitbreiding van Eigenschap met als uitbreiding dat ProductEigenschap tot een vast product behoort. Op deze manier kunnen bepaalde TypeEigenschappen en eigenschappen hergebruikt worden en via een ProductEigenschap aan een Product toegewezen worden. Een bepaald TypeEigenschap met zijn bijhorende waarde worden samengebundeld in een object ProductEigenschap dat tot een bepaald product behoort. 5.1.4 Herstelling Een product kan meerdere herstellingen bevatten. Herstelling is een klasse die informatie bijhoudt over de informaticus die het product aan het herstellen is, de datum van herstelling, de status van de herstelling en enkele details over de herstelling zelf. 5.1.5 Categorie Elk product behoort tot een categorie maar ook een categorie kan tot een andere categorie behoren. Elke categorie moet dus bijhouden welke categorieën er wel of niet in toegelaten zijn. Bij de aanmaak van een nieuw product wordt gecontroleerd of de categorie van het beschouwde product tot een bepaalde geselecteerde categorie mag behoren of niet. Op die manier hoeft niet aan elk product meegegeven te worden in welke producten het mag behoren maar wordt dit bepaald aan de hand van zijn categorie en de categorie van zijn potentiële vadercategorie. Bijvoorbeeld mag product ‘PC1 ‘, die tot categorie ‘Computers’ behoort, een kindproduct zijn van product ‘B004’, die tot de categorie ‘Lokalen’ behoort. Computers zijn toegelaten in lokalen dus dit is toegestaan. Andersom zou B004 geen kindproduct van PC1 mogen worden want lokalen zijn niet toegelaten in computers.

16


5.2 Functies Bij de hierboven beschreven klassen behoren een aantal functies. Ten eerste zijn er functies aanwezig die data uit de database kunnen halen waarmee objecten gecreëerd kunnen worden. Dit gebeurt door functies van de database-abstractielaag te gebruiken in de PHP-laag. Nadat de nodige informatie van bijvoorbeeld een product uit de database gehaald is maakt de PHP-laag van deze informatie een object. Ten tweede is het nodig om informatie die door de gebruiker ingegeven wordt door te sturen naar de database. Van de ingegeven informatie wordt een object gemaakt, de data wordt doorgestuurd naar de database die aan het object een ID-nummer toewijst. Dit ID-nummer wordt teruggezonden naar de PHPlaag en toegevoegd aan het object. Om dit te doen wordt de functie Store() gebruikt. Deze functie gaat eerst na of het object dat opgeslagen gaat worden al bestaat. Het is namelijk niet de bedoeling dat als er een wijziging aan een product aangebracht wordt er dan een volledig nieuw product aangemaakt wordt. Dit zou de database op termijn veel te groot maken. Er zijn ook functies aanwezig die deze objecten kunnen manipuleren. Functies zoals setParent($parent) of setDate($date) kunnen de verschillende eigenschappen van een bepaald object aanpassen. Al deze functies worden gebruikt in de response-files waaraan de client vragen stelt en antwoorden krijgt in JSON.

5.3 Datastroom De data uit de request van de client naar de database en terug legt een lange weg af via verschillende objecten en functies. Aan de hand van het volgende schema leggen we een voorbeeld uit om deze datastroom te illustreren.

17


HTML

HTML

event

toon

Javascript functie

Javascript object

question

evalueren

AJAX

JSON

communiceert

communiceert

responsefile

responsefile

functies

return waarden

objecten

objecten

vraagt info

bouwt

databaselaag

databaselaag

query's

antwoord

database

database Figuur 10: Datastroom

Wanneer een gebruiker vraagt naar gegevens die in de database opgeslagen zijn, wordt zijn event behandeld met een javascript-functie. Deze start een AJAX-functie met bepaalde gegevens meegeleverd. De url die aangesproken wordt in deze AJAX-functie wijst naar een responsefile. Afhankelijk van de opgegeven gegevens gaat de responsefile functies oproepen en objecten aanmaken. De gegevens waaruit deze objecten zijn opgebouwd komen via een database laag uit de database. Aan het einde van dit proces worden de objecten in de responsefile omgezet in een JSON-expressie. Bij de gebruiker staat er ondertussen nog steeds een functie te wachten op het antwoord van de responsefile. Wanneer alles succesvol verloopt kan deze de bekomen JSON-expressie omzetten in een javascript-object en nadien wordt er weer een nieuwe functie opgeroepen, of verder gegaan met een vorige. In deze laatste functie kunnen gegevens worden geëvalueerd en op het scherm worden getoond.

18


6 Beveiliging De toepassing moet beveiligd worden tegen, al dan niet opzettelijke, toevoeging van foute informatie in de database. Deze vereiste hielden we in het achterhoofd tijdens het ontwikkelen van de toepassing. Ten eerste mag men pas toegang krijgen tot de gebruikersomgeving na een gebruikersauthenticatie. Een veel gebruikte oplossing hiervoor is een beveiliging met “htacces en htpasswd”. Maar dit is slechts een lichte vorm van beveiliging omdat de authenticatiedata niet versleuteld wordt verzonden. Werken met het HTTPS-protocol (Hypertext Transfer Protocol Secure) is hiervoor een mogelijke oplossing. Op basis van SSL (Secure Sockets Layer) wordt de data dan versleuteld verzonden. Ten tweede krijgt de gebruiker nooit de ID’s van de database te zien. Hoe minder een gebruiker van het systeem weet, hoe moeilijker het is om het systeem te misbruiken. De ID’s worden in de logicalaag omgezet in eenvoudigere ID’s. Deze vertalingen worden bijgehouden zodat dit ook in 2 richtingen werkt. Tenslotte worden de handelingen van de gebruiker zo veel mogelijk gecontroleerd op mogelijke fouten. Dit gebeurt zodat ook fouten die niet opzettelijk zijn opgevangen worden.

7 Gebruikersomgeving De gebruikersomgeving kan via een gewone browser bereikt worden door te surfen naar de localhost. Na een authenticatie krijgt de gebruiker toegang tot het hoofdscherm. Deze bevat een menu waarlangs de gebruiker door producten kan browsen en categorieën en producten toevoegen. Daarnaast kan de gebruiker eigenschappen, herstellingen en logboekgegevens bekijken en wijzigen. De broncode geeft hierover meer uitleg en is terug te vinden op de bijgeleverde cd-rom.

8 Resultaat Aan het begin van deze bachelor proef hadden we maar weinig basiskennis over dit onderwerp waardoor we onderweg vele problemen en hindernissen tegenkwamen. Oplossingen zoeken voor al deze problemen heeft ons zeer veel bijgeleerd. Al dit werk heeft geleid tot een basis waarop verdergebouwd kan worden. De database en het databaseontwerp zijn volledig afgewerkt. In de visualisatielaag zijn al enkele dingen volledig uitgewerkt maar deze laag moet nog uitgebreid worden. Het is al mogelijk te browsen door de producten die in de database staan, filteren op categorie, een categorie toevoegen, een product toevoegen en eigenschappen van een product bekijken. We hebben de bachelorproef ingenieus en groots aangepakt, maar misschien net iets te groot. Maar beter een goed doordacht geheel dan een systeem met een slechte ruggegraat waar niet verder aan gewerkt kan worden. Omdat we gekozen hebben om heel abstract te werken is de applicatie behoorlijk complex geworden. Langs de andere kant zorgt dit er wel voor dat de applicatie kan gebruikt worden 19

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi voor alle soorten van voorwerpen op te slaan. Ook hebben we een client-side application geschreven die met behulp van AJAX zorgt voor een responsieve, gebruiksvriendelijke interface. We zijn blij dat we deze ervaringen hebben kunnen opdoen. Deze ervaringen helpen ons voor een goede planning bij onze Masterproef. Ook hebben we onze vaardigheden in onderzoek, uitwerking, problemen oplossen, rapporteren en presenteren sterk kunnen trainen. Dit gaat ons zeker ten goede komen bij onze masterproef.

20


9 Bibliografie Hofstede, Gert-Jan, Databases ontwerpen: bouwen en gebruiken. Academic Service, Schoonhoven, 1997. Aerts, Kris, Gegevensbanken - analyse, ontwerp & implementatie. Bibeault, Bear & Katz, Yehuda, jQuery in Action. Manning. Pascarello, Eric, Ajax in action. Manning. www.json.org/ nl.wikipedia.org/wiki/Asynchronous_JavaScript_and_XML nl.wikipedia.org/wiki/JSON www.w3schools.com www.php.net www.dhtmlx.com www.db4o.com www.postgresonline.com/journal/index.php?/archives/51-Cross-Compare-of-SQL-Server,-MySQL,-andPostgreSQL.html dev.mysql.com/doc dev.mysql.com/doc/refman/5.1/en/replication.html

21


Bijlagen Bijlage 1: Lastenboek Bijlage 2: ER-schema database

Bijlage 1: Lastenboek Doelstelling: Het probleem bestaat erin dat er een databank of inventaris per lokaal gemaakt moet worden waar informatie in staat over alle aanwezige voorwerpen. Dit kan via een barcode ingevoerd worden of via een ander scansysteem. De gescande informatie wordt hierna gesynchroniseerd met een server. Per laptop moet men voorwerpen kunnen scannen en achteraf met de server repliceren. Draadloos werken zou teveel problemen geven. Een goed design is essentieel. Schematische voorstelling: Het geheel zal bestaan uit de database zelf waarin alle gegevens opgeslagen worden. Deze zal in MS SQL, MySQL, postgreSQL… gemaakt worden, ermee rekening houdend dat replicatieeigenschappen erg belangrijk zijn. Hierboven ligt de logicalaag. Hierin is de server aanwezig, deze wordt geschreven in PHP, ASP of JSP. De gebruikte taal zal gekozen worden aan de hand van webtoegankelijkheid. Als serverprogramma zal waarschijnlijk Apache gebruikt worden. Bij KIDS is er reeds een server aanwezig. Dit is een SQL server 2000. Deze zal waarschijnlijk in de toekomst naar versie 2008 geüpgraded worden.

Presentatie

Logica

Database-abstractielaag

Database

Als laatste komt de presentatielaag aan bod. Hierin is de interface aanwezig waarmee de gebruiker kan communiceren met de database. Deze zal in HTML geschreven worden met AJAX als tussenstation tussen HTML en PHP/ASP. Tussen de database en de logica kan eventueel nog een database-abstractielaag komen. Algemene werking: Er zal abstract gewerkt moeten worden zodat het gebruik van het project aangepast kan worden aan de toepassing waarvoor het gebruikt zal worden. Bij KIDS zal voornamelijk gewerkt worden met het inventariseren van computers met hun onderdelen per lokaal.

22

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi Scannen: Via labels die weergegeven zijn op de objecten in een kamer wordt een unieke code per object ingescand. Deze code wordt opgeslagen in de database en per gescand object worden de eigenschappen hiervan ingegeven. Als een voorwerp 2 keer gescand wordt moet dit gemeld worden door het programma. Anders komt een voorwerp dubbel in de database te staan met dezelfde ingescande code. Database: In de database worden gegevens van de verschillende objecten bijgehouden. Een goed design is hier heel belangrijk. Replicatie van 2 verschillende databanken is een belangrijk aspect. Hier moet rekening mee gehouden worden bij de keuze van server. Er wordt een primary key gebruikt als unieke code van elk object waarmee elk object gekenmerkt wordt. In de database wordt een geschiedenis bijgehouden van wijzigingen die aangebracht werden aan een object, hoe oud het object is en welke componenten bij het object horen (Bijvoorbeeld een muis die bij een computer hoort.) Dit wordt opgeslagen in een logboek dat per object bijgehouden wordt. Er moet een rapport weergegeven kunnen worden van de database dat weergeeft welke voorwerpen er ontbreken in een lokaal en welke er niet thuishoren. De mogelijkheid om een voorwerp dat in de ene kamer thuishoort in een andere kamer te gebruiken moet aanwezig zijn. Interface (GUI) In de interface kan men ingeven welke eigenschappen men per object wil bijhouden in de database. Daarom is het noodzakelijk dat de database abstract geprogrammeerd wordt. Een tafel heeft bijvoorbeeld andere eigenschappen dan een computer. In de interface kan een gebruiker zich inloggen en op deze manier de database bekijken of aanpassen. Er zijn gebruikers met verschillende rechten. Sommige gebruikers kunnen enkel de database bekijken, andere gebruikers kunnen zowel de database aanpassen als bezichtigen. Meerdere personen kunnen op hetzelfde moment de database wijzigen op de server via een browser op hun eigen computer. Maar het aanpassen van een record uit de database kan slechts door 1 gebruiker tegelijk gebeuren, anders gaan er interne conflicten optreden. Enkele aandachtspunten: - In het verleden is er reeds een database opgesteld maar deze is niet efficiënt ontworpen. Een volledig nieuw ontwerp is noodzakelijk. - Er moet rekening mee gehouden worden dat in de toekomst het project nog uitgebreid kan worden en voor verschillende toepassingen gebruikt kan worden. - Het budget is een belangrijk aandachtspunt. Er mogen niet nodeloos kosten gemaakt worden. 23

Databasesysteem voor het beheer van een schoolinventaris Konings Kristof, Narinx Hans, Sluismans Brecht, Tielens Jordi - Het geheel moet goed beveiligd zijn tegen personen die het systeem proberen te hacken.

24


Bijlage 2 ER-schema database

25

KHLim. Databasesysteem voor het beheer van een schoolinventaris

Recommend Documents