MAOV-systemet skal tilgå en hel del af Oracle's eksisterende databaser, samt MAOV's egen database. I dette afsnit vil samtlige af Oracle's databaser, som MAOV-systemet tilgår, blive beskrevet. Beskrivelsen vil indeholde hvordan de enkelte databaser tilgås, hvilke tabeller og attributter der er interessante, og hvordan de hænger sammen. I det efterfølgende afsnit vil MAOV's egen database og tabeller blive beskrevet.
Inden gennemgangen skal det nævnes at der ikke er direkte adgang til hver enkelt af de forskellige af Oracle's databaser. Det foregår istedet via MAOV's egen database. Det vil sige at der i MAOV databasen er oprettet nogle db-links til de relevante databaser. Disse db-links giver kun læserettigheder, mens der er fuld læse/skrive-rettigheder til MAOV's egen database.
De Oracle databaser og tabeller, som MAOV-systemet skal tilgå, er naturligvis bestemt af funktionsafgrænsningen. Som før nævnt, tilgår MAOV-systemet de enkelte databaser, via db-links som er oprettet i MAOV's egen database. Databaser der er oprettet db-links på er: prod, cdm og sms. I prod databasen er de relevante tabeller: hrv_people_info, ra_customers og product_license. I cdm databasen er de relevante tabeller: cdmcomp, cdmpcode, cdmcont og cdmacti. Og i sms databasen er de relevante tabeller: tar_head og tar_status.
De databaser og tabeller nævnt ovenfor har ikke været lige nemme at finde frem til. Det har krævet en hel del analyse arbejde, og snak frem og tilbage med Asger Jensen, Rasmus Menche og Bo Nielsen (se mødereferat X X X side XXX).
For at oprette et db-link, skal der i den database man vil have adgang til, være oprettet en bruger man kan benytte. I vores tilfælde blev der oprettet en bruger i hver at de tre databaser, som det så var muligt at benytte. Når db-linket er oprettet, så har man præcis de samme rettigheder som den bruger man benytter. I vores tilfælde kun læserettigheder. Brugeren som db-linket benytter, kan yderligere have adgang til diverse skemaer i den specifikke database. Det var tilfældet med "prod" og "cdm" databaserne.
Måden man får adgang til en tabel på via et db-link foregår på følgende måde:
Dvs. hvis man skal tilgå tabellen ra_customers i prod databasen, som ligger i skemaet oradk, så ser det således ud:
Herunder er en komplet oversigt over hvordan de forskellige tabeller tilgåes, bemærk at der ikke er specificeret et skemanavn til sms databasen, da det ikke er nødvendigt.
De enkelte databaser og tabeller beskrives i de følgende afsnit. Men inden denne gennemgang er der to tabeller, der kræver en særlig forklaring. Det drejer sig om "ra_customers" og "cdmcomp" fra hver deres database, som begge indeholder kunde-oplysninger.
For at hente oplysninger om en kundes licenser og TAR's kræver det at man bruger kundeID'et fra "ra_customers" tabellen, og for at hente oplysninger om en kundes aktiviteter og kontakter kræver det at man bruger kundeID'et fra "cdmcomp" tabellen. Dette er heller ikke noget problem, da de to tabeller kan linkes sammen (ra_customers.customer_number = cdmcomp.oldoracleid), men det viste sig at det ikke var muligt at linke alle kunder sammen. Dette skyldes at Oracle for ikke så lang tid siden har flyttet deres kundedata over i nogle nye tabeller. Dvs. at kunder der bliver oprettet herefter ikke får et "oldoracleid" i "cdmcomp" tabellen, og dette gør at det ikke er muligt at få fat i begge ID'er, hvilket der er krævet for at vise alle oplysninger om en kunde.
Vi vælger tabellen "ra_customers", som indgang til kunden, dvs. når man søger en kunde så er det i denne tabel kunden bliver søgt. Dette gør at når "oldoracleid" i "cdmcomp" er tom, så er det kun muligt at få kundeID'et fra "ra_customers", hvilket som før nævnt, gør at man kun kan se licens og TAR oplysninger om kunden. Begrundelsen for dette valg, er at oplysninger om en kundes licenser og TAR's er dem der har størst værdi for brugerne, og de vil på denne måde altid være tilgængelige.
I denne database står oplysninger om de enkelte kunder og hvilke produkter de har licens til. Desuden står der også oplysninger om alle medarbejdere. De tre relevante tabeller og de attributter MAOV-systemet bruger er beskrevet nedenfor.
Tabellen "hrv_people_info" indeholder medarbejder oplysninger. Når en medarbejder skal findes ved hjælp af den indtastede søgestreg, så er det attributten "keystring", der sammenlignes med.
hrv_people_info - person_id (primær-nøgle) - first_name - middle_names - last_name - telephone_number_1 (hjemme) - telephone_number_2 (mobil) - work_telephone (arbejde) - email_address - full_name - keystring (medarbejderens navn med store bogstaver)
Tabellen "ra_customers" indeholder kunde oplysninger. Når en kunde skal findes ved hjælp af den indtastede søgestreg, så er det attributten "attribute11", der sammenlignes med. Som før nævnt er denne tabel indgangen til kunden, og det er heri at kundens navn og status står. For at finde kundens ID til kontakt og aktivitets tabellerne, samt kundens addresse og telefonnummer, linkes attributten "oldoracleid" fra "cdmcomp" tabellen i "cdm" databasen med attributten "customer_number".
ra_customers - customer_id (primær-nøgle) - customer_name - attribute11 (kundens navn med store bogstaver) - status (kundens status, A=aktiv) - customer_number (link til cdm.cdmcomp.oldoracleid)
Tabellen "product_license" indeholder licens oplysninger. For at finde ud af hvilke produkter en kunde har licens til, linkes attributten "customer_id" fra "ra_customers" tabellen med attributten "customer_id".
product_license - customer_id (link til ra_customers.customer_id) - product_descr (hvilket produkt drejer det sig om) - version (hvilken version er det) - quantity (antallet af licenser til dette produkt) - licens_type (må ikke være null, hvis null så er licensen termineret) - platform (hvilket OS-platform det kører på)
I denne database står igen oplysninger om de enkelte kunder og hvilke kontakter der er hos hvilken kunde. Endvidere er der også oplysninger om alle aktiviteter (seminare/nyhedsbreve) Oracle har for tiden, og hvilke aktiviteter den enkelte kunde er tilmeldt og har været tilmeldt. De 4 relevante tabeller og de attributter MAOV-systemet bruger er beskrevet nedenfor.
Tabellen "cdmcomp" indeholder kunde oplysninger. Dette er den tabel, som tabellen "ra_customers" fra "prod" databasen linker med. Heri er kundens ID, der skal bruges til kontakt og aktivitets tabellerne, samt oplysninger om kundens addresse og telefonnummer. Dette er dog, som før nævnt, kun muligt at få fat på hvis attributten "oldoracleid" ikke er tom.
cdmcomp - id (primær-nøgle) - addr1 - phone - oldoracleid (link til prod.hrv_people_info.customer_number) - primarypostcode (link til cdmpcode.id)
Tabellen "cdmpcode" indeholder postnummer/by oplysninger. For at få en kundes bynavn, så linkes attributten "primarypostcode" fra "cdmcomp" tabellen med attributten "id".
cdmpcode - id (primær-nøgle) - town
Tabellen "cdmcont" indeholder kontakt oplysninger. Alle de kontakter der er hos en kunde findes ved at linke attributten "id" fra "cdmcomp" tabellen med attributten "primcomp".
cdmcont - id (primær-nøgle) - firstn - lastn - title - direct - mobile - email - delu (må ikke være null) - primcomp (link til cdmcomp.id)
Tabellen "cdmacti" indeholder aktivitets oplysninger. Aktiviteter som en kunde er tilmeldt og har været tilmeldt findes ved at linke attributten "id" fra "cdmcomp" tabellen med attributten "primcomp". Det skulle også være muligt at tilmelde kunder til fremtidige aktiviteter, men det var ikke muligt at finde en attribut, der indeholdt en fremtidig dato. Derfor vil denne funktion ikke blive mulig.
cdmacti - head (kort aktivitetsbeskrivelse, må ikke være null) - startdate (hvilke dato den enkelte aktivitet er oprettet) - primcomp (link til cdmcomp.id)
I denne database står oplysninger om de enkelte kunders sagsforløb (TAR's). De to relevante tabeller og de attributter MAOV-systemet bruger er beskrevet nedenfor.
Tabellen "tar_head" indeholder oplysninger om de enkelte TARs. En vigtig oplysning om en TAR er om det er kunden eller Oracle der forventes at gøre noget ved sagen. Den oplysning står i "tar_status"-attributten, som et nummer. Er nummeret under 18, er TAR'en stadig direkte aktiv. En sag kan dog vise sig at være en fejl i programmet som skal løses i USA. Hvis en sag venter på det, er "bug_status"-attributten mindre end 39, og TAR'en skal også vises.
tar_head - tar_no - contact_first_name - contact_name - contact_phone - change_date - severity - component - subject - tar_status (link til tar_status.status) - bug_status (link til tar_status.status) - org_id (link til prod.ra_customers.customer_id)
tar_status tabellen er til for at afkode de numre der står i "tar_status" og "bug_status" -attributterne i "tar_head"-tabellen. Man kan direkte linke tal-værdierne til denne tabel, og få en beskrivelse for det enkelte status-nummer, dog på engelsk.
tar_status
- status (link til tar_head.tar_status og tar_head.bug_status)
- status_type ('T' = tar eller 'B' = bug)
- description
Figuren herunder viser hvordan de forskellige tabeller linkes sammen.
Dette var en kort gennemgang af de forskellige Oracle databaser og tabeller, som MAOV-systemet anvender. De SELECT statements MAOV-systemet gør brug af kan ses i afsnit XXX "SQL - kommandoer" side XXX.
Det var ærgerligt at det viste sig, at det ikke er muligt at få oplysninger om aktiviteter og kontakter for kunder, som er oprettet efter at kundedata er flyttet fra de gamle tabeller til de nye. Men det er der ikke noget at gøre ved, for sådan har Oracle selv valgt at skrue tabellerne sammen.
Dette gør selvfølgelig at MAOV-systemet ikke er 100% brugbart i alle situationer, men dette er Oracle helt indforstået med, da de selv har skabt dette problem. De vil dog efterfølgende forsøge at få lavet en linktabel, således at det vil være muligt at se alle oplysninger for samtlige kunder.
Det var desvære heller ikke muligt at finde nogle aktiviteter der ligger ude i fremtiden i aktivitets-tabellen. Dette bevirker at tilmelding til aktiviteter ikke bliver muligt, men det har ikke den store betydning. Det vigtigste er at kunne se hvilke aktiviteter en kunde er tilmeldt og har været tilmeldt. Det ville selvfølgelig have været smart, men det er en af de her "nice to have" funktioner, der sagtens kan undværes, hvilket Oracle også selv mener.