Universitetet i Oslo Institutt for informatikk Systemutfikling Revisited Fikling for Examen Rolf Borgen Guescini, Heidi-Christin Bernhoff-Jacobsen Studentrapport 16. juni 2002
Innhold 1 INNLEDNING 4 1.1 Konvergens.............................. 4 1.2 Informasjonssystem......................... 4 1.3 Interesseområde........................... 4 1.4 Modell................................. 4 1.5 Interessegrupper........................... 4 1.6 Systemutviklingsmetoder..................... 5 2 SYSTEMUTVIKLINGSPROSESSEN 6 2.1 PRODUKTAKTIVITETER....................... 6 2.1.1 Realisering (løsning av problemet)............ 6 2.1.2 Analyse (HVA er problemet)................ 6 2.1.3 Utforming/design (HVORDAN løse oppgaven).... 6 2.2 STYRINGSAKTIVITETER (Styrer produksjon av et hensiktsmessig informasjonssystem)................... 6 2.2.1 Vurdering........................... 7 2.2.2 Planlegging.......................... 7 2.2.3 Regulering........................... 8 2.2.4 Hvor går systemutviklingsgrensen?........... 8 2.2.5 Systemutviklingsartefakter................ 9 2.2.6 Modeller............................ 9 2.2.7 Utvilingsmiljø........................ 9 2.3 SYSTEMUTVIKLINGSSTRATEGIER................. 9 2.3.1 Utviklingsstrategi...................... 10 2.3.2 Fra Kjernen ut / Skallet Inn................ 11 2.3.3 Gjenbruksstrategi...................... 12 2.4 SYSTEMUTVIKLINGSMETODER.................. 13 2.4.1 Hva inneholder en metode?................ 13 2.4.2 Fossefallsmetoden...................... 15 2.4.3 Fossefallsmetode med lakseeffekt............ 16 2.4.4 Inkrementelle metoder................... 16 2.4.5 Risikostyrte spiralmetoden................ 17 2.4.6 Smidige Metoder (Agile methods)............ 17 2.4.7 Metoder må tilpasses.................... 17 2.5 Rammer................................ 18 3 PLATTFORMER, UTVIKLINGSMILØER OG SYSTEMARKITEKTUR 20 3.1 Plattformen,informasjonssystemet og APIer.......... 20 3.2 Abstraksjoner............................. 20 3.3 Modularisering............................ 20 3.4 Lagdeling............................... 20 3.5 Trelagsarkitektur for et informasjonssystem......... 20 3
3.6 Visjon................................. 20 4 FRA KJERNEN UT 21 4.1 Relasjonsdatabaser......................... 22 4.2 ENTYDIGHETSSKRANKE OG PRIMÆRNØKKEL......... 23 4.3 REFERANSEINTEGRITET...................... 24 4.4 SQL................................... 25 4.5 VIRTUELLE TABELLER........................ 26 4.6 Ad-hoc spørring og oppdatering................. 26 4.7 Programmer med innebygde spørringer............ 26 4.8 Brukergrensesnitt.......................... 26 4.8.1 Synkronisering av brukergrensesnitt og database.. 27 4.9 Pubblisering-abonnement-mekanismen............. 27 4.9.1 Oppdatering i flerbrukermiljø.............. 27 5 Begreper / Rollemodeller 29 5.1 Elementære Utsagn......................... 29 5.2 Hvorfor elementære utsagn?................... 29 5.3 Oppsplitting / Normalisering................... 29 5.4 Funksjonelle Avhengigheter.................... 30 5.5 Normalisering og Oppsplitting.................. 30 5.5.1 Fritt Fram........................... 30 5.5.2 Hvor og Hva bestemmer Hvem.............. 30 5.5.3 Hva bestemmer Hvem (Partiell funksjonell avhengighet)............................... 30 5.5.4 Hvor bestemmer Hva, Hva bestemmer Hvem..... 31 5.5.5 Hvor bestemmer hva, hvor bestemmer hvem..... 31 5.5.6 Hvor og hva bestemmer hvem, hvem bestemmer hvor 31 5.6 Begrepsdannelse........................... 32 5.7 Generalisering............................ 32 5.8 Underbegreper............................ 32 5.8.1 Homogenitetsregelen.................... 32 5.9 Stabilitet / Migrasjon........................ 33 6 SKRANKER 34 6.1 Entydighetsskranken (Uniqueness Constraint......... 34 6.2 Påkrevd Rolle............................. 35 6.2.1 Genrelle multiplisitetsskranker.............. 35 6.3 Mengdeskranker........................... 36 6.3.1 Delmengdeskranken.................... 36 6.3.2 Mengdelikhet......................... 36 6.3.3 Mengdeulikhetsskranken................. 36 6.3.4 Begrepsskranker....................... 37 6.3.5 Underbegrepsskranke................... 37 4
6.3.6 Prosedyreorienterte skranker............... 37 6.4 Avledede Utsagn........................... 37 6.4.1 Transitivt avledede utsagn................. 37 6.4.2 Akkumulering........................ 37 6.5 Overgangsskranker......................... 38 7 Representasjoner 39 7.1 Broer.................................. 39 7.2 Informasjonsbærende representasjoner............ 39 7.3 Delvis Informasjonsbærende Representasjoner........ 39 7.4 Fullt Informasjonsbærende Representasjoner......... 39 7.5 Kontekstsensitive Representasjoner............... 40 7.6 Hvordan gjøre et begrep representerbart............ 40 8 GRUPPERING 41 8.1 Gruppering til relasjonsdatabase................. 41 8.2 Hovedprinsippet........................... 42 8.2.1 Velg Primærnøkkel..................... 42 8.2.2 Grupperingen......................... 42 8.2.3 Undertrykking av tabeller................. 43 8.3 NIL i basen............................... 43 8.4 Sterk gruppering........................... 43 8.5 Gruppering av Underbegreper................... 44 8.5.1 Separasjon.......................... 44 8.5.2 Absorpsjon.......................... 44 8.5.3 Partisjonering........................ 44 8.6 Navngivning av attributter..................... 45 8.7 Skranker i grupperte utsagn.................... 45 8.7.1 Påkrevde roller........................ 45 8.8 Denormalisering........................... 46 9 Skallet - inn 47 9.1 Kravspesifikasjon.......................... 47 9.2 Rammer................................ 48 9.3 Bruksmønstermodeller....................... 48 10 Brukergrensesnitt 49 10.1 Prototyping av brukergrensesnittet............... 51 11 Fra skallet og inn 52 11.1 Sekvensdiagramemr......................... 52 11.1.1 Hvordan velge objekter?.................. 53 11.2 Objekter i trelagsarkitekturen................... 54 11.3 Klassediagrammer.......................... 55 11.4 Dataorienterte klassediagram................... 55 5
11.4.1 Assosiasjoner......................... 55 11.4.2 Primær- og kandidatnøkler................ 55 11.4.3 Underklasser......................... 56 11.4.4 Undertrykning........................ 56 12 Juridiske og Etiske Problemstillinger 57 12.1 Personopplysningsloven...................... 57 12.2 Konsesjon............................... 57 12.3 Innsyn................................. 58 12.4 Varslingsplikt............................. 58 12.5 Nettnemda............................... 58 6
1 INNLEDNING 1.1 Konvergens Utvikling i retning av at telefon, fjernsyn og datamaskinbaserte anvendelser kommer til å smelte sammen i en fells teknologi, og at denne teknologien, kommer til å bli like utbredt som telfonen er idag. 1.2 Informasjonssystem En inretning som er i stand til å ta imot informasjon, lagre den, behandle/bearbeide den og gi informasjon tilbake, hente ut info kanskje på et annet sted. Det skal bidre til utveksling av informasjon mellom mennesker i en organisasjon, og mellom organisasjoner. Informasjonssystem: (Norsk datahåndbok:) Informasjonsbehandlingssystem som sørger for, og fordeler informasjon. Informasjon: Kunnskap om objekter, fex: fakta, begivenheter, ting, prosesser eller ideer, inklusive begreper som i en viss sammenheng har en spesiell mening. System: Samling av komponenter som hører sammen og virker sammen, slik at vi kan betrakte dette som en organisert helhet. 1.3 Interesseområde Det utsnitt av virkeligheten vi betrakter. Informasjonssystemet er en modell av virkeligheten. 1.4 Modell En modell er en representasjon av noe, der visse egenskaper som er viktige for det formål representasjonen skal brukes til er fremhevet, mens de øvrige egenskaper utelates. 1.5 Interessegrupper De ulike interessegruppene kan ha avvikende oppfatning om hva som egentlig er formålet, og hva som er viktig. Meningsforskjellene gjenspeiles i de metoder og tekonikker vi bruker i systemutviklingen. 7
1.6 Systemutviklingsmetoder En metode beskriver hvordan man bør gå fram, hvilke beskrivelsesteknikker som bør brukes, sjekkliste over ting man bør huske på osv. 8
2 SYSTEMUTVIKLINGSPROSESSEN Et datamaskinbasert informasjonssystem består av en datamaskin eller flere datamaskiner koblet sammen med et datanett Et eller flere datamaskinprogrammer Data som behandles av disse programmene 2.1 PRODUKTAKTIVITETER 2.1.1 Realisering (løsning av problemet) skaffe maskinvare lage eller kjøpe software data legges inn systemet testes for at det fungerer som det forventets brukere må læres opp 2.1.2 Analyse (HVA er problemet) hvilke behov skal systemet dekke? finnes det økonomiske, juridiske, praktiske begrensninger? 2.1.3 Utforming/design (HVORDAN løse oppgaven) et stort system må settes sammen av mindre deler for å bli håndterbart utnytte allerede eksisterende programvare skal internasjonale / nasjonale /europeiske standarder følges? skaffe grunnlag for alle beslutninger inngår i hovedaktiviteten vi kaller utforming / design 2.2 STYRINGSAKTIVITETER (Styrer produksjon av et hensiktsmessig informasjonssystem) Produktaktivitetetene må styres: Start / slutt, hvilken rekkefølge skal ting utføres i? 9
Hvordan skaffe de ressurser som trengs? Sørge for at jobben blir utført Disse oppgavene dekkes av følgende tre hovedaktiviteter: 2.2.1 Vurdering når skal systemet være ferdig? hvor mye skal det koste? hvem skal involveres hva skal gjenbrukes av eksisterende programvare? hva trengs av nytt utstyr? hvor lang tid vil vi bruke hvordan få tak i data hvem bestemmer / tar beslutninger 2.2.2 Planlegging Ta alle opplysningene og legge en plan for når noe skal gjøre og hvem som utfører dette etablere MILEPÆLER - en konstanterbar tilstand i systemutviklingsprosessen 10
til enhver milepæl knyttes en dato for når den etter planen skal nås disse ligger mellom start og realisering, når systemet er akseptert og betalt 2.2.3 Regulering sette planen ut i livet å påse at milepæler nås til planlagte tidspunkt med de planlagte ressurser regulerende tiltak hvis så ikke skjer eks: ekstra bemanning (sjelden heldig, de må settes inn i systemarbeidet) vurdere på nytt ved å forskyve milepæler, redusere oppgavens omfang De seks punktene produkt- og styringsaktivitetene kan settes i et diagram som nedenfor: 2.2.4 Hvor går systemutviklingsgrensen? Det er hensikstmessig å se på systemet som en helhet - og ikke i første omgang ta stilling til hva som skal utføres av menneske/maskin, fordi en primærbruker kan ikke forventes å foreslå løsninger som gjør en selv o0verflødig, ergo blir fokuset på systembyggingen muligens feil... 11
2.2.5 Systemutviklingsartefakter planer sjekklister kravsspesifikasjoner modeller programkode Alt utenom koden vil kunne gjøre nytte som beslutningsgrunnlag og dokumentasjon av systemet dokumentasjon av organisasjonen rundt systemet brukerdokumentasjon erfaringsgrunnlag for senere prosesser 2.2.6 Modeller I systemutvikling er artefaktene oftest grafiske modeller, som brukes til å beskrive: det påtenkte systemet fra ulike synsvinkler samspill mellom bruker,virksomhet, system 2.2.7 Utvilingsmiljø Kan sørge for at modellene på de høyere nivåene til enhver tid er i overenstemmelse med det kjørende systemet. 2.3 SYSTEMUTVIKLINGSSTRATEGIER Fokus på Informasjonssystemet,Organinsasjonen eller Individet En systemutviklingsprosess har mange interessenter, som f.eks brukere av systemet, de som skal betale regningen, virksomhetens kunder, systemutviklerne osv, de har ikke nødvendigvis felles mål. Man burde ikke la seg overkjøre, eller la hensyn til brukerens ønsker bli overkjørt av holdninger og verdigrunnlag som ligger implisitt i systemutviklingsmetodene. 12
2.3.1 Utviklingsstrategi her går det en skala mellom: Analytisk utvikling......eksperimentell Utvikling Analytisk Utvikling Tar utgangspunkt i klare mål finner ut hva slags informasjonssystemer vi trenger lager / kjøper dem - setter dem i drfit basert på forutsetningen om at systemutvikling kan gjøres helt rasjonelt helt klare mål god oversikt over forskjellige alternativer som oppfyller målene beste alternativ velges på et rent saklig grunnlag det er mulig å sette oppp fulstendige kravsspesifikasjoner for systemet det er greit å lage systemet på grunnlag av disse fungerer best med SMÅ systemer, eller for klart definerte omgivelser f.eks: innebygde systemer i telefoner, vaskemaskiner, biler o.l vanskelig å tilpasse for systemer som skal inn i en organisasjon hvor målene sjelden er helt klare, og som forandrer seg underveis Eksperimentell Utvikling prøve-og-feile-prinsippet behøver ingen klare mål eller forestillinger onm systemet man kjøper eller utvikler et system og prøver det i brukermiljøet observerer svakheter og mangler, prøver systemet en gang til, og fortsetter slik til det er tilfredsstillende for organisasjonen en fullstendig eksperimentell utvikling lar seg sjelden utføre i praksis 13
Leveransestrategi Delleveranser - inkrementell systemutvikling: PROS: CONS: det tar kortere tid før deler av systemet kan tas i bruk vi forsøker å lever det viktigste delsystemet først: det som gir mest for pengene erfaringer av bruk/utvikling av det første delsystemet, kan komme til nytte ved utvikling av de etterfølgende delsystemene når et delsystem er ferdig, betraktes det som en milepæl gir reultater raskt - motiverende for brukere og utviklere hvis kostnadene ved et delsystem er overkommelige, er det ingen katastrife hvis det må forkastes hvordan sikre seg at et tidligere delsystem passer sammen med et ennå ikke påtenkt delsystem uheldig om ting i senere systemer tvinger frem forandring i allerede leverte delsystemer Man burder prøve å minimere størrelsen på første delleveranse. 2.3.2 Fra Kjernen ut / Skallet Inn Systemet kan bygges på prinsippielt to måter: 1. Fra kjernen og ut - kjernen er ofte en database, med alle opplysninger vi kunne tenke oss å få bruk for - behøver ikke nødvendigvis å vite hvordan kantobjektet ser ut, hvordan alt skal brukes - så skrives programmet for interaksjon med kjernen - 2. Fra skallet og inn - beskriver først hvordan systemet skal se ut fra brukerens synsvinkel (brukergrensesnittet) - så lager vi programmet som realiserer denne oppførselen - dukker nye behov opp, spesifiseres nye brulkergrensesnitt og vi 14
skriver nye programmer - dersom systemet er fornuftig konstruert, kan utvidelese bygge på det som allerede eksisterer slik at arbeidsmengden blir overkommelig Valg av prinsipp kommer an på situasjonen! Hvis systemet er datatungt med enkle brukeroperasjoner, så velger man kjernen ut. Derimot hvis systemet er oppførselstungt, så vil det nok være hensiktsmessig å velge fra skallet og inn. 2.3.3 Gjenbruksstrategi gjør at utviklingen kan gå vesentlig fortere senker kostnader kan gi lavere feilmargin, da delene allerede er feilprøvd Problemer? gjør delen alt det jeg trenger? ble letingen bortkastet? man må tilpasse delen fordi den ikke passer helt Disse tingene kan ta mer tid enn å konstruere et nytt komponent. Planleggingsstrategi Forutbestemt Plan - gitt i mange klassiske systenutviklingsmetoder. Dynamisk Plan Hva er hensikstmessig å gjøre nå. Ut i fra svaret fastlegges de neste aktivitetene. Vi vurderer, planlegger og regulerer hele tiden, og produktaktivitetene og styringsaktivtetene påvirker hverandre gjensidig. Risikostyring - velge de mest hensiktsmessige aktivitetene ved å prioritere de som fjerner / reduserer risiko for å ikke møte tidsfrist/prisanslag - ved milepælene stopper vi opp og vurderer hva som må til videre for å møte tids- /priskrav. (2-3) /subsubsectionomfangsstyring eller tidsstyring og omfangsstyring Hvilken av de to kolonnenei milepælsplanen skal fylles ut først-beskrivelsen 15
eller tidsfristen? Omfangsstyring: - sette opp milepæler som angir et visst leveranseomfang, og deretter anslå tidspunkter for å nå disse - så estimere kostnader - dette er en tradisjonell form for avtale mellom selger og kjøper av et informasjonssystem. DEN KLASSISKE FORMEN FOR MILEPÆLSPLANLEGGING - fordele milepælene jevnt over tid, det er dårlig styring hvis førtse milepæl dukker opp først etter at halve tiden er gått, og mesteparten av ressursene er brukt. Et alternativ er det omvendte: Tidsstyring - først fastslå tidspunkter, og deretter anslå hva vi kan greie å levere på den oppsatte tiden - forpliktekese til å levere på deadlines - prinsippet er kjent under betegnelsen TIMEBOXING (ca 3 mnd / 3 uker for et lite sytsem) - en timebox er en avgrenset tidsperiode. Kommer utviklerne i tidsnød må de heller redusere omfanget av leveransen (og overholde tidsfristen) enn å overskride tidsfristen. Kostnadsstyring - vi setter av ressursene/pengene for et utviklingsformål, deretter forsæøker vi å få mest mulig system for pengene - denne styringen er implisitt i en bedrift hvor systemutvikleren går på fastlønn - kjøper må være aktiv for å få mest mulig for pengene 2.4 SYSTEMUTVIKLINGSMETODER - en detaljert oppskrift på hvordan man skal gå frem når man skal lage/endre et datamaskinbasert informasjonssystem. - bygger dels på teorier/ og systematisering av erfaringer - slike metoder er ofte bygd inn i utviklingsverktøy - et utall metoder; exsplisitt eller implisitt i disse, ligger en rekke valg mellom de ulike startegiene beskrevet i kapitelet om systemutviklingsstrategier 2.4.1 Hva inneholder en metode? Aktivitetsliste hva må gjøres 16
forutsetninger for gjennomføring hva trengs av ressurser hva skal aktiviteten resultere i Aktivitetsrekkefølge Spesifikasjon av leveranser artefakter som systemutviklingsprosessen skal levere til omverdenen programmoduler dokumentasjon utredninger Forslag til milepæler Anbefalte teknikker Det er hensiktsmessig å benytte et antall systemutviklingsteknikker Mænstre generelt anvendelige beskrivelser modeller programbiter som man erfaringsmessig har sett gå igjen. Sjekklister detaljoppgaver innen hver aktivitet Rutiner for kvalitetssikring rutiner som skal øke sannsynlighet for at milepæler nås innenfor rammene av tid / ressurs Verktøystøtte CASETOOLS (kan ha den ulempen at metoder blir for satt i faste rammer) oppmerksomhet bort fra aktiviteter uten verktøystøtte 17
2.4.2 Fossefallsmetoden Det er innlysende at de tre hoved aktivitetene må utføres i en viss rekkefølge: 1. Analyse (hva er problemet) 2. Utforming (hvordan løser vi problemet) 3. Realisering (løsningen av problemet) Resultatet av analysen fosser ned i og danner grunnlaget for utformingsaktiviteten, hvis resultat igjen fosser ned i og danner grunnlaget for realiseringsaktiviteten. Dette er de klassiske, tradisjonelle systemutviklingsmetodene. Fossefallsmetoden kommer av at man egentlig ikke skal kunne vende tilbake fra realisering til tidligere stadier, dette illustrerer velavgrensede faser i systemutviklingen. - ved de 3 milepælene, analysen ferdig, utforming ferdig, og realisering ferdig, gjennomføres styringsaktivitetene vurdering/planlegging/regulering. - en leder for prosjektet vil gjøre uformelle vurderinger underveis, for å kunne gripe inn i tide, hvis noe ikke går etter planen. Forprosjekt - før starten på hvert av de 3 produktaktivitetene utførerer vi de 2 reflekterende styringsaktivitetene vurdering og planlegging, dette er jo ikke mulig foran analysen, så der har man gjerne en aktivitet kalt forprosjekt.(foil: 2-4) vurderer om systemet er mulig å skaffe til veie gjør grove overslag over kostnader og gevinster vurderer om det er hensiktsmessig å utvikle systemet og setter rammer for utviklingen. Fossefallsmetoden - uhensiktsmessig? (enkel) sterkt rettet kun mot programvaren, ikke mot mennesker og organisatoriske spørsmål. hvor grundig må vi analysere for at hvert fall foregår som planlagt? forhåndsbestemt rekkefølge, struktur ligger fast etter at systemutvikling har startet 18
vurdering / planlegging går til å anslå hvor mye tid / penger som må til for realisering av de enkelte systemdelene illusjon om rasjonell systemutvikling mest egnet for små, innebygde systemer, eller systemer uten behov for milepæler 2.4.3 Fossefallsmetode med lakseeffekt når forutsetningene for analytiske strategier svikter, forsøker lakseeffekt å bøte på dette ved at man åpner for å gå tilbake til tidligere aktiviteter (foil: 2-5) problemet blir at nå må tilsynelatende ferdige aktiviteter gjøres om igjen, dette sprer seg kanskje bakover pga forandringer verdien av mileåæler blir derfor tvilsom endringsønsker blir et nødvendig onde - ny revidert plan - nye kostnadsanslag - nye milepæler 2.4.4 Inkrementelle metoder mer realistisk alternativ til fossefallsmetoden, tar hensyn til at analyse, utforming og realisering påvirker hverandre gjensidig systemutvikling inneldes med en analytisk fase der vi prøver å definere omfanget av totalsystemet for deretter å bryte det ned i delsystemer - hvert delsystem utvikles ved hjelp av en småskala fossefallsmetode det lages nye milepæler etter hver dellevering (foil: 2-6) er noen delsystemer avhengig andre? (se kapittel for Systemutviklingsstrategier.leveransestrategi.inkrementell systemutvikling ulempe: tidligere delleveranser begrenser valgmulighetene for de senere leveransene 19
2.4.5 Risikostyrte spiralmetoden fremdriften går som i en statidig større spiral gjennom de ulike aktivitetene basert på risikostyring - hvilke deler av systemet som betraktes - hvor mye vekt på hver aktivitet bestemmes ved hjelp av risikovurderinger planene oppdateres for hver runde i spiralen fossefallsmetodene og inkrementelle metoder kan betraktes som spesialtilfeller av den mer generelle spiralmetoden 2.4.6 Smidige Metoder (Agile methods) moderne metoder - konkretisert i metoder som the unified process og extreme programming legger vekten på å komme frem til kjørbare systemer så raskt som mulig, og utfører bare det høyst nødvendige av analyse og utføringsaktiviteter det er bortkastet arbeid å foreta en grundig undersøkelse av omgivelesenes ønsker for systemet, når disse har en tendens til å endre seg ganske så mye gjennom systemets levetid det er bedre å utforme systemer slik at de er lette å endre og tilpasse nye behov etterhvert som de dukker opp metodene bruker som oftest tidsstyring i forbindelese med milepælsplanleggingen 2.4.7 Metoder må tilpasses - til hvert enkelt oppdrag -hva gjør systemutviklingsprosessene så forskjellige at metodene må tilpasses? fleksible metoder åpner for planlegging underveis fleksible metoder gjør det igjen vanskeligere å planlegge tidsmessig / resursmessig, og å legge en fullstendig utviklingsplan - løsning: - detaljplanlegging på kort sikt - grovplanlegging på lang sikt 20
selve målene menneskene omfanget teknologien - hva er mulig å gjøre? - hvordan gjøres det best? - teknologiuavhengige metoder finnes ikke utviklingsoppgavenes innbyrdes påvirkning - neste utviklingsprosess vil starte med andre forutsetninger - de tidligere prosessene får en ekstra belastning ved å skape gjenbrukbare moduler som de senere prosessene kan høste gevinst av 2.5 Rammer - uansett metode så må systemer lages innenfor disse rammene: Juridiske Rammer følge internasjonale og nasjonale regler og lover i Norge Personopplysningsloven Arbeidsmiljøloven (om medvrkning) Avtaler mellom parter i arbeidslivet Etiske Rammer se vær varsom-plakaten, utviklet av USA s dataforening, Association of Computing Machinery Økonomiske Rammer budsjett i form av kroner eller timeverk Tidsmessige rammer deadline, eller når systemet skal tilpasses nye krav fra myndigheter som resulterer i absolutte tidskrifter ofte viktig med sikkerhetsnett i form av redusert, men likevel akseptabelt leveranseomfang Teknologiske Rammer maskinutstyr 21
plattform utviklingsmiljø samspill med andre systemer systemutviklers kompetanse kan kreve betydelige investeringer - metoder må brukes kritisk og med omtanke - avvik skal være bevisste og vel begrunnet for å senere finne ut hvilken metodevariant som førte til success eller fiasko 22
3 PLATTFORMER, UTVIKLINGSMILØER OG SYSTEMAR- KITEKTUR 3.1 Plattformen,informasjonssystemet og APIer se foil 3 el. kap 4 foil 34 3.2 Abstraksjoner se3 foil 26 3.3 Modularisering se foil 28 3.4 Lagdeling se foil 29 3.5 Trelagsarkitektur for et informasjonssystem se foil 30 3.6 Visjon se foil 31 23
4 FRA KJERNEN UT egner seg godt for delleveranser fordi vi stadig kan legge til nye applikasjonsprogrammer kjernen kan utvides etterhvert som nye applikasjonsprogrammer krever det bygge systemet rundt en kjerne(gjerne i form av en database) av viten om INTERESSEOMRÅDET lager en virkelighetsmodell ut fra antagelser om hvilke opplysninger om interesseområdet det er verdt å ta vare på legger deretter et APPLIKASJONSLAG og et BRUKERGRENSESNITT- LAG tilpasset ulike brukergrupper, rundt denne felles databasen realiseres ofte på en plattform som omfatter et databasehåndteringssystem (foil1) Databasesystemet har nyttige egenskaper som f.eks: Flerbrukermekanismer -tillater flere brukere samtidig Transaksjonshåndtering - oppdateringer -enkel måte å oppdatere databasen på Spørrespråk -gjør det muligå spørre el. oppdatere databasen uten å skrive ut et spesielt program for formålet Sikkerhetsmekanismer - sørger for tilgjengelighet av data Privacymekanismer - kan sperre tilgang til data for brukere som ikke skal ha adgang til dem De fleste databaser som finnes i verden i dag er bygd på RELASJONSDA- TABASETEKNOLOGI. En annen type er objektorienterte databaser. 24
4.1 Relasjonsdatabaser database: - en samling med data som er organisert for å tjene et bruksområde jmf ND Databasehåndteringssystem: brukes for å enkelt kunne bruke disse dataene - datamaskinsystem som definerer etablerer, håndterer, styrer, administrerer og bruker databasen jmf ND Et brukervennlig datamaskinbasert informasjonssystem vil inneholde mange programmoduler i tillegg til håndteringssystemet. Den sentrale ideen i relasjonsdatabaseteorien, er å strukturere dataene i tabeller, og å "regne" med disse tabellene på bestemte måter (foil 4-2) Man kan også sette sammen to tabeller og få en tredje Hver tabell har to deler: 1. tabellhode som inneholder overskrift for hver kolonne 2. en mengde linjer, som utgjør selve innholdet i tabellen Kolonnenavnene kalles attributter og er tilordnet et verdiområde(som er en mengde med verdier som det er lovlig å bruke i denne kolonnen Det kan være vilkårlig mange attributter med samme verdiområde i en tabell - vi kan derfor oppfatte attributtene som roller som deres tilhørende verdiområder spiller i tabellen 25
Når det gjelder tupler, så må de ha en verdi for hvert attributt (gjerne null), men ikke ingenting! En tabell må oppfylle visse krav: alle attributter må ha forskjellig navn alle tupler må ha like mange attributter alle verdier i et attributt må komme fra samme verdiområde verdiene er atomære (kan ikke plukkes fra hverandre) tuplenes rekkefølge er vilkårlig alle tuplene må være forskjellige fra hverandre Hvis alt dette er oppfylt, kan vi kalle tabellen en RELASJON Dersom vi fjerner alle tuplene i en tabell, sitter vi igjen med det vi kan kalle et RELASJONSSKJEMA el TABELLSKJEMA(fig: 4-2) - dette kalles også databasens INTENSJON, også kalt METADATA, mens tuplene er databsens EKSTENSJON (brukerdata) Verdiområde - en mengde verdier - verdier => datatyper - datatype er et definert sett med kantobjekter til en bestemt datastruktur og et sett med tillatte operasjoner jmf ND - kan også definere egne datatyper (fig: 4-3) NIL - en verdi som settes inn når vi ikke kjenner verdien - betyr: ingenting, og er ikke det samme som 0. (Det er forskjell på at en person har 0 barn, enn at man ikke vet hvor mange - NULL/ NOT NULL - å forby at et attributt kan være nil markeres med NOT NULL, og et eks. på det vi kaller INTEGRITETSREGEL 4.2 ENTYDIGHETSSKRANKE OG PRIMÆRNØKKEL Entydighetsskranken (streken over en kolonne) pålegger tabellen at alle verdier i den "beskrankede" kolonnen må være forskjellige fra hverand- 26
re Derav følger det at det til et gitt attributt som er gjenstand for entydighetsskranke, så vil det bare være en verdi for de andre attributtene i tabellen som tilhører denne tuppelen - dermed kan attributtet som har entydighetsskanken også være en PRIMÆR- NØKKEL(fig: 4-4 => til et gitt kommunenr kan det bare høre en eneste verdi av kommunenavn, avfallsmengde, innbyggertall, fylkenr og fylkenavn. Dermed kan kommunenr også fungere som primærnøkkel) En entydighetsskranke og dermed en primærnøkkel kan omfatte flere attributter, og vi får da en SAMMENSATT PRIMÆRNØKKEL En primærnøkkel er altså et attributt eller en kombinasjon attributter hvis verdier erforskjellige fra hverandre i alle tupler i en relasjon/tabell, ved å oppgi verdien på en primærnøkkel, velger vi samtidig ut en bestemt tuppel i tabellen. Relasjonsdatabaseteorien sier at verdier for attributter som inngår i en primærnøkkel ikke kan være null - regelen om ENTITETSINTEGRITET Noen ganger hender det at det i samme tabell er flere attributter (- kombinasjoner) som er gjenstand for entydighetsskranke og dermed kan brukes som primærnøkkel - det er disse som kalles kandidatnøkler - vi kan relativt fritt velge primærnøkkel ut fra disse (mer i kap 5) Alle tabeller må i følge relasjonsdatabaseteorien ha minst en entydighetsskranke og dermed en primærnøkkel - unngå dobbeltlagring, lag heller to tabeller (fig: 4-6) - metoden for å slå disse to sammen til en tabell igjen kalles en NATU- RAL JOIN 4.3 REFERANSEINTEGRITET For å forhindre at en feilaktig verdi legges inn, kan man legge inn en skranke som sier at alle verdier som f.eks legges inn i tabell 1 må finnes i tabell 2 Referanseintegritet kan brytes på to måter: 27
1. Enten ved å legge inn en verdi i tabell A som ikke berøres av skranken mellom A og B ex: kommune i fylke som ikke finnes 2. Eller ved å fjerne fylke fra fylketabellen som inneholder en eller flere kommuner SQL : ADD CONSTRAINT navn FOREIGN KEY (attributtnavn) REFERENCES tabellnavn; - dette kalles en FREMMEDNØKKEL 4.4 SQL Datadefinisjon - setter opp top tabellstruktur - endre struktur Datakontroll - regulere adgangstillatelser Datamanipulering - sette inn, endre, slette, spørre Med basen i bunnen kan vi bygge videre - for at system skal bli oversiktelig og vedlikeholdsvennlig, bør de enkelte programmene 1. ikke ha koplinger mellom seg (couplings), men bare mot databasen 2. kohesjon bør være slik ar porgrammene (moduler) ikke omfatter urelaterte oppgaver 3. Programmer bør ikke overlappe hverandre i funksjonalitet Ofte er applikasjonslaget tynt og mye vil blande seg inn i brukergrensesnittet, slik at man ofte i praksis får en to-lagsmodell isteden for den vanligst ønskede tre-lags-modellen 28
4.5 VIRTUELLE TABELLER Virtuelle Tabeller fimnnes tilsynelatende i databasen, og formes ved at man lager en temporær tabell ut fra en spørring - spørringen blir utført hver gang den virtuelle tabellen blir kalt på, og blir derfor dynamisk på bakgrunn av hvilke data som ligger i de originale tabellene i mange tilfeller kan brukergrensesnittet legges rett på de vituelle tabellene SQL: CREATE VIEW navn AS SELECT... - virtuelle tabeller kan også virke som en slags tilgangskontroll, ved å gi tilgang til kun disse - det er vanskelig å oppdatere basen gjennom den 4.6 Ad-hoc spørring og oppdatering - spørringer som brukeren utformer på sparket her og nå 4.7 Programmer med innebygde spørringer - alternativt til ad-hoc-spørringer er programmer som er skreddersyddtil en spesiell arbeidsform. Spørringene vil være innebygget i programmet(såkalte canned queries ) - et problem kjent som impedance mismatch består i at relasjonsdatabaseverden og SQL opererer med hele tabeller(relasjoner), mens de fleste programmeringsspråk med noe som tilsvarer en tabellinje/tuppel ad gangen. - program språket henter inn tuplene og lagrer de bak kulissene og bruker enten en peker eller løper gjennom en array for å hente de frem. - kan få problemer hvis datatyper i databasen ikke stemmer overens med datatypene i programspråket. 4.8 Brukergrensesnitt Med programmer som inneholder skjulte spørringer kan si lage grensesnittet som vi selv vil - det er en fordel at brukergrensenittet ligner på ting brukere har sett før 29
- hvis man lar strukturen gjenspeile basen, blir programmene lette å lage, og grensensittet kan lanskje genereres automatisk - brukeren må dog kanskje kjenne til databasestrukturen. - det bør danne et separat lag i systemarkitekturen. 4.8.1 Synkronisering av brukergrensesnitt og database er også en ting å tenke på; - hvordan skal oppdateringen skje? - øyeblikkelig? - dette er en stor utfordring, for ifølge lagdelingsprinsippet, skal ikke lagene vite noe om hverandre, derfor blir en automaitsk oppdatering vanskelig - hvordan skal en modul sende en melding om oppdatering til en annen modul som den ikke kjenner til? - det kan løses ved at brukergrensesnittet kaller på en modul i underliggende lag ved oppstart - denne modulen sier fra når det skjer noe interessant som gjør det verdt å oppdatere grensesnittet Det mest beskjedne ville være at oppdatering ikke foregår automatisk, her må bruker oppdatere dataene på nytt for å få med seg eventuelle oppdateringer 4.9 Pubblisering-abonnement-mekanismen Den generelle løsningen på dette med oppdatering er når brukergrensesnittet etableres sender det en abonnementsmelding til en publiseringsabonnements-modul i det underliggende laget. Hvis noe av interesse i brukergrensesnittet skjer i de underliggende lagene, så vil brukergrensesnittet få beskjed om dette. Hendelsen bir publisertt overfor brukergrensesnittet som jo har abonnert på denne publiseringen 4.9.1 Oppdatering i flerbrukermiljø Dette kan gjøres på to måter: 30
1. Velg => lås basen => les en gang til => hvis fremdeles ledig => endre - hvis belagt i mellomtiden => velg på nytt 2. lås basen en begrenset tid => velg => hvis valg innenfor denne tiden => oppdater => ellers begynn på nytt - hvis basen er stor vil dette alternativet gi lange svartider Oppdateringen gjennomføres helt ut eller ikke i det hele tatt 31
5 Begreper / Rollemodeller (foiler: 5,8,14,21,23,26 5.1 Elementære Utsagn Utsagn som ikke kan gjøres kortere uten at vi mister meningsinnholdet, kaller vi elementære En elementær utsagnstype skal ha minst en kandidatnøkkel (entydighetsskranke) som omfatter alle roller, eller alle untatt en, (hvis dette ikke er tilfelle, kan utsagnet splittes) I de aller fleste tilfeller, så vil et elementart utsagn /elementær utsagnstype ha to roller, et såkalt binært utsagn, men det kan ha bare en eller også tre eller flere roller I elementære utsagn med tre roller, må det finnes minst en entydighetsskranke som omfatter enten to eller alle tre roller - typisk er at denne skranken omfatter roller som spilles av begreper av typen hvem, hva, hvor ex: "Gjenvinningsselskap gjenvinner materiale i kommune" er et elementært utsagn med tre roller, og det er elementært så lenge det ikke finnes noen forretningsregler som legger begrensninger på hvor mange gjenvinnningsselskaper, materialer og kommuner som kan være involvert. 5.2 Hvorfor elementære utsagn? 1. Vi kan enkelt lage overganger til naturlig språk 2. Vi står fritt til å gruppere utsagnene sammen på en hensiktsmessig måte 3. Vi unngår å trekke forhastede konklusjoner om grupper, entydighetsskranker osv. 4. Vi kan enkelt sette på endel sentrale integritetsregler / skranker 5.3 Oppsplitting / Normalisering Binære tabeller kan ikke deles opp, og er derfor alltid elementære - valnligvis et stort flertall av alle utsagn i en modell være binære utsagn med entydighetsskranke over en av rollene Derimot finnes det utsagn med mer enn to roller, disse må sjekkes om er elementære eller ikke: 32
1. Et utsagn som har mer enn en rolle utenfor en av entydighetsskrankene, er ALDRI elementær! 2. Et utsagn med en eller ingen roller utenfor entydighetsskranken er trolig elementært - hvis det finnes Partielle Funksjonelle Avhengigheter, må utsagnet normaliseres 5.4 Funksjonelle Avhengigheter I et utsagn med korrekt plassert entydighetsskranke, går det alltid en funksjonell avhengighet fra de rollene som er gjenstand for entydighetsskranke til hver og en av de øvrige rollene - det kan imidlertid finnes flere flere funksjonelle avhengigheter en dissa p.g.a. eventuelle forretningsregler - i så fall, er utsagnet ikke elemetært, og kan deles opp eller normaliseres I et elementært utsagn, er alle determinanter gjenstand for entydighetsskranke, som ikke skal omfatte roller utenom determinanten. 5.5 Normalisering og Oppsplitting Her følges oppdelingen med HVEM,HVA,HVOR 5.5.1 Fritt Fram - regelverk hvor det ikke finnes noen restriksjoner på noen av rollene, dermed ingen funksjonelle avhengigheter, og utsagnet er elementært (fig: 5-8) 5.5.2 Hvor og Hva bestemmer Hvem (fig 5-9)Determinanten er her gjenstand for entydighetsskranke, og utsagnet er dermed normalisert og elementært. 5.5.3 Hva bestemmer Hvem (Partiell funksjonell avhengighet) (fig-5-10a) Denne forretningsregelen gir en funksjonell avhengighet fra "hva" til "hvem", "hva"-rollen er determinant, men ikke gjenstand for entydighetsskranke (skranken er for lang på figuren) 33
Vi har her en situasjon hvor en determinant omfatter bare noen av rollene som er gjenstand for entydighetsskranke - dette kalles en Partiell funksjonell avhengighet - et utsagn med en partiell funksjonell avhengighet sies å være på Første NormalForm - slike tabeller medfører dobbeltlagring av opplysninger, i det tilfellet at hvem har monopol på hva For å bli kvitt den partielle funksjonelle avhengigheten, må vi skille ut rollene som inngår i den partielle funksjonelle avhengigheten i et eget utsagn, samtidig som vi lar en kopi av determinanten bli stående i det opprinnelige utsagnet - eventuelle duplikater i den utskilte tabellen fjernes, og vi kan sette en entydighetsskranke over "hva"-attributtet i den utskilte tabellen(fig: 5-10b)(sjekk errata) - det opprinnelige utsagnet som ikke var elementært, er nå blitt normalisert til to elementære utsagn 5.5.4 Hvor bestemmer Hva, Hva bestemmer Hvem (fig: 5-11a) Tabellen har mer enn en rolle utenfor entydighetsskranken, og utsagnet er dermed ikke elementært Det er en transitiv funksjonell avhengighet fra Hvor til Hvem, gjennom Hva. En transitiv funksjonell avhengighet sises å være på andre normalform Også denne modellen vil medføre dobbeltlagring av hvem-rollen, som i følge figuren har monopol. - normaliseringen foregår akkurat som i foorgige exempel: fig 5-11b 5.5.5 Hvor bestemmer hva, hvor bestemmer hvem Hvor -rollen er determinant overfor både materiale og avfallsselskap, og samtidig gjenstand for entydighetsskranke fig : 5-12a - det finnes ikke andre funksjonelle avhengigheter, så tabellen er normaliser, men siden det er mer mer enn en rolle utenfor entydighetsskranken, er den ikke elementær, og tabellen kan splittes opp i de to tabellene i fig 5-12b 5.5.6 Hvor og hva bestemmer hvem, hvem bestemmer hvor I fig 5-13a kan vi ikke sette en entydighetsskranke på determinanten, fordi da kan hvem kun behandle ett eneste materiale 34
Hvis vi nå skiller ut utsagnet som har funksjonell avhengighet ovenfor hvor i en egen tabell, så kan vi sette entydighetsskranken over hvem - rollen, slik får vi også en tabell til med hvem og hva under en lang entydighetsskranke, men hvordan skal vi uttrykke den lange skranken som var over hva og hvor? - med en ekstern entydighetsskranke Dette er normalisering til Boyce - Codd Normalform 5.6 Begrepsdannelse Enhver kombinasjon av roller som er gjenstand for entydighetsskranke kan oppfattes som et nytt begrep. Entydighetsskarnaker over mer enn to roller åpner for ulike begrepsdannelser: - enten er begrep over alle rollene, eller såkalte nøstede begrepsdannelser ved å danne et begrep av noen av dem, for så å hekte på rollen(e) som ikke var under entydighetsskranken på det nye begrepet som kom ut av begrepsdannelsen Dersom vi har en begrepsdannelse som omfatter n roller, så vil vi få en ekstern entydighetsskranke som omfatter n roller dersom begrepsdannelsen 5.7 Generalisering Dersom ulike begreper har samme representasjon, er dette et sterkt signal om at begrepene bør slås sammen - de må også tilhøre samme begrepstype (vi kan ikke sammenligne epler og bananer). 5.8 Underbegreper 5.8.1 Homogenitetsregelen Alle tenkelige forekomster av et begrep skal kunne spille alle tilknyttede roller - dette er ikke noe absolutt krav til en datamodell, med den blir mer presis og utsagnskraftig hvs den gjør det. - hvis dette ikke kean opprettholdes, så vil underbegreper være løsningen Alle undermengdene vil være en delmengde av supermengden og arver derfor også alle rollene fra supermengden, bl.a. representasjonen, og vil derfor ikke ha en egen representasjon 35
Et par interessante spørsmål: 1. Er underbegrepene disjunkte? - eller kan samme forekomst være av flere underbegreper 2. Er underbegrepene tilsammen uttømmende med hensyn til superbegrepet - eller finnes det forekomster som ikke er av noen av underbegrepene I eksempelet i foil 5-20c, er de både disjunkte og uttømmende 5.9 Stabilitet / Migrasjon Homogenitetsregelen bærer i seg en problematisk avgrensning: - skal vi betrakte begrepenes evne til å spille roller slik som de er i øyeblikket, eller skal vi ta hensyn til at de kan forandre seg og bli istand til å spille andre roller enn de er i stand til å spille nå? ex: - person => mann/kvinne er ganske stabilt - person => student derimot, vil forandre seg. 36
6 SKRANKER En skranke er en betingelese som oppfylles av forekomstene i datamodellen, og skal gjenspeile reglene i virkeligheten En avledning er en regel som spesifiserer hvordan en opplysning kan avledes fra andre opplysninger - skrankene skal gjenspeile de regler som gjelder i interesseområdet vi modellerer - reglene kan være naturlover, juridiske regler og regler som gjelder virksomheten eller organinsasjonen - disse kalles ofte for forretningsregler Skrankene brukes til 2 ting: 1. som del av et regelverk som kan håndheves av databasehåndteringssystemet eller av informasjonssystemet, og spm dermer kan bidra til en høyere datakvalitet 2. som grunnlag for å komme fram til en hensiktsmessig gruppering av de elementære utsagnene Det er 2 hovedgrupper av skranker: 1. Tilstandsskranker - angir betingelser som enhver lovlig tilstand i datamodellen skal overholde - de viktigste tilstandsskrankene er: multiplitetsskranker - regler for hvor mange ganger en begrepsforekomst skal kunne forekomme i en utsagnstype mengdeskranker - regler for avhengigheter mellom begrepsforekomster begrepsskranker - regler for hvilke begrepsforekomster som overhodet kan forekomme 2. overgangsskranker - begrenser hva som er lovlige overganger fra en tilstand til en annen - f.eks fastskranker 6.1 Entydighetsskranken (Uniqueness Constraint Entydighetsskranken sikrer at alle forekomster i en rolle må være forskjellige fra hverandre 37
- entydighetsskranker skal omfatte så få roller som mulig - idet en entydighetsskranke utvides, tillates dobbeltlagring, og modellen blir slakkere I relasjonsdatabasetorien, kalles en hvilken som helst kombinasjon av roller som entydig identifiserer linjene i en relasjon fro en supernøkkel - fordi alle linjer skal være forskjellige fra hverandre i en relasjon/tabell, har enhver relasjon minst en supernøkkel - nemlig alle kolonnene i relasjonen - vi fjerner kolonner fra supernøkkelen helt til det er umulig å fjerne flere uten at de gjenværende kollonnene ikke er en supernøkkel(entydig identifiserende) - da har vi funnet en kandidatnøkkel - primærnøkkelen velges blandt kandidatnøklene Oppsummering et og samme utsagn kan ha en eller flere entydighetsskranker en entydighetsskranke over få roller er sterkere enn en over flere jo flere entydighetsskranker, jo sterkere er de sett under ett entydighetsskranker som går over flere roller kan delvis overlappe hverandre en lang entydighetsskranke som fullstendig overlapper en kortere er fullstendig overflødig entydighetsskranken omfatter sjelden roller som spilles av begreper som måles,veies eller telles 6.2 Påkrevd Rolle En påkrevd rolle er som regel også gjenstand for entydighetsskranke er et symbol i matematisk logikk som betyr for alle, og brukes som symbol for påkrevd rolle - kan også symboleres som en svart prikk inntil begrepet på forbindelseslinjen mellom begrepet og den påkrevde rollen man bruker ikke påkrevd rolle på begge sider av et utsagn, siden dette indikerer at begge verdiene må legges inn samtidig Kombinert rolle mellom to utsagn, indikerer at begrepet skal spille en av rollene eller begge 6.2.1 Genrelle multiplisitetsskranker Den påkrevde rollen påkrever minst en forekomst av et begrep - lite brukt i begreps-rollemodellering 38
6.3 Mengdeskranker 6.3.1 Delmengdeskranken Setter betingelsen for hvilke mengder av forkomster som skal være tillatt - delmengde tilsvarer referanseintegritet (foreign key) Gir som konsekvens at man ikke kan fjerne den siste forekomsten av et begrep i rollen R1 for samtlige forekomster i R2 er fjernet - påkrevd rolle impliserer delmengdeskranker mot den påkrevde rollen fra ikke - påkrevde roller som spilles av samme begrep - man kan istedenfor å normalisere til BOYCE - CODD NORMALFORM, sette opp den funksjonelle avhengigheten som i figur 6-11 Til foil 6-10: a) DU kan ikke selge et bjørneskinn før NOEN har skutt den BJØRNEN SKINNET SITTER PÅ b) DU kan ikke selge et bjørneskinn før DU SELV har skutt en eller annen bjørn c) DU kan ikke selge et bjørneskinn før DU SELV har skutt BJØRNEN SKINNET SITTER PÅ 6.3.2 Mengdelikhet For at en forekomst av et begrep skal kunne spille rollen R1, må den samtidig spille rollen R2 og omvendt - den er lite brukt, da den ofte erstattes av et antall påkrevde roller på de samme rollene - det er forskjell på alle må og du må både a og b eller du kan la være 6.3.3 Mengdeulikhetsskranken Når en forekomst av et begrep spiller rollen R1, kan den ikke samtidig spille R2 - mengdeulikheten forekommer ofte i kombinasjon med en kombinert påkrevd rolle for å uttrykke eksklusiv eller Til foil 6-13: a) sag ikke i en gren når DU sitter på EN GREN b) sag ikke i en gren som NOEN ANDRE sitter på c) sag ikke i grenen DU SITTER PÅ 39
6.3.4 Begrepsskranker Angir hvilke verdier som er lovlige representasjoner av et begrep ex: {M,F} Et alternativ til en begrepsskranke er å opprette et unært utsagn med en påkrevd rolle som har de lovlige verdiene som forekomster 6.3.5 Underbegrepsskranke I modeller med underbegreper hekter vi ofte på et såkalt diskriminerende utsagn på superbegrepet - ved å se på forekomstene av dette utsagnet kan vi avgjøre i hvilket av underbegrepene forekomsten tilhører (foil 6-17 - ss 32/33) 6.3.6 Prosedyreorienterte skranker Uttrykkes i et eller annet programmeringsspråk, f.eks. at alle lønningene til de ansatte i en avdeling ikke skal overskride avdelingens budsjett 6.4 Avledede Utsagn Et avledet utsagn kan avledes fra andre utsagn som allerede finnes i modellen I begreps/rollemodeller, er det vanlig å merke den med en asterisk (*) i grafen i umidelvar nærhet av det avledede utsagnet De kan være med på å gjøre systemet uoversiktelig hvis det blir mage av dem - mens vanlige skranker kan føre til en avvisning av oppdateringer, fører denne til avledede oppdateringer, denne opppdateringen gir systemet en ekstra utfordring å takle 6.4.1 Transitivt avledede utsagn Hvis det er slik at A så B og B så C, da er det også slik at hvis A så C 6.4.2 Akkumulering Avledede verdier kan bergnes ut fra verdier i en gruppe forekomster av et annet utsagn, og siden flere verdier slås sammen, så kalles dette akkumulering 40
- vanlige akkumulerte funskjoner er sum(),avg(),count(),min(),max() - fig 6-22 6.5 Overgangsskranker Beskriver lovlige /ulovlige tilstander i datatabellen - den enkleste overgangsskranken er kal fastskranken, den utrykker at en forekomst av et elementært utsagn overhodet ikke kan endres - den er en vikti forutsetning for informasjonsbærende representasjoner - ukjent i relasjonssdatabasesammenheng 41
7 Representasjoner - siden f.eks. et menneske ikke kan skrives på papir, så er det hendig med representasjoner, og det er et sterkt ønske om stabile representasjoner 7.1 Broer Hvis informasjonssystemer skal kunne gi oss et utvetydig bilde av virkeligheten, så må det alltid være en entydig asossiasjon mellom en forekomst og det tilsvarende begrepet Det som trengs er altså en en-til-en-bro mellom begrep og referanse (fig: 7-1) Begrepet har en påkrevd rolle som sier at begrepet alltid må ha en representasjon, vi vil også helst ha en fastskranke for representasjonen skal være stabil 7.2 Informasjonsbærende representasjoner en ikke-representasjonsbærende representasjon representerer bare en forkomst av et begrep - den forteller oss ikke mer.. Ex: - verdens hovedsteder - internasjonalt aksepterte koder for land 7.3 Delvis Informasjonsbærende Representasjoner - kommunenumre er delvis informasjonsbærende representasjoner - ved å se på de to første sifrene vet vi fylkesnummeret, men hvis vi ser på de to siste sifrene, så skjuler de ingen informasjon alene (fig 7-2) - derfor kan vi heller bruke et tosifret kommunenummer som er entydig innefor et fylke (fig 7-3), skrankene forhindrer at man kan bruke det samme kommunenummeret innenfor et fylke 7.4 Fullt Informasjonsbærende Representasjoner ad fig. 7-4: - kombinasjonen av ansattnummeret og prosjektnummeret her er en fullt informasjonsbærende representasjon - den ene delen forteller oss hvem deltager er, mens den andre delen 42
forteller oss hvilket prosjekt det er snakk om - det finnes ingen del som ikke gir oss informasjon Informasjonsbærende representasjoner er mye brukt i praksis fordi det er en grei måte å få til entydighet på - men en representasjon kan være informasjonsbærende for noen, men ikke for andre, derfor bør vi i modellen vise informasjonsbæreingen, derosm det er den aller minste mulighet for at en eller annen bruker av systemet kan komme til å spørre etter denne informasjonen 7.5 Kontekstsensitive Representasjoner - bør unngås da de kan gjøre spørringene unødvendig kompliserte - de bør i tilfelle være godt skjult for brukeren 7.6 Hvordan gjøre et begrep representerbart Bortsett fra bruk av informasjonsbærende representasjoner, kan et begrep arve representasjon fra et superbegrep, eller få det via indirekte representasjon fra et annet begrep - underbegreper arver alle utsagn tilknyttet superbegrepet, inklusive broer - det betyr altså at underbegrep får samme representasjon som superbegrepet (fig: 7-9) Hvis et begrep spiller påkrevd rolle i et en-til-en utsagn, kan begrepet representeres indirekte gjennom det andre begrepets representasjon (fig 7-10) - + se fig. 7-11 - en annen måte er å bruke standardiserte representasjoner, slik slipper man i allefall å finne opp kruttet på nytt for disse begrepene 43