For at kunne holde styr på hvilke kunder og medarbejdere den enkelte bruger senest har brugt i systemet, og kunne vise priserne på alle Oracle's produkter, er det nødvendigt at oprette nogle tabeller i MAOV databasen, hvor disse oplysninger kan gemmes.
Om den enkelte bruger skal der kunne gemmes hvilke medarbejdere og kunder, brugeren senest har søgt og følgende valgt. I prislistens tilfælde så er det priserne for de enkelte produkter, samt hvilken produktgruppe produktet tilhører, som skal kunne gemmes. Udover dette så skal alle typer action-points også kunne gemmes, så det er nemt at slette/tilføje action-points. Hvor mange tabeller det drejer sig om, og hvordan de skal designes vil blive beskrevet i dette afsnit.
Når en bruger har søgt og valgt en medarbejder, så skal medarbejderen gemmes i en tabel, sådan at når brugeren igen vælger menupunktet medarbejdere, så vil denne medarbejder blive listet op. Begrundelsen for denne funktionalitet, er at tidligere valgte medarbejdere typisk skal vælges igen. Det vil dog ikke være alle medarbejdere brugeren tidligere har valgt, som vil blive listet op, da dette meget hurtigt kan blive en lang liste. Men det vil dreje sig om de seneste 10 medarbejdere. Tallet 10 er vi kommet frem til ud fra en praktisk betragtning og ved snak med forskellige brugere, dvs. hvor mange personer er det egentlig relevant at gemme. Det tal vi landede på var 10, men det vil da være muligt at ændre dette tal senere hvis det bliver relevant.
De oplysninger der skal gemmes i en tabel for at få denne funktionalitet er: brugerens ID, medarbejderens ID og navn, samt et tidsstempel for hvornår medarbejderen blev valgt. Dette betyder at tabellen kommer til at bestå af 4 attributter. Attributten "userID" er brugerens ID, og den er samtidig primærnøgle, dvs. ud fra dette ID kan man finde de medarbejdere brugeren tidligere har valgt. Attributten "searchedForID" er medarbejderens ID, og skal bruges når der skal hentes oplysninger om denne medarbejder fra medarbejder tabellen. Attributten "searchedForName" er medarbejderens navn, og er det navn der kommer til at stå i listen. Attributten "timestamp" er det tidsstempel der bliver noteret når brugeren vælger en medarbejder, og bruges når de seneste medarbejdere skal findes frem.
Datatyperne for de enkelte attributter er ikke grebet ud af den blå luft, men er identiske med de tilsvarende attributter der eksisterer i Oracle's databaser. Dette skulle de også helst være, da der ellers kunne opstå problemer i bl.a en WHERE betingelse, f.eks hvis et ID blev til en varchar2, men oprindelig er et number.
Vi vælger at kalde tabellen for "RecentEmpSearch". Herunder er tabellen vist med attributter og tilhørende datatyper.
RecentEmpSearch - userID varchar2(19) - searchedForID number(19) - searchedForName varchar2(35) - timestamp date
Begrundelsen for at lave denne funktionalitet, er den samme som med medarbejdere, dvs. at tidligere valgte kunder typisk skal vælges igen. Det antal kunder som skal gemmes og listes op er det samme som for medarbejdere, altså 10. Og igen så kan dette tal senere ændres hvis det bliver relevant.
I denne tabel er der lidt flere oplysninger som skal gemmes, end der var for medarbejdertabellen. Det er fordi det tager noget længere tid at hente en kundes oplysninger op af databasen, og det kan derfor betale sig at gøre dette samtidig med søgningen. Når så den enkelte kunde vælges, så er oplysninger allerede hentet. Og det er disse oplysninger der også skal gemmes i tabellen. Derfor får tabellen hele 8 attributter, som er brugerens ID, kundens to ID'er (forskellige for hvilken Oracle database det drejer sig om), kundens stamoplysninger (navn, vej, by og telefonnummer) og et tidsstempel for hvornår kunden blev valgt.
Attributten "userID" er brugerens ID, og den er samtidig primærnøgle, dvs. ud fra dette ID kan man finde de kunder brugeren tidligere har valgt. Attributterne "searchedForID" og "searchedForCDMID" er kundens to ID'er, og skal bruges når der skal hentes diverse oplysninger om denne kunde fra Oracle's databaser. Attributterne "searchedForName", "custAddr1", "custTown" og "custPhone" er kundens stamoplysninger. Attributten "timestamp" er det tidsstempel der bliver noteret når brugeren vælger en kunde og bruges når de seneste kunder skal findes frem.Datatyperne for de enkelte attributter er igen fuldt identiske med de tilsvarende attributter der eksisterer i Oracle's databaser.
Vi vælger at kalde tabellen for "RecentCustSearch". Herunder er tabellen vist med attributter og tilhørende datatyper.
RecentCustSearch - userID varchar2(19) - searchedForID number(19) - searchedForCDMID varchar2(19) - searchedForName varchar2(35) - custAddr1 varchar2(35) - custTown varchar2(30) - custPhone varchar2(20) - timestamp date
Prislisten består af nogle produktgrupper, hvorunder de produkter og priser tilhørende denne produktgruppe står. Endvidere så skal der på forsiden af prislisten, der hvor produktgrupperne er listet op, stå som overskrift hvilken dato prislisten er fra. Udfra denne opbygning vælger vi at repræsentere prislisten ved tre tabeller: en til opstartsteksten, en til de enkelte produkter, og en til produktgrupperne.
Opstartsteksten: Denne tabel kalder vi for "pricelist_startuptext", og den får kun een attribut med navnet "startuptext", der er af datatypen varchar2 med en maksimal størrelse på 40 karakterer. Den vil kun komme til at indeholde een tupel, dvs. hver gang prislisten opdateres, så overskrives denne attribut med den nye dato for den aktuelle prisliste.
De enkelte produkter: Denne tabel kalder vi for "pricelist_details", og den kommer til at indeholde 6 attributter. Et produktgruppeID, et produktnavn og 4 priser. Attributten "id" er produktets gruppeID, dvs. den er fremmednøgle til produktgruppetabellen, og er af datatypen number. Attributten "productname" er navnet på produktet, og er af datatypen varchar2 med en maksimal størrelse på 50 karakterer. Attributterne "nuss", "nums", "upu" og "license" er produktets forskellige priser, og de er alle af datatypen number.
Produktgrupperne: Denne tabel kalder vi for "pricelist_groups", og den kommer til at indeholde to attributter. Et ID for hver produktgruppe og et produktgruppenavn. Attributten "id" er produktgruppens ID, den er primærnøgle og er af datatypen number. Attributten "groupname" er navnet på produktgruppen, og er af datatypen varchar2 med en maksimal størrelse på 30 karakterer.
Herunder er de tre tabeller vist med attributter og tilhørende datatyper.
pricelist_startuptext - startuptext varchar2(40) pricelist_details - id number not null (pricelist_groups.id) - productname varchar2(50) not null - nuss number (Named User Single Server) - nums number (Named User Multi Server) - upu number (Universal Power Unit) - license number (Price for one license) pricelist_groups - id number not null - groupname varchar2(30) not null
De action-points, som det skal være muligt at sende, skal hentes fra en tabel. Begrundelsen for at lægge dem i en tabel, er at man nemt kan slette/tilføje action-points, samt redigere dem. Hvis de istedet havde været hardkodet, så ville dette være meget besværligt at gøre, da dette kræver at man skal direkte ind i koden og ændre det, hvilket ikke er hensigtsmæssigt.
Et action-point består af en overskrift og en beskrivelse, og vil blive sendt som en e-mail, det er derfor naturligt at tabellen får to attributter. Vi vælger meget nærliggende at kalde tabellen "ActionPoints", og attributterne for "subject" og "body". Attributten "subject" bliver en varchar2 på masimalt 30 karakterer, dette skulle give plads nok til at skrive en sigende overskrift og den vil samtidig heller ikke fylde for meget af WAP-telefonens display (dvs. maks 2 linjer). Attributten "body" bliver en varchar2 på maksimalt 250 karakterer, dette skulle være nok til en kortfattet beskrivelse. Herunder er tabellen vist med attributter og tilhørende datatyper.
ActionPoints - subject varchar2(30) - body varchar2(250)
Figuren herunder viser hvordan de forskellige tabeller linkes sammen.
Denne gennemgang skulle meget gerne have givet et indblik i hvordan MAOV's egne tabeller er tænkt designet og begrundelsen herfor.