Tidigare Tenta Frågor Flashcards
Eriksson och Ågerfalk (2010) pekar på 3 ofta förekommande problem med identifierare.
Förklara (1) The Descriptive Identifier Problem
Beskrivning: Detta problem uppstår när identifierare inte är tillräckligt beskrivande för att klart och entydigt skilja mellan olika objekt eller entiteter.
Exempel: Om ett bibliotek använder sig av en enkel siffersekvens som identifierare för böcker, kan flera böcker av olika författare ha samma identifierare (t.ex. “1234”). Detta gör det svårt att exakt skilja mellan böckerna.
Konsekvens: Detta kan leda till förväxlingar och fel i hanteringen av objekt. Användare och system kan få svårt att korrekt lokalisera och hantera specifika entiteter, vilket kan resultera i förvirring och ineffektivitet.
Eriksson och Ågerfalk (2010) pekar på 3 ofta förekommande problem med identifierare.
Förklara (2) The Identifier Selection Problem
Beskrivning: Problemet uppstår när det är svårt att välja lämpliga identifierare för olika typer av objekt eller entiteter.
Exempel: En organisation måste välja hur man ska identifiera sina anställda i ett system. Om de väljer att använda anställdas initialer och födelsedatum som identifierare, kan detta vara svårt att hantera om två anställda har samma initialer och födelsedatum.
Konsekvens: Valet av felaktiga identifierare kan leda till kollisioner eller dubbla identifierare för samma objekt, vilket skapar förvirring och problem i systemet. Det kan också försvåra sökningar och hänvisningar till specifika objekt.
Eriksson och Ågerfalk (2010) pekar på 3 ofta förekommande problem med identifierare.
Förklara (3) The Identifier Control Problem.
Beskrivning: Problemet uppstår när det saknas standardiserade kontrollmekanismer för skapande, underhåll och verifiering av identifierare.
Exempel: Om olika avdelningar i en organisation skapar sina egna identifierare utan central kontroll, kan det leda till att två avdelningar skapar samma identifierare för olika objekt.
Konsekvens: Utan en enhetlig kontrollmekanism kan det vara svårt att säkerställa att identifierare är unika och korrekta över tid och över olika system. Det kan leda till datainkonsekvenser, felaktig referens till objekt och svårigheter att spåra och hantera information effektivt.
Förklara vad avses med ett institutionellt objekt?
Ett institutionellt objekt är en abstrakt representation av en entitet, process eller koncept inom en organisation eller samhälle. Det är skapat och definierat av institutionella regler, normer eller konventioner. Till exempel kan ett studentkonto i en universitetsdatabas vara ett institutionellt objekt. Det representerar inte bara studentens personliga data utan även de regler och normer som styr hur studentinformation hanteras och lagras.
Förklara vad som avses med ett fysiskt ting?
tt fysiskt ting är en konkret, materiell entitet som existerar i den fysiska världen. Det kan vara något som kan ses, röras eller uppfattas med våra sinnen. Till exempel är en bok, en dator eller en människa exempel på fysiska ting. Dessa objekt har en direkt existens och är inte beroende av några institutionella regler för sin natur.
Vilka problem kan det leda till om man inte ser skillnaden mellan fysiska ting och institutionella objekt i samband med konceptuell modellering?
När det inte finns någon tydlig åtskillnad mellan fysiska ting och institutionella objekt i konceptuell modellering kan det leda till flera problem:
Datainkonsekvenser: Om modellen inte tydligt skiljer mellan faktiska objekt och deras institutionella representationer, kan det leda till felaktiga tolkningar och inkonsekvenser i datahantering.
Felaktiga Beslut: Bristen på klargörande mellan de två typerna av objekt kan resultera i felaktiga beslut baserade på modellens antaganden.
Svårigheter att Implementera: Utan en tydlig distinktion kan det vara svårt att implementera system och processer korrekt, vilket kan leda till ineffektivitet och fel.
Att förstå och tydligt definiera skillnaden mellan institutionella objekt och fysiska ting är avgörande för att skapa en korrekt och effektiv konceptuell modell för informationshantering och systemdesign.
I artikeln “Design Theory for Dynamic Complexity in Information Infrastructures:
The Case of Building Internet” gör Hanseth och Lyytinen en viktig skillnad mellan applikationer (organisatoriska informationssystem) och informationsinfrastrukturer
Förklara vad som är skillnaden mellan dessa två typer av informationssystem?
Applikationer, eller organisatoriska informationssystem: är i grunden programvara eller verktyg som är utformade för att lösa specifika uppgifter eller problem inom en organisation. Dessa system är ofta skräddarsydda för att passa organisationens behov och fungerar som verktyg för att automatisera processer, hantera data och underlätta arbetsflöden. Applikationer fokuserar på att tillhandahålla specifika funktioner eller tjänster, såsom bokföring, lagerhantering, kundhantering eller produktionsplanering. De är vanligtvis avgränsade och isolerade från varandra, och deras huvudsyfte är att stödja och förbättra specifika affärsprocesser inom organisationen.
Informationsinfrastrukturer (IIs): representerar istället en övergripande ram eller struktur som möjliggör kommunikation, datautbyte och samarbete över en organisation eller till och med över flera organisationer. Dessa infrastrukturer består av ett nätverk av sammanlänkade komponenter, protokoll och resurser som möjliggör en effektiv och samordnad informationsflöde. IIs är mer omfattande och övergripande jämfört med applikationer; de stöder inte bara enskilda uppgifter eller processer utan möjliggör även integration och samverkan mellan olika delar av organisationen eller till och med mellan olika organisationer. Exempel på IIs inkluderar nätverk, operativsystem, databaser, kommunikationsprotokoll och andra infrastrukturella element som krävs för att möjliggöra användningen och funktionaliteten hos applikationer.
Artikeln “The Case of ePrescribing in Sweden”
Förklara vad som menas med begreppet institutionellt system som både består av en makronivå och en mikronivå. Exemplifiera detta med e-recept?
Inom institutionell teori avser ett institutionellt system ett system som befinner sig i och påverkas av den institutionella kontext i vilken systemet existerar. Denna kontext består av två huvudsakliga nivåer: en makronivå och en mikronivå.
Makronivå:
På makronivån finner vi den övergripande institutionella designen av informationsinfrastrukturen. Här ingår de regler, normer och kulturella förväntningar som styr hur systemet ska fungera. Det handlar om de institutionella pelare som utgör grundvalen för systemets struktur och beteende. I fallet med e-recept skulle detta kunna inkludera lagar och regler som styr receptförskrivning, de normer som förskrivare och apotekspersonal förväntas följa, samt de kulturella förväntningar som formar hur systemet används och tolkas.
Mikronivå:
På mikronivån implementeras och förändras den institutionella designen. Det är här systemet används i praktiken inom den digitala infrastrukturen. Det handlar om hur systemet används i verkligheten och hur aktörerna interagerar med det. I fallet med e-recept kan detta innebära hur förskrivare skapar recept, hur apotekspersonal hanterar och tolkar dem, samt hur patienter interagerar med systemet för att hämta ut sina mediciner.
E-recept är ett utmärkt exempel på ett institutionellt system som består av både en makro- och mikronivå. På makronivån har vi den övergripande institutionella designen av e-receptsystemet. Det inkluderar lagar och regler som styr elektronisk receptförskrivning, normer för hur recept ska utformas och hanteras digitalt, samt kulturella förväntningar kring användningen av dessa system.
På mikronivån ser vi sedan hur dessa institutionella regler och normer implementeras och förändras i praktiken. Exempelvis, när e-receptsystemet först infördes, stötte man på kvalitetsproblem med konvertering av olika receptformat. Genom att ta bort en gateway som tidigare dolde fel i konverteringen och istället införa automatiserad validering av e-recepten från början, förändrades praktiken på mikronivån. Förskrivare tvingades lära sig att skapa korrekta e-recept från början, vilket visar hur förändringar på makronivån direkt påverkar användningen och praktiken på mikronivån.
På så vis är e-receptsystemet ett tydligt exempel på ett institutionellt system som består av både en makronivå (institutionell design och regler) och en mikronivå (praktisk användning och implementation). Dessa två nivåer är intimt sammanlänkade och påverkar varandra i en feedbackcykel av förändring och anpassning för att uppnå ett effektivt och korrekt användande av systemet.
Artikeln “The Case of ePrescribing in Sweden”
Vad är ett API?
Ett Application Programming Interface (API) är ett set av definierade metoder och regler som tillåter olika programvarukomponenter att kommunicera och interagera med varandra. Det fungerar som en mellanhand som tillåter olika applikationer att begära och dela data eller funktionalitet med varandra på ett standardiserat sätt. Genom att använda ett API kan utvecklare skapa applikationer som utnyttjar funktioner från andra program eller tjänster utan att behöva förstå detaljerna i hur de är implementerade.
Artikeln “The Case of ePrescribing in Sweden”
Vad är ett DPI?
Ett Digital Practice Interface (DPI) är ett begrepp som är specifikt för hälso- och sjukvårdssystem. Det är ett gränssnitt som tillåter olika aktörer inom vården, såsom läkare, apotek och patienter, att interagera med och dela information relaterad till recept och medicinering digitalt. DPI möjliggör elektronisk förskrivning och hantering av recept, vilket effektiviserar och förbättrar processerna inom vården.
Artikeln “The Case of ePrescribing in Sweden”
Hur relaterar API och DPI till varandra?
API och DPI är nära relaterade eftersom DPI i grund och botten är en implementation av ett API inom hälso- och sjukvårdskontexten. DPI fungerar som det gränssnitt som tillåter olika aktörer inom vården att kommunicera med systemet för elektronisk förskrivning. Genom att använda DPI:s API kan olika program och system inom vården ansluta till och utbyta information med det elektroniska förskrivningssystemet.
Artikeln ”Pre-conditions for public sector e-infrastructure dev”
Eriksson och Goldkuhl menar att “Le1. Regulations with clear specifications for electronic exchange may enable the evolution of e-infrastructure. “ Förklara vad menas med detta och exemplifiera detta med utgångspunkt från ekonomiskt bistånd
När Eriksson och Goldkuhl talar om “Regulations with clear specifications for electronic exchange” syftar de på tydligt definierade regler och specifikationer för hur elektronisk utbyte ska ske. Detta innebär att det finns klara riktlinjer och standarder som styr hur information ska utbytas elektroniskt mellan olika aktörer inom ekonomiskt bistånd.
Ett exempel på detta inom ekonomiskt bistånd kan vara att det finns väldefinierade regler för hur ansökningsprocessen ska genomföras elektroniskt. Det kan inkludera specifika format för ansökningsdokument, krav på vilken information som måste inkluderas, och hur den ska skickas och tas emot. Om reglerna är tydliga och enhetliga underlättar det för myndigheter, individer och organisationer att förstå och följa processen för att söka och bevilja ekonomiskt bistånd. Detta kan leda till en smidigare och effektivare elektronisk utbytesprocess.
Eriksson och Goldkuhl menar att ”Lo1. Regulations with unclear or contrarious specifications for electronic exchange may inhibit the evolution of e-infrastructure.” Förklara vad menas med detta och exemplifiera detta med utgångspunkt från ekonomiskt bistånd
Å andra sidan, när Eriksson och Goldkuhl talar om “Regulations with unclear or contrarious specifications for electronic exchange” syftar de på otydliga eller motstridiga regler och specifikationer för elektroniskt utbyte. Detta innebär att det kan finnas förvirring eller osäkerhet kring hur elektronisk information ska utbytas inom ekonomiskt bistånd.
Exempelvis, om det finns olika tolkningar av reglerna kring elektronisk ansökan om ekonomiskt bistånd kan det skapa förvirring bland myndigheter och individer. Om det inte är tydligt vilka dokument som behövs, vilket format som krävs, eller hur informationen ska skickas och tas emot, kan det leda till felaktiga ansökningar, förseningar i processen och ineffektivitet. I det här fallet kan det också finnas problem om olika myndigheter eller organisationer har olika tolkningar eller krav på elektroniskt utbyte. Om reglerna är motstridiga kan det försvåra samarbetet och utbytet av information mellan olika aktörer inom ekonomiskt bistånd.
Sammanfattningsvis, tydliga och enhetliga regler och specifikationer för elektroniskt utbyte kan underlätta och främja utvecklingen av e-infrastruktur för ekonomiskt bistånd, medan otydliga eller motstridiga regler kan hämma och försvåra denna utveckling. Det är därför viktigt att ha klara riktlinjer och standarder för att skapa en effektiv och smidig elektronisk utbytesprocess inom ekonomiskt bistånd.
Eriksson och Goldkuhl menar att ”Lo1. Regulations with unclear or contrarious specifications for electronic exchange may inhibit the evolution of e-infrastructure.” Förklara vad menas med detta och exemplifiera detta med utgångspunkt från ekonomiskt bistånd.
Å andra sidan, när Eriksson och Goldkuhl talar om “Regulations with unclear or contrarious specifications for electronic exchange” syftar de på otydliga eller motstridiga regler och specifikationer för elektroniskt utbyte. Detta innebär att det kan finnas förvirring eller osäkerhet kring hur elektronisk information ska utbytas inom ekonomiskt bistånd.
Exempelvis, om det finns olika tolkningar av reglerna kring elektronisk ansökan om ekonomiskt bistånd kan det skapa förvirring bland myndigheter och individer. Om det inte är tydligt vilka dokument som behövs, vilket format som krävs, eller hur informationen ska skickas och tas emot, kan det leda till felaktiga ansökningar, förseningar i processen och ineffektivitet. I det här fallet kan det också finnas problem om olika myndigheter eller organisationer har olika tolkningar eller krav på elektroniskt utbyte. Om reglerna är motstridiga kan det försvåra samarbetet och utbytet av information mellan olika aktörer inom ekonomiskt bistånd.
Sammanfattningsvis, tydliga och enhetliga regler och specifikationer för elektroniskt utbyte kan underlätta och främja utvecklingen av e-infrastruktur för ekonomiskt bistånd, medan otydliga eller motstridiga regler kan hämma och försvåra denna utveckling. Det är därför viktigt att ha klara riktlinjer och standarder för att skapa en effektiv och smidig elektronisk utbytesprocess inom ekonomiskt bistånd.
XML för Premier League.
Utgå från denna XML-fil (finns nedan) i uppgiften.
Denna XML avser en fotbollsliga, i detta fall ”Premier League”, samt information om ett urval av ligans matcher och relevanta uppgifter om ligans lag, spelare, och domare.
Fråga a) Din uppgift är att med utgångspunkt från XML-filen skapa en konceptuell modell. Då modellering m.h.a. ritverktyget i Inspera är svårt att använda så ska du nyttja en alternativ syntax. Genom att följa denna alternativa syntax så kan modellen representeras med hjälp av tabeller:
Tabellnamn
==========
ID {PK}
Attribut
ID {FK}
I tabellerna du skapar är det viktigt att du markerar primärnycklar (primärnyckeln kan vara sammansatt om det är en korstabell), främmande nycklar, och samtliga attribut. Observera att det kan saknas lämpliga primärnycklar eller främmande nycklar i XML-filen, vilket innebär att du behöver skapa samt lägga till dessa på egen hand, i samband med att du modellerar tabellerna.
Du ska också beskriva relationerna (associationerna) och kardinaliteterna mellan tabellerna med hjälp av text. T.ex. om det finns en relation mellan anställd och avdelning kan den beskrivas på följande sätt.
En anställd finns på en avdelning och endast en avdelning (1..1).
En avdelning har minst en anställd men kan ha flera anställda (1..*).
Man måste alltså beskriva kardinaliteten från båda hållen i relationen.
<Fotbollsligor>
<Fotbollsliga>
<ligaid>1</ligaid>
<liganamn>Premier League</liganamn>
<land>England</land>
<Domare>
<domarid>101</domarid>
<namn>John Doe</namn>
<ålder>45</ålder>
</Domare>
<Domare>
<domarid>102</domarid>
<namn>Jane Smith</namn>
<ålder>38</ålder>
</Domare>
<Match>
<match_id>201</match_id>
<resultat>3-1</resultat>
<datum>2023-05-15</datum>
<SpelandeLag>
<match_id>201</match_id>
<lag_id>1</lag_id>
<status>Vinnare</status>
</SpelandeLag>
<SpelandeLag>
<match_id>201</match_id>
<lag_id>2</lag_id>
<status>Förlorare</status>
</SpelandeLag>
</Match>
<Match>
<match_id>202</match_id>
<resultat>2-2</resultat>
<datum>2023-06-01</datum>
<SpelandeLag>
<match_id>202</match_id>
<lag_id>2</lag_id>
<status>Oavgjort</status>
</SpelandeLag>
<SpelandeLag>
<match_id>202</match_id>
<lag_id>3</lag_id>
<status>Oavgjort</status>
</SpelandeLag>
</Match>
<!-- Andra matcher och data här -->
<Lag>
<lag_id>1</lag_id>
<lag_namn>Liverpool FC</lag_namn>
<arenanamn>Anfield</arenanamn>
<Spelare>
<spelarid>301</spelarid>
<namn>Mohamed Salah</namn>
<ålder>29</ålder>
<Mål>
<målid>401</målid>
<match_id>201</match_id>
<minut>15</minut>
</Mål>
<!-- Andra mål och data här -->
</Spelare>
<!-- Andra spelare och data här -->
</Lag>
<Lag>
<lag_id>2</lag_id>
<lag_namn>Manchester United</lag_namn>
<arenanamn>Old Trafford</arenanamn>
<Spelare>
<spelarid>302</spelarid>
<namn>Bruno Fernandes</namn>
<ålder>27</ålder>
<!-- Andra spelare och data här -->
</Spelare>
<!-- Andra spelare och data här -->
</Lag>
<!-- Andra lag och data här -->
</Fotbollsliga>
<!-- Andra ligor och data här -->
</Fotbollsligor>Tabeller och Relationer:
- Fotbollsliga
ligaid (Primärnyckel)
liganamn
land - Domare
domarid (Primärnyckel)
ligaid (Främmande nyckel)
namn
ålder - Match
match_id (Primärnyckel)
ligaid (Främmande nyckel)
resultat
datum - SpelandeLag
match_id (Primärnyckel)
lag_id (Primärnyckel)
status - Lag
lag_id (Primärnyckel)
lag_namn
arenanamn - Spelare
spelarid (Primärnyckel)
lag_id (Främmande nyckel)
namn
ålder - Mål
målid (Primärnyckel)
spelarid (Främmande nyckel)
match_id (Främmande nyckel)
minut
Relationer och Kardinaliteter:
- Fotbollsliga och Domare:
En fotbollsliga har en eller flera domare (1..*).
En domare dömer i en och endast en fotbollsliga (1..1). - Domare, Match och MatchDomare (korstabell):
En match kan ha en till flera domare (1…).
En domare kan döma noll eller flera matcher (0…).
Varje instans av MatchDomare (varje rad i databasen) hör till en och endast en match (1…1) och till en och endast en domare (1..1). - Match, Lag och SpelandeLag (korstabell):
Varje match har två och endast två spelande lag (2..2).
Varje lag kan spela en eller flera matcher (1..*).
Varje instans av SpelandeLag (varje rad) tillhör en och endast en match (1..1) och en och endast ett lag (1..1). - Lag och Spelare:
Varje lag innehåller noll till flera spelare (0..*).
Varje spelare tillhör ett och endast ett lag (1..1). - Spelare och Mål:
Varje spelare kan göra noll eller flera mål (0..*).
Varje mål görs av en och endast en spelare (1..1). - Match och Mål:
Varje match kan ha noll eller flera mål (0..*).
Varje mål tillhör en och endast en match (1..1). - Lag och Fotbollsliga:
Varje fotbollsliga har (minst) två eller flera lag som deltar (2..).
Varje lag kan delta i 0 eller flera fotbollsligor (0..). - Match och Fotbollsliga:
Varje match tillhör en och endast en fotbollsliga (1..1).
Varje fotbollsliga har en eller flera matcher (1..*) - måste finnas minst en match.
