Studenten: begeleider



Dovnload 81.3 Kb.
Datum24.08.2016
Grootte81.3 Kb.


D
EPARTEMENT BEDRIJFSINFORMATIE

Schoonmeersstraat 52

9000 GENT
ACADEMIEJAAR 2007-2008

Rapport

STUDENTEN: BEGELEIDER:

Cantaert Joachim Derwael Cecilia

De Vos Bart

Valcke Denis

VOORWOORD
Toen op dinsdag 29 januari, na ons laatste examen, een algemene briefing plaatsvond over de projecten werd ons al heel snel duidelijk wat zo’n project nu eigenlijk inhield. Zo kregen we onder andere te horen van mevrouw Vuyge dat er naast een informaticaluik ook nog drie taalluiken zijn waaraan we moeten voldoen.

Daarnaast kregen we de mogelijkheid om te kiezen uit volgende drie projecten:



  • vliegtuigreservaties

  • hotelboekingen

  • autoverhuur.

Na enige tijd overleggen met elkaar kozen we alvast voor het thema hotelboekingen.

Bij dit thema bestond de opdracht erin een uitgebreid programma ‘BINFSea Booking’ te creëren dat medewerkers van hotel BINFSea zou moeten helpen om gegevens vlotter en efficiënter te kunnen beheren. Men verwacht dus uiteindelijk een soort van geautomatiseerd reserveringssysteem.
Het programmeren van zo’n reserveringssysteem wordt voorafgegaan door een hele reeks stappen. Dit is natuurlijk een hele klus en daarom is dit rapport dan ook geen overbodige luxe om alle realisaties stapsgewijs bij te houden die zullen moeten leiden tot een geslaagd eindresultaat.
Tot slot hopen we aan alle verwachtingen van dit rapport te kunnen voldoen


INHOUDSOPGAVE

INLEIDING
In het kader van ons project hotelboekingen werd ons al snel duidelijk dat een uitgebreid rapport een absolute must is om tot het gewenste eindresultaat te komen, namelijk een nieuw geautomatiseerd reserveringssysteem.
De aanleiding tot het programmeren van dit geautomatiseerde reserveringssysteem kwam er op vraag van het hotel BINFSea. Tot op de dag van vandaag werden reserveringen daar nog steeds manueel gedaan en bijgehouden op papier. Dit is in deze moderne tijd nog amper een denkbare, laat staan efficiënte manier om allerlei gegevens bij te houden.

Bovendien gaf dit onflexibel systeem aanleiding tot fouten zoals dubbele boekingen en verdwenen regelmatig gegevens van ondermeer klanten, kamers enz.

Daarnaast zorgde dit alles voor wrevel bij zowel bestaande als potentiële klanten en werd de samenwerking met reisbureaus belemmerd.

Er was dus dringend nood aan een nieuw geautomatiseerd reserveringsysteem zodat men aan klanten een vlotte en correcte service kan bieden. Verder zou dit systeem de inkomsten moeten verhogen en de groei van BINFSea bevorderen.

‘BINFSea Booking’ is een programma dat de medewerkers van BINFSea zou moeten helpen om gegevens vlotter en efficiënter te beheren.
Ons programma beschikt daarom over de volgende 4 mogelijkheden:


  • Ten eerste is er de mogelijkheid om gegevens van klanten op een eenvoudige en overzichtelijke wijze te beheren, indien gewenst kan men gegevens toevoegen, aanpassen of verwijderen.

  • Ten tweede kunnen kamers evenwel in het programma beheerd worden, men kan kamers toevoegen, verwijderen en indien gewenst voor een bepaalde tijd onbeschikbaar maken.

Er zijn verschillende kamertypes in BINFSea, de meest voorkomende zijn kamers van het type ‘Twin’ en ‘King’, dit zijn tweepersoonskamers. Sommigen hebben zicht op zee, anderen hebben deze luxe dan weer niet. Dit moet dus een van de selecteerbare opties zijn bij het boeken van een kamer.

  • Ten derde bestaat ook de mogelijkheid een reservatie te maken, er kan onmiddellijk een offerte opgesteld worden met de prijs voor het verblijf; incl. BTW en andere kosten en toeslagen. De prijs hangt natuurlijk af van het gekozen kampertype en sanitair, de boekingsperiode, (optioneel) ontbijt, halfpension of volpension en de (optionele) annuleringsverzekering.

Men is overigens ook in staat om een kamer te boeken voor een gevraagde periode of een bepaalde reservatie te annuleren (hierbij worden eventueel kosten aangerekend).

  • Ten slotte wordt na bevestiging van de reservatie een factuur opgemaakt met een detail van alle bij reservering aangerekende kosten (kamer, opties, …) en duidelijke opgave van alle bedragen zonder BTW en aangerekende BTW, die naar de desbetreffende klant kan gestuurd worden.

Wanneer het hotel een bepaald bedrag moet terugbetalen omwille van een annulering wordt een gedetailleerde creditnota opgemaakt.

Bovendien is ons programma beschikbaar in drie talen: Nederlands, Frans en Engels.


In dit rapport belichten we alle stappen die moeten leiden tot het eindresultaat.

Zo beginnen we eerst met het verzamelen van de benodigde informatie, gevolgd door een uitvoerige analyse van het probleem. Daarna zullen we aan de hand van deze informatie een ER-diagram opstellen met de bedoeling een overzichtelijke structuur te creëren van bestaande gegevens.

Deze gegevens worden dan stap voor stap geïmplementeerd in een Access-database.

Vervolgens beginnen we met het belangrijkste deel, het programmeren. Dit begint met het maken van een degelijk ontwerp. De termen packages, GUI, domein en persistentie die hierbij komen kijken zullen we stapsgewijs vermelden en gedetailleerd beschrijven.

Als laatste testen we of ons programma wel degelijk werkt en of het aan voorgeschreven eisen voldoet, ook volgt er nog een korte conclusie met een bijhorende evaluatie.

1 ERD
1.1 Wat is een ERD?
ERD staat letterlijk voor Entity-Relationship-diagram, soms gebruikt men ook wel de term Entity-Relationship-model.

Een ERD is dus een diagram of datamodel dat een grafische weergave vormt voor een hele reeks gegevens. Bedoeling is om eenvoudig en snel inzicht te krijgen in de benodigde informatie door verbanden tussen gegevens visueel weer te geven. Vervolgens kan dit ERD desgewenst omgezet worden in een relationeel model om dan uiteindelijk geïmplementeerd te worden in een database (= databank).


1.2 De werking van een ERD-diagram
De bouwstenen van een ERD zijn voornamelijk enerzijds entiteittypen en attribuuttypen en anderzijds relationshiptypen met (eventuele) attribuuttypen.
Een entiteittype is een verzameling van gelijksoortige entiteiten. Entiteiten zijn objecten uit de werkelijkheid waarover wij gegevens willen verzamelen. Een entiteit kan zowel een object zijn dat fysiek bestaat (een klant, een factuur) als een object dat enkel conceptueel bestaat (een aanspreekvorm, een job).

Entiteiten kunnen bijgevolg ook beschikken over kenmerken of eigenschappen die men attributen noemt en zijn dus een individueel voorkomen van een of ander object.

Zo is een attribuuttype op zijn plaats de verzameling van gelijksoortige attributen.

De waarden van deze attributen zijn uiteindelijk de gegevens die zullen terechtkomen in een databank.


1.2.1 Ter verduidelijking:

KLANT


1, Dhr., De Vos, Bart, Nashuatec, 004-4547BR, Stationsstraat, 220, 1700, Dilbeek, België, +32 2 466 02 12, …



Attributen gescheiden door komma’s. Zo is bijvoorbeeld België een attribuut van het attribuuttype land.

Dit is een entiteit van het entiteittype KLANT.


1.3 Voorstelling van de elementen in een ERD

e

ntiteittype





attribuuttype

0..1

0..n

relationshiptype (verzameling van gelijksoortige verbanden) tussen entiteittypen

1.3.1 Cardinaliteit


Zoals hierboven is weergegeven heeft een relatie in een relatietype twee rollen, elk met een unieke (optionele) rolnaam: de ene gaat van links naar rechts, de andere omgekeerd. Een rol heeft een multipliciteit die wordt aangeduid met een cardinaliteitsratio.
Er bestaan 4 cardinaliteitsratio’s:
0..1 = minimale cardinaliteit 0 maximale cardinaliteit 1

0..n = minimale cardinaliteit 0 maximale cardinaliteit n

1..1 = minimale cardinaliteit 1 maximale cardinaliteit 1

1..n = minimale cardinaliteit 1 maximale cardinaliteit n
Minimale cardinaliteit 1 betekent concreet dat er een verplichte deelname is aan de relatie van elke entiteit. Als ze de waarde 0 heeft dan spreekt men van een optionele deelname.

Maximale cardinaliteit 1 betekent dat met een entiteittype maximaal 1 ander entiteittype mag zijn gekoppeld. Heeft ze de waarde n dan mag een entiteittype met een onbepaald aantal entiteittypen zijn gekoppeld.


1.4 Voorbeeld uit ons project
Uit het schema hierboven kan men nu volgende zaken afleiden:


  • Er bestaat een relatie tussen de entiteittypen klant en aanspreekvorm.

  • Zowel klant als aanspreekvorm hebben naast hun gewone attribuuttypen ook één onderstreept attribuuttype id, dit attribuuttype noemt men een sleutelattribuuttype. De waarde van deze sleutel laat een entiteit toe om zich op een unieke manier te onderscheiden van een andere entiteit en wordt dus gebruikt als unieke identificatie.

  • Entiteittype klant heeft minimale cardinaliteit 1 en maximale cardinaliteit n (een aanspreekvorm is bestaansafhankelijk van een klant en met één aanspreekvorm kunnen meerde klanten overeenkomen).

  • Entiteittype aanspreekvorm heeft een minimale cardinaliteit 1 en een maximale cardinaliteit 1 (een klant kan minimaal 1 en maximaal 1 aanspreekvorm hebben, vb. een persoon heeft ofwel de aanspreekvorm Mr. ofwel de aanspreekvorm Mevr.).

2 EERD
2.1 Wat is een EERD?
Een EERD of Enhanced Entity-Relationship-model is een uitbreiding van het klassieke ERD. Het gebruikt de bouwstenen van een ER-model en voegt een aantal abstracties toe zodat meer betekenisaspecten van gegevens kunnen gemodelleerd worden.
2.2 Voorbeeld uit ons project

Uit bovenstaande afbeelding kan men concluderen dat entiteittypen verzekering, catering en zeezicht de subklassen zijn van superklasse en entiteittype optie.

Het entiteittype optie werd met andere woorden gespecialiseerd in entiteittypen verzekering, catering en zeezicht, dit brengt met zich mee dat deze subklassen alle attributen erven van hun superklasse (als het entiteittype optie attributen zou hebben dan erft elke subklasse deze attributen).
Voor de afbeelding van superklasse-/subklasseverbanden bestaat er ook nog een grafisch formalisme dat resulteert in 4 verschillende soorten van specialisaties:


  • disjunct-totaal

  • disjunct-partieel

  • overlap-totaal

  • overlap-partieel.

Op bovenstaand EERD hebben we dus een disjuncte, totale specialisatie, dit betekent dat een entiteit of tot de ene subklasse of tot een andere subklasse behoort (disjunct). Een entiteit van het entiteittype optie kan niet zowel tot ‘verzekering’ als tot ‘catering’ behoren.



Totaal: elke entiteit uit superklasse optie behoort tot één of meerdere subklassen.

Bijgevolg betekent overlap dat een entiteit tot meerdere subklassen kan behoren. Partieel wijst erop dat er entiteiten in de superklasse kunnen zijn die niet tot één van de subklassen behoren.


Het volledige EERD bevind zich in de bijlage op pagina (dient nog ingevuld te worden), merk op dat in het kader rechtsonder enkele attributen van de entiteiten klant en kamertype verder verfijnd zijn, reden hiervoor was om de overzichtelijkheid van het datamodel te behouden.

3 HET RELATIONELE MODEL
3.1 Wat is een relationeel model?
Een relationeel model wordt in tegenstelling tot een (E)ERD niet meer grafisch voorgesteld. Bij het maken van een relationeel gegevensmodel leunen we echter wel op de kennis van een (E)ERD.
3.2 Wat is het doel?
Een relationeel model wordt als tussenstap gebruikt om een (E)ERD te kunnen implementeren in een databank. In een relationeel model worden relaties genormaliseerd zodanig dat er geen anomalieën kunnen optreden.

3.3 De bouwstenen


Een relationeel model wordt gekenmerkt door tupels, relaties, attribuuttypen, attribuutwaarden en domeinen

Tupels zijn niets minder dan entiteiten of geordende lijsten met attribuutwaarden en een relatie is een verzameling van tupels.

Een domein is een verzameling van waarden die voor de attributen in tupels van een relatie worden gebruikt.


3.3.1 Ter verduidelijking:
KLANT (entiteittype)


Id

Aanspreekvorm

Naam

Voornaam

Bedrijf

Ondernemingsnummer

Straat

Nummer



1

Dhr.

De Vos

Bart

Nashuatec

004-4547BR

Stationsstraat

220



2
























3

























attribuutwaarde domein relatie tupel

(met aanspreekvorm als attribuuttype)
3.4 Genormaliseerde relaties
Relaties hebben op zichzelf allerlei eigenschappen: elke tupel moet uniek zijn (primaire sleutel), er mogen enkel ondeelbare attribuutwaarden voorkomen, de volgorde van tupels is niet relevant, enzovoort.

Relaties in een relationeel moeten echter ook voldoen aan een extra eigenschap: ze moeten zijn genormaliseerd.


Normaliseren is een stapsgewijs proces dat op een verzameling van relaties wordt toegepast met als doel hun attribuuttypen te verdelen over de relaties, zodanig dat het model geen tegenstrijdigheden of overtolligheden bevat en dus ook geen anomalieën veroorzaakt.
3.5 Voorbeeld uit ons project
Het normalisatieproces wordt opgedeeld in 4 stappen.
Moet nog uitgewerkt worden

4 DATABASEMANEGEMENTSYSTEMEN (DBMS)
4.1 Wat is een databasemanagementsysteem?
Een databasemanagementsysteem is een programma waarmee we een databank kunnen aanleggen met de gegevens die afkomstig zijn uit ons relationeel model.

Een database of databank is een verzameling van gegevens met een bepaalde betekenis voor een bepaalde groep van gebruikers.


4.2 DBMS in ons project
Er bestaan talrijke databasemanagementsystemen in de praktijk. Het DBMS dat wij gaan gebruiken in ons project is Microsoft Access 2003 omdat dit een zeer gebruiksvriendelijk programma is.
4.2.1 Waarom gebruiken we een DBMS?
Een DBMS heeft heel veel voordelen, in de eerste plaats laat het ons toe om gegevens op een eenvoudige en efficiënte wijze te beheren.

Om gegevens te kunnen raadplegen passeren we altijd via het DBMS, door de databasegerichte benadering is er geen rechtstreekse toegang mogelijk tot de eigenlijke gegevens in de databank. Hierdoor krijgen we de mogelijkheid om gegevens op onze gewenste manier te bekijken. Daarnaast kunnen we gegevens opvragen, wijzigen, verwijderen, afdrukken, enzovoort.


Onze bedoeling is nu om in Access een databank aan te leggen, zodat we essentiële hotelgegevens zoals klanten, kamers, facturen, offertes, creditnota’s, … kunnen opslaan en beheren.

We kunnen evenwel een lijst van aanwezige klanten en beschikbare/ bezette kamers laten weergeven en deze dan vervolgens laten afdrukken. Je ziet het al: er zijn ontzettend veel mogelijkheden.

Indien er een fout is geboekt of als het adres van een specifieke klant verandert is, kunnen we dit m.b.v. Access makkelijk en snel aanpassen.
Verder heeft Access ook als voordelen: gegevensbeveiliging, back-up en recovery, performantie, flexibiliteit, het beheren van de redundantie en integriteit van gegevens.



      1. Voorbeeld van databank ‘BINFSea Booking’ uit ons project


Moet nog uitgewerkt worden








BESLUIT

EVALUATIE

BIBLIOGRAFIE

BIJLAGE




Woordenlijst ‘schermen’:
1. Lijst van klanten, kamers,… weergeven

2. klikken op

3. openen

4. sluiten, afsluiten

5. opslaan

6. verwijderen

7. toevoegen van klanten, kamers,…

8. afdrukken, printen

9. annuleren

10. reserveren

11. de kamerlijst

12. het referentienummer

13. een e-mailbericht

14. een wachtwoord

15. bevestigen

16. een overzicht

17. een kamer

18. de rekening

19. het tarief

20. personalia, gegevens

21. toevoegen (aan)

22. beschikbaar

23. vrij, onbezet

24. bezet

25. gereserveerd

26. selecteren, uitkiezen

27. de aankomstdatum

28. de vertrekdatum

29. het kamertype

30. kamer met zicht op

31. een kalender

32. het ontbijt

33. een half pension

34. een vol pension

35. verblijfsbelasting

36. de verblijf(plaats)

37. factureren

38. de faciliteiten

39. de leverancier

40. inschrijven

41. de diensten

42. het plan van de ligging








De database wordt beschermd door het auteursrecht ©opleid.info 2017
stuur bericht

    Hoofdpagina