Tentamen och lösningsförslag,

Institutionen för Data- och Systemvetenskap SU/KTH Maria Bergholtz och Paul Johannesson Tentamen och lösningsförslag, 0226 2I-033 IT i rganisationer och Databasteknik Tentamen är öppen i så motto att föreläsningar, litteratur, egna anteckningar, lösningsförslag till seminarier, etc., är tillåtna. Det är inte tillåtet att dela material med varandra. Datorer, programmerbara räknare, mobiler etc. är inte tillåtna. Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars rättas inte tentamen Tentan innehåller sex uppgifter som kan ge maximalt 50 poäng För att erhålla betyget tre räcker 35 poäng För att erhålla betyget fyra räcker 4 poäng För att erhålla betyget fem räcker 47 poäng

Uppgift, 0p. Skapa ett konceptuellt schema (t.ex. i form av ett UML klassdiagram) som kan representera ett enkelt rollspel enligt den engelska beskrivningen nedan. Alla avbildningsregler (multiplicities) skall anges. A player can play games with the computer where a game consists of a sequence of battles. When a player starts a battle, she can choose a certain role figure to represent her in the battle. For example, she can choose to be a warrior or a thief or a sorcerer, but there are many more role figures to choose from. Each role figure can carry out different things that help in the battle. For example, a warrior can throw spears or fire guns, while a sorcerer might throw thunderbolts or cast magic spells. Typically, there are between ten and twenty different things a role figure can do. However, what a role figure is capable of doing is dependent on the skill level of the player. Here are a few concrete examples: - A player with skill level 0 who chooses to be a sorcerer can throw thunderbolts - A player with skill level 00 who chooses to be a sorcerer can throw thunderbolts, cast magic spells, and throw daggers - A player with skill level 0 who chooses to be a warrior can fire guns - A player with skill level 50 who chooses to be a warrior can fire guns, throw spears, and throw daggers The skill level of a player varies during a game. After each battle the skill level increases how much depends on the success of the player in the battle. The conceptual schema should make it possible to represent sentences like: - The skill level of Peter is 20 when he starts the game, but it increases to 40 at the second battle and at the last battle his skill level is 220. It should be possible to get answers to queries like: - If Peter had chosen to be a sorcerer in the second battle of the game he started 0220 2:00, which things had he been capable of doing? GAME gameid PLAYER playerid CAPABILITY SPEC skill level BATTLE battleseqno skill RLE FIG name ACTIN actionname Uppgift 2, 8p. Konstruera ett konceptuellt schema (t.ex. i form av ett UML klassdiagram) som uppfyller följande två villkor:. m det konceptuella schemat översätts till ett relationsdatabasschema så erhålles det relationsdatabasschema som återfinns nedan 2. Det konceptuella schemat får innehålla högst tre klasser (om Du gör ett ER-schema, högst tre entiteter) I schemat skall anges alla avbildningsregler (multiplicites) samt för varje klass dess identifierare. Relationsdatabasschema: R(A, B, F)

S(A, B, C, G) T(A, B, A2, B2, C2) U(A, B, A2, B2, C2, H) V(A, B, C, A2, B2, C2) S.(A,B) << R.(A, B) T.(A, B) << R.(A, B) T.(A2, B2, C2) << S.(A, B, C) U.(A, B) << R.(A, B) U.(A2, B2, C2) << S.(A, B, C) V.(A, B, C) << S.(A, B, C) V.(A2, B2, C2) << S.(A, B, C) Följande notation används ovan: PERSN(namn, adress, telnr), HUND(hundid, ägarnamn, ägaradress, ras) Primärnycklar är understrukna. Relationen HUND innehåller ett attribut benämnt ägare som utgör främmande nyckel mot tabellen PERSN. Detta skrivs på följande sätt: HUND.(ägarnamn, ägaradress) << PERSN.(namn, adress) där namn, adress utgör primärnyckel i tabellen PERSN. R A B F S C G U H Uppgift 3, 0p. Betrakta följande relationsdatabasschema: FLD(Namn, Längd) LAND(Namn, Yta) FLYTER_GENM(Flod, Land) GRÄNSAR_MT(Land, Land2 ) KUST_MT(Land, Hav) MYNNAR_I(Flod, Hav, Land) // Floden Flod mynnar i havet Hav i landet Land

(Primärnycklar är angivna med fetstil.) FLYTER_GENM.Flod << FLD.Namn FLYTER_GENM.Land << LAND.Namn GRÄNSAR_MT.Land << LAND.Namn GRÄNSAR_MT.Land2 << LAND.Namn MYNNAR_I.Flod << FLD.Namn MYNNAR_I.Land << LAND.Namn a) Skriv följande fråga i Relationsalgebra och SQL: Vilka länder gränsar mot exakt samma länder som landet Georgien? (4p) Rättning: Någon form av kvot eller kombinationer som simulerar kvot måste vara med. Vi har inte gett avdrag för de som inte tagit fram exakt samma utan bara samma. Georgien_grannar --> PILand2 (SIGMA Land = 'Georgien' (GRÄNSAR_MT)) Icke_Georgien_grannar --> PILand2 (GRÄNSAR_MT) DIFFERENS Georigen_grannar Har_alla_Georgien_grannar --> GRÄNSAR_MT KVT Georgien_grannar Har_minst_en_granne_som_Georgien_inte-Har --> PILand (GRÄNSAR_MT JIN Icke-Georgien_grannar) GRÄNSAR_MT.Land2 = Icke_Georigen_grannar.Land2 6 (SIGMA Land <> 'Georgien' (Har_alla_Georgien_grannar) DIFFERENS Har_minst_en_granne_som_Georgien_inte_har a) Skapa en trigger som upprätthåller följande konsistensregel: Relationen GRÄNSAR_MT är symmetrisk, dvs vid INSERT av en rad i tabellen GRÄNSAR_MT ska ytterligare en rad läggas till som realiserar att om landet X gränsar mot landet Y så ska även landet Y gränsa mot landet X. (3p) CREATE TRIGGER symmetri AFTER INSERT N GRÄNSAR_MT REFERENCING NEW AS n FR EACH RW MDE DB2SQL WHEN (n.land NT IN (SELECT Land2 from GRÄNSAR_MT WHERE Land = n.land2) INSERT INT GRÄNSAR_MT VALUES(n.Land2, n.land); a) Realisera tabellerna LAND och KUST_MT som två CREATE TABLE satser. Definitionerna ska inkludera sk. key business rules, dvs regler för vad som händer om man tar bort den ena av två tabeller som är relaterade via främmande nycklar. (3p) CREATE TABLE LAND(Land varchar(50) NT NULL, Yta integer not null, primary key(land));

CREATE TABLE KUST_MT(Land varchar(50) NT NULL, Hav varchar(50) NT NULL, primary key(land, Hav), foreign key(land) REFERENCES Land(Land) N DELETE CASCADE N UPDATE RESTRICT) Rättning: lika varianter finns. Eftersom den främmande nyckeln inte var utsatt i tentamen så bör det inte ge avdrag om den inte tagits med. Däremot ges avdrag om man deklarerat främmande nycklar i tabellen LAND. Uppgift 4, 8p. Betrakta följande relationsschema: ANSTÄLLD(Anställningsnummer, Rumsnummer, Lönegrad, Avdelning, Antal_kvadratmeter, Lokalkostnad) Följande funktionella beroenden råder: Anställningsnummer Rumsnummer, Lönegrad Rumsnummer Antal_kvadratmeter Lönegrad, Avdelning Antal_kvadratmeter, Lokalkostnad a) (3p) Bestäm primärnyckel för ANSTÄLLD. Motivera ditt val. Primärnyckel = Anställningsnummer + Avdelning. Bevis: Anställningsnummer Lönegrad (dekomponeringslagen) Anställningsnummer Rumsnummer (dekomponeringslagen) Anställningsnummer Antal_kvadratmeter (transitiva lagen) Anställningsnummer, Avdelning Lokalkostnad (pseudotransitiva lagen) Således är minimala antalet attribut som ensamt funktionellt bestämmer övriga attribut lika med Anställningsnummer + Avdelning. Rättning: Bara Anställningsnummer alternativt Anställningsnummer, Avdelning och Lokalkostnad ger poäng b) Vilken normalform är tillämplig för ANSTÄLLD? Motivera ditt val. (2p) NF. Tabellen är inte i 2NF pga vissa attribut, tex Lönegrad mfl bara är bestämda av halva PN. c) Visa via exemplet ovan och motivera i text varför en högre normalform är att föredra framför en lägre. (3p) Icke normaliserade tabeller ger upphov till så kallade uppdateringsanomalier. Tex kan man inte lägga in uppgifter om antal_kvadratmeter i ett rum om inte rummet används av en anställd. Tas en den sista som sitter i

ett rum bort (som anställd) så försvinner alla uppgifter om detta rums storlek, sitter flera i ett rum så kan det, om det vill sig illa, bli så att rummet i fråga har LIKA uppgifter om antal_kvadratmeter dvs konsistensproblem, mao problem både vid INSERT, DELETE och UPDATE. Effektivitetsmässigt så vinner vi en del i dimensionen plats på hårddisken. Eftersom man inte längre dubbellagrar saker som t ex antal kvadratmeter för ett visst rum så minskar det utrymme detta tar. Detta under förutsättning att antalet rader som refererar till samma rum är många och att datatypen för främmande nyckeln är liten i förhållande till storleken på datatypen för antal_kvadratmeter i detta fall. I annat fall kan datastrukturen istället bli större. Vad gäller snabbhet i sökning är tendensen att högre normalform leder till FLER diskaccesser, läs flera JIN mellan tabeller. Uppgift 5, 8p. Låt U vara en mängd attribut. Låt D vara en mängd funktionella beroenden som gäller attributen i U. Låt SAT(D) beteckna mängden av de relationer (tabeller) som har alla attributen i U som kolumner och uppfyller alla funktionella beroenden i D. a) Låt U = {a,b,c,d} och D = {a b, bc d}. Ge ett exempel på en relation (tabell) som tillhör SAT(D) och en relation som inte gör det. Medlem i SAT(D): a b c d x y x m Inte medlem i SAT(D): a b c d x y x m x m x m (Bryter mot a b) b) Avgör för vart och ett av följande påståenden om det är sant eller falskt. Anser du att påståendet är sant motivera med en generell diskussion varför du anser att så är fallet. m du anser att påståendet är falskt så visa detta med ett motexempel. i) m D D2 så SAT(D) SAT(D2) FALSKT. Låt tex D = tomma mängden och D2 = {a b}. Då är vänsterledet SANT (tomma mängden är en delmängd av alla mängder). Högerledet är därmot FALSKT, dvs SAT(D) är nu mängden av ALLA relationer över U. SAT(D2) är en mindre mängd nämligen alla relationer över U som upprättnåller a b. ii) m SAT(D) SAT(D2) så D D2 FALSKT. Låt D2 = tomma mängden. Då är vänsterledet SANT. Högerledet är dock FALSKT, tomma mängden har inga delmängder. Uppgift 6, 6p. Utgå från en liten dagligvarubutik som ingår i en stor affärskedja, t.ex. en ICA-butik. Konstruera en affärsmodell (business model) för företaget. Förklara affärsmodellen i text. Här har vi inte gjort ett exakt lösningsförslag. Varianter av lösningsförslaget till seminarium 6 kan tjäna som modell. Definition av affärsmodell enligt Weill: Similar to Weill, we will visualise business models by means of the legends shown below. The legends are divided into three groups that cover the major aspects of a business model. First, there are the agents, which include the organisation from whose perspective the business model is constructed (square), customers (left-facing pentagons), suppliers (right-facing pentagons), and allies (split squares). Secondly, there are the relationships between the agents shown by lines. Thirdly, there are flows of products or services (arrow labelled 0 ), money (arrow labelled ), and information (arrow labelled i ). The last item, the information, is based on the messages that

flow through the relationships between the agents. nly information pertaining to the transactions occurring is considered here, not information that constitutes products, e.g. downloadable software. Typically, the information is acquired through systematic research about a product or service. A traditional linear industry value chain would have a business model like this one, showing products flowing upwards the chain from suppliers to customers and money flowing in the opposite direction. Supplier s supplier Supplier MyCompany Customer Customer s customer Business Model for Industry Value Chain rganisations may participate in arbitrarily complex business models. However, it is possible to identify a number of basic, generic business models that can be used as building blocks to create more complex models. ne of the simplest generic business models is the direct-to-customer model shown below. The most important flows in this model are products mo ving from the organisation to the customer and a reciprocal movement of money from the customer. The distinguishing feature of this model is that the organisation sells directly to the customer without any intermediary or any other actor being involved. This can be contrasted to a business model where the organisation uses allies (like distributors and dealers) as intermediaries to the customer, see figure below. Replacing this business model with a direct-to-customer model has become increasingly popular during recent years thanks to the possibilities offered by the Internet. ne example is Dell Computer Corporation that hosts a web site, which allows customers to configure and order their computers directly from Dell without the need for any intermediary. MyCompany Customer Direct to Customer Business Model MyCompany Distributor Dealer Customer Intermediary Business Model Removing intermediaries and instead adopting a direct-to-customer model has been one of the most important uses of the Internet in business. However, the Internet has also enabled new types of intermediaries that can link customers and suppliers in ways that would be difficult or even impossible without the use of IT. ne successful type of intermediary is the full-service provider, which provides a customer within some domain with all the services needed by the customer. A full-service provider typically does not produce all the services itself, but instead functions as an intermediary between a supplier and a customer. Any domain could be covered by a full-service provider, e.g. financial services, educational services, and computer equipment. A full-service provider in a financial domain would provide different services like cash management, account

services, financial advice, stock market research, brokerage, etc. The main benefit a full-service provider can offer its customers is a single point of contact so that they do not have to interact with several different suppliers to fulfil their needs in a domain; instead, they only need to interact with the full-service provider.