Institutionen för Data- och Systemvetenskap SU/KTH Paul Johannesson, Maria Bergholtz Tentamen och lösning, 0325 2I-033, IT i Organisationer och databasmetodik Skriv bara på en sida av pappret Skriv namn på varje papper Skriv läsligt, annars rättas inte tentamen För att erhålla betyget tre räcker 35 poäng (27) För att erhålla betyget fyra räcker 42 poäng (37) För att erhålla betyget fem räcker 47 poäng (43)
Uppgift, 0p. Betrakta följande beskrivning på engelska. The health authorities in Intersylvania have decided to set up an e-procurement system that will support all the hospitals in the country. The system will enable hospitals to procure healthcare items in an efficient way based on a procedure called reverse auctions. This means that a hospital will announce a number of items it intends to procure by a tender. Several suppliers will place bids on the tender or parts of the tender. Finally, the hospital will decide which supplier (or suppliers) to choose. The procedure is described in more detail below, including a few forms to be used in the procurement. The process starts by a hospital announcing a tender. Essentially, the tender states that the hospital intends to buy a number of different items in various quantities. An example of a filled in tender form is given below. The bold labels are preprinted, while the rest is filled in for each tender. This tender states that the hospital Jubelklinik wants to buy 2000 autopsy gloves, 4000 surgery gloves, 3000 syringes, and 200 bags of blood plasma. Note that the tender is divided into two lots. The lot mechanism is useful for allowing suppliers to bid on only a part of the tender. In this case, a supplier may place a bid for only lot, or for only lot 2, or for both lots and 2. If a supplier places a bid for lot, she must provide all items in this lot, i.e. autopsy gloves as well as surgery gloves. Max price for a lot is used to state that a supplier is not allowed to place a bid for the lot with a price higher than Max price. The due date is the deadline for supplier bids, i.e. bids arriving after this date are not considered. Tender no ABC23 Hospital Jubelklinik Responsible Dr. A. Huytens Address Erdstrasse 22, Dartfeld Date Nov 2003 Due date Jan 2004 Lot Max price 2000 Item Quantity Category Autopsy 2000 Consumable glove Surgery glove 4000 Consumable Lot 2 Max price 5000 Item Quantity Category Syringe 3000 Consumable Blood plasma 200 Organic The suppliers will place bids on one or several lots of the tender. An example of a filled in bid form is given below. In this example, the supplier MedProvisio has placed a bid only on lot of the previous tender. For each required item, the bid specifies a product from the company that corresponds to the item, and the price requested. Note that different companies may offer different products for the same item, e.g. one company offers their Glove AG77 as autopsy glove, while another company offers their Glove GA55.
Tender ABC23 Supplier name MedProvisio Contact person Hans Werfgand Address Seeweg 32, Date 2 Dec 2003 Frankwerpen Lot Lotprice 000 Item Quantity Product Price Autopsy glove 2000 Glove AG77 5000 Surgery glove 4000 Glove SG88 6000 Below is a bid from another company that places bids for both lots of the tender. Tender ABC23 Supplier name MedicoSupp Contact person Alf Digstrand Address MeerStrasse 22, Date 4 Dec 2003 Frankwerpen Lot Lotprice 000 Item Quantity Product Price Autopsy glove 2000 Glove AG77 4000 Surgery glove 4000 Glove SG88 7000 Lot 2 Lotprice 9000 Item Quantity Product Price Syringe 3000 Syringe S 2000 Blood plasma 200 Blood B55 7000 The system shall be able to answer queries like the following:. Which item is the most expensive one in tender DEF456? 2. Is there any supplier who has placed a bid on each lot in tender DEF456? 3. Is there a lot in tender DEF456 for which no supplier has placed a bid? 4. Which suppliers have placed bids with a price higher than Max price? 5. Which suppliers have offered different products for the same item? 6. Which supplier has the cheapest offer for syringes in tender DEF456?
Konstruera ett konceptuellt schema (t.ex. i form av ett UML klassdiagram) som klarar av att hantera frågorna ovan samt det som beskrivs dessförinnan. All information i formulären skall kunna representeras. Avbildningsregler (cardinality constraints, multiplicities) skall anges. TENDER TenderNo Hospital Responsible Address Date DueDate BID SUPPLIER Name Address..* LOT MaxPrice..* LOTBID LotBidPrice..* ITEMNEED Quantity..* BIDLINE Price ITEM Name Category PRODUCT Name Uppgift 2, 8p. Betrakta följande konceptuella schema:
a S b R c d Q e f P g h T S identifieras av attributet a. Q identifieras av sin association till R samt attributet c. P identifieras av sin association till Q samt attributet e. T identifieras av sin association till P samt attributet g. ÖVERSÄTT DET KONCEPTUELLA SCHEMAT OVAN TILL ETT RELATIONSDATABASSCHEMA. Ange för varje relation vad som utgör primärnyckel samt vad som eventuellt utgör främmande nycklar (främmande nycklar måste specificeras med alla korrekta kolumner). I fallet främmande nycklar skall även specificeras mot vilken relation de utgör främmande nyckel. Översättningen får ej innebära att avsteg från den konceptuella modellen görs (annat än de avsteg som måste göras för att realisera relationsmodellen). Surrogatnycklar får inte införas. Använd följande notation med understrykning av primärnycklar: PERSON(namn, adress, telnr), HUND(hundid, ägarnamn, ägaradress, ras) Relationen HUND innehåller två attribut benämnda ägarnamn, ägaradress som utgör främmande nyckel mot relationen PERSON. Detta skrivs på följande sätt: HUND.(ägarnamn, ägaradress) << PERSON.(Namn, adress) där Namn, adress utgör primärnyckel i tabellen PERSON. S(a) R(a, b) Q(a, c, d) P(a, c, e, f) T(a, c, e, g, h, a, c, e, g) W(a, c, e, g, a2, c2, e2, g2)
R.a << S.a Q.a << R.a P.(a, c) << Q. (a, c) T.(a, c, e) << P.(a, c, e) T.(a, c, e, g) << T.(a, c, e, g) W.(a, c, e, g) << T.(a, c, e, g) W.(a2, c2, e2, g2) << T.(a, c, e, g) Uppgift 3, 8p. Betrakta följande recept på engelska: Salmon with mashed potatoes is made in the following way. The salmon is cut into small pieces and salt and pepper is added. Thereafter, the salmon is put into a refrigerator for 20 minutes. In parallel, the potatoes can be prepared. 5 kilos of potatoes are boiled on the furnace for 5 minutes. Thereafter, butter and salt is added and everything is mixed in a mixing machine for 2 minutes. Then, the result is inspected, and if it is not smooth enough it will be mixed one more minute. Finally, the mashed potatoes is sprinkled around the salmon and put into an oven for 35 minutes. Modellera detta recept med hjälp av ett Petri nät med tid. Alla resurser skall modelleras, både ingredienser och köksmaskiner. salmon Pepper/salt free refrigerator shelves Free ovens 20 35 start salmon end salmon start oven end oven start start potatoes Start mix Stop mix 5 2 end potatoes Start more mix potatoes Free furnaces butter+salt Free mixers not smooth Stop more mix Uppgift 4, 0p. Betrakta följande relationsdatabasschema: HOTELL(HotellId, MittChefMamn, MinChefViktklass) PERSON(Namn, Viktklass, Vikt) RUM(HotellId, Rumsnr, Rumstyp, Antal_sängar)
MÖBELTYP(MöbelId, Pris) MÖBELTILLDELNING(HotellId, Rumsnr, MöbelId) Primärnycklar är angivna i fetstil. Följande främmande-nyckel förhållanden råder: HOTELL.(MittChefNamn, MinChefViktklass) << PERSON(Namn, Viktklass) RUM.HotellId << HOTEL.HotellId MÖBELTILLDELING.(HotellId, Rumsnr) << RUM(HotellId, Rumsnr) MÖBELTILLDELNING.MöbelId << MÖBELTYP.MöbelId Följande funktionella beroenden råder: HotellId, Rumsnr Rumstyp, Antal_sängar Rumsnr Rumstyp Rumstyp Antal_sängar Namn, Viktklass Vikt Vikt Viktklass a) NORMALISERA schemat till, i tur och ordning, 2NF, 3NF och BCNF. Gör ett steg i taget, dvs gör bara den nedbrytning som behöver göras för att komma fråm NF till 2NF. Kommentera varför du gjort nedbrytningen. Gör sen den nedbrytning som behövs för att komma till närmast högre normalform osv. Kommentera varför du gjort en nedbrytning. Glöm inte att ange de nya främmande nycklar som uppstår vid normaliseringen. Tabeller i 2NF RUM(rumsNr, hotellid) RUM(rumsNr, rumstyp, antal_sängar) HOTELL(HotellId, chefnamn, chefviktklass) MÖBELTYP(möbeltypsnamn) PERSONAL(Namn, viktklass, vikt) MÖBELTILLDELNING(Rumsnr, hotellid, möbeltypsnamn) Vi lägger till RUM. rumsnr = RUM.rumsNr (RUM är inte så bra namn för nya tabellen men jag kommer inte på något annat just nu) Vi skapade den nya tabellen RUM pga att rumstyp och antalsängar är beroende av bara en del av primärnyckeln för RUM nämligen rumsnr. För 2NF ska alla icke-nyckelattribut vara beroende av HELA primärnyckeln. Tabeller i 3NF RUM(rumsNr, hotellid) RUM(rumsNr, rumstyp) RUM2(Rumstyp, antal_sängar) HOTELL(HotellId, chefnamn, chefviktklass) MÖBELTYP(möbeltypsnamn) PERSONAL(Namn, viktklass, vikt) MÖBELTILLDELNING(Rumsnr, hotellid, möbeltypsnamn) Vi lägger till RUM.rumstyp = RUM2.rumstyp
Vi skapade den nya tabellen RUM2 pga att det fanns ett transitivt beroende mellan de två icke-nyckelattributen rumstyp och antal_sängar i den ursprungliga tabellen RUM. d) Tabeller i BCNF RUM(rumsNr, hotellid) RUM(rumsNr, rumstyp) RUM2(Rumstyp, antal_sängar) HOTELL(HotellId, chefnamn, chefviktklass) MÖBELTYP(möbeltypsnamn) MÖBELTILLDELNING(Rumsnr, hotellid, möbeltypsnamn) PERSONAL(Namn, vikt) PERSONAL (Vikt, viktklass) (Nu tog jag bara ett alternativ och testar non-loss på detta:) Namn Viktklass Vikt PERSONAL a b a a PERSONAL b a a Vi testar Namn, Viktklass --> Vikt, ingen rad har a för både Namn och Viktklass så detta leder inte till byte. Vi testar Vikt --> Viktklass, både PERSONAL och PERSONAL har ett a för Viktkolumnen. Eftesom PERSONAL dessutom har ett a för viktklasskolumnen får vi byta b mot a för tabellen PERSONAL för denna kolumn (se ovan!) Slutsats: En hel rad innehåller bara a:n dvs nedbrytningen var non-loss! OBS: Non loss behövde inte testas för att få full poäng. b) Varför normaliserar man, för och nackdelar? Motivera i text och exemplifiera för och nackdelar, svaren i a) kan användas som exempel, eller hitta på andra exempel. Man normaliserar först och främst för att undvika redundans. Varje faktum på en säger en plats enbart. Redundans kan leda till så kallade uppdateringsanomalier. Vill man tex ändra på vilken antalet en viss rumstyp har så måste man ändra på alla ställen som denna rumstyp förekommer på olika hotell) risk för inkonsistens om ngn rad blir glömd (då kan ju en och samma rumstyp kan råka peka ut olika antalsängar). Dessutom vinner man i plats. Databasen blir vanligen mindre. Det kan man t ex se i svaret ovan där man bara behöver ange på ETT ställe vilket antal sängar en viss rumstyp har.i a) var man tvungen att upprepa detta faktum på varje rad i den ursprungliga tabellen RUM där en viss rumstyp förekom i komb med olika hotel. I vissa undantagsfall kan man få en större databas (om främmande nycklarna som införs i och med normaliseringen är längre (i bytes) än de attribut som inte upprepas lika många gånger och/eller om antalet rader i databasen är få. Så vad förlorar man då, jo oftast i tid. En godtycklig transaktion mot databasen kommer att ta längre tid eftersom den förmodligen involverar fler tabeller, läs fler joins behöver göras. Uppgift 5, 0p. a) Avgör för fört och ett av följande påståenden om det är SANT eller FALSKT. Om du tror att ett påstående är sant motivera varför med ett (kortfattat) generellt resonemang. Om du tror att ett påstående är falskt, ge ett motbevis. Svar utan motivering = 0 p. (4p) i. Projektionsoperatorn, π, tillämpad på en relation R returnerar färre eller lika många kolumner som R hade från början men lika många rader, dvs π(r) = R.
FALSKT. Om man π(r) attribut och detta attribut råkar vara lika med NULL för någon rad så kommer ju inte just den raden med. Alternativt om vi tar fram några rader som råkar ha samma värden i just de valda attributen så blir ju dessa dubbletter med avseende på varandra och bara en kommer med. ii. Selektionsoperatorn, σ, tillämpad på en relation R returnerar färre eller lika många rader som R hade från början men lika många kolumner. SANT. Selections-operatorn skär bort rader (eller låter dem vara kvar). Antalet kolumner påverkas dock inte. NULL i ngt kolumnvärde är ett värde det också. b) Betrakta följande relationsdatabasschema: HUSTYP(Id, Pris, Antal_kvadratmeter) BYGGBOLAG(Namn, Adress, Telefon) HUSKATALOG(Namn, Id, År) Primärnycklar är angivna i fetstil. Följande främmande nyckel förhållanden råder: HUSKATALOG.Namn << BYGGBOLAG.Namn HUSKATALOG.Id << HUSTYP.Id Skriv följande fråga i SQL: (6p) Vilket byggbolag (ange Namn och Adress) hade flest hustyper i sin katalog år 975 av de bolag som hade alla hustyperna i sin katalog året innan, dvs 974? En svårighet var möjligen om man kunde betrakta antalet hustyper som fixt eller ej. Båda lösningarna kommer att godtas. Fixt antal hustyper: En hjälpsam vy CREATE VIEW hade_alla_74 AS (SELECT B.Namn FROM BYGGBOLAG B WHERE NOT EXISTS (SELECT Id FROM HUSTYP WHERE Id NOT IN (SELECT Id FROM HUSKATALOG WHERE År = 974 AND Namn = B.Namn)) En till: CREATE VIEW byggen75 AS (SELECT Namn, COUNT(DISTINCT(Id)) AS Antal FROM HUSKATALOG, hade_alla_74 WHERE hade_all_74.namn = KATALOG.Namn AND År = 975 GROUP BY Namn) SELECT Namn FROM byggen75 WHERE Antal = (SELECT MAX(Antal) from byggen75) Om antalet hustyper inte är fixt utan beroende av vilka som byggs varje år:
En hjälpsam vy: CREATE VIEW byggda74 AS (SELECT DISTINCT(Id) FROM KATALOG WHERE År= 974 ) En till: CREATE VIEW hade_alla_74 AS (SELECT B.Namn FROM BYGGBOLAG B WHERE NOT EXISTS (SELECT Id FROM byggda74 WHERE Id NOT IN (SELECT Id FROM HUSKATALOG WHERE År = 974 AND Namn = B.Namn)) CREATE VIEW byggen75 AS (SELECT Namn, COUNT(Id) AS Antal FROM KATALOG, hade_alla_74 WHERE hade_all_74.namn = KATALOG.Namn AND År = 975 GROUP BY Namn) SELECT Namn FROM byggen75 WHERE Antal = (SELECT MAX(Antal) from byggen75) Uppgift 6, 4p. Här var de inlämnade svaren så bra att jag nästan backar från mitt löfte om att göra ett lösningsförslag. Men håll till godo, det är dock inte bättre än det ni lämnat in. a) Definiera kort begreppen Supply Chain Management och Customer Relationship Management. Följande exempel kan tjäna som användningsfall (eller hitta på egna exempel): Kunder köper varor av en återförsäljare. Återförsäljaren köper varor av en tillverkare. Tillverkaren tillverkar och levererar varor till återförsäljaren. Återförsäljaren levererar dels varor hem till kunden, och säljer dels varor till kunden över disk. Begreppet Supply Chain Managment (SCM) handlar att hantera (för att inte säga optimera) länkkedjan av aktiviteter som är inblandade i köpande-processer, säljande-processer och tillverkninsprocesser. Målet är en integration både av processerna och aktörerna (säljare, köpare, tillverkare) till exempel med avseende på den logistik som behövs för att optimera ledtider (läs göra dem kortare) (= tiden från ax till limpa eller i det här fallet alla aktiviteter som är inblandade i att tillverkaren tillverkar produkter, annonserar sina produkter för sina kunder (återförsäljarna), levererar sina produkter till återförsäljarna och hur de får betalt, från återförsäljarnas synvinkel hur de hittar bästa produkter till bästa pris, lagerhållning, hur de betalar tillverkarna, hur de får tag i sina kunder, hur de säljer till kunderna, orderhanteringen mot kund etcetera.). SCM skulle kunna översättas som styrande av tillhandahållande, dvs vad det gäller är att styra processerna som rör vem som har tillgång till vad och när i termer av produkter i ena riktningen och betalningar i andra riktningen (notera att det råder en dualitet mellan å ena sidan tillverkare återförsäljare respektive återförsäljare (slut-) kund). Noteras bör även att begreppet information dels kan ses som något som ingår i och möjliggör processerna ovan, dels som en produkt vilken som helst som köpts och betalas för. Allt för att korta ledtider och optimera lagerhållning.
Customer Relationship Management (CRM) tangerar det förra minus produkt-logistiken. Här ligger betoningen på att skapa strukturer för att styra och hantera relationen företag kund (exempelvis återförsäljare (kund) vs tillverkare (företag) och återförsäljare (företag) vs kund (kund)). De processer som sak koordineras och integreras här är följaktligen alla affärsprocesserna som rör företagets interaktion med kunden vad gäller försäljning, marknadsföring (hitta nya kunder) ch inte minst support (behålla de man har). Bygger på idéer om att det är mycket dyrare och svårare att hitta nya kunder än att hålla befintliga kunder nöjda. Missnöjda kunder sprider dåliga erfarenheter. Således underbygger CRM strukturer för att göra befintlig service (information, reklamation, support) bättre mot (existerande) kund (därmed inte sagt att inte strukturer för marknadsföring inte behövs, det gör de. Men enligt resonemanget ovan saknas framförallt bra strukturer för att hantera relationerna till existerande kunder). Stöd för processerna ovan behövs. För att hitta generella felkällor och bra strategier för support används olika typer av informationssystem (mer om detta i b) ) som analyserar data operationellt, taktiskt och strategiskt. Detta leder till implementering av strategier för sk. Call center management (försäljning, support på olika nivåer). b) För vart och ett av det två begreppen i a) förklara hur ett Management Information System, ett Decision support system och ett Transaction Processing System skulle kunna användas. Exemplifiera gärna med användarfallet. Management Information Systems är en typ av beslutstödsystem, som hanterar företagets interna processer. Exempel (från föreläsning 8) skulle kunna vara Sammanfattningsrapport aggregerar data från många transaktioner och presenterar dem i ett koncist format: Månatlig försäljning, Årlig personalomsättning, Avvikelserapport - beskriver avvikelser mellan prognos och faktiskt utfall, Budgetöverskridande, Försäljningsminskning, Antal varor i lager vid en viss punkt. Samtliga funktioner ovan behövs för att fatta korrekta beslut vid Supply Chain Managment. Om man vill skulle man kunna säga att MIS stöder SCM på en taktisk nivå, dvs här behövs inte funktioner för att lagra enskilda transaktioner utan snarare stöd för att sammanställa tranaktioner och för att dra slutsatser om förändringar. För att kunna utföra de processer och den integration av processer som behövs inom SCM och även CRM (tex analysera vilka typer av klagomål som är vanligast). Transaction Processing Systems (TPS) - system som hanteraroch lagrar transaktioner Transaktion: ett utbyte mellan två parter Uttag från bankkonto Förfrågan om pris på en produkt Beställning av en vara. Det vill säga all den dagliga verksamheten hos återföräljare och tillverkare måste naturligtvis lagras via ett informationssystem (ett databashanteringssystem är ett ypperligt exemempel på ett TPS). Denna information är i sin tur indata till ett MIS (vill man kan man säga att TPS:en arbetar på operationell nivå, information lagras och sammanställs i någon mån men stöd för analys av informationen saknas). För CRM lagras naturligvis uppgifter om kunder, uppgifter om klagomål, uppgifter om service etectera. DDS Desicion Support System. Är en typ av intelligent form av beslutstödsystem. Med intelligent menas här att systemet stöder användarna (läs ledningen i företag) (antingen de ingår i ett SCM eller CRM) ISS - att fatta beslut om ostrukturerade problem. Data mining system och expertsystem är exemel på DDS:er. Inom CRM kan DDS:er användas för att hitta generalla mönster vad gäller kunders och support-avdelningars beteende och också (i varierande grad) föreslå lösningar på problem och flaskhalsar. För SCM används datamining i stor utsträckning för att ur stora datamängder snabbt söka fram svar på komplexa frågor. Övrigt Ange Din email-adress för att underlätta kommunikation! Glöm inte fylla i den elektroniska kursutvärderingen på kursens hemsida!