17.12.1999

OUTOKUMPU POLARIT AMRO-PROJEKTI:

TIETOKANTA JA SEN KÄYTTÖLIITTYMÄ

JANNE GUSTAFSSON

TOMMI GUSTAFSSON

Mat-2.108 Systeemianalyysin erikoistyöt

Systeemianalyysin laboratorio

Teknillinen Korkeakoulu

2

SISÄLLYSLUETTELO

1. JOHDANTO........................................................................................................................................ 4

2. ONGELMAKENTÄN KUVAUS .............................................................................................................. 5

2.1 AMRO-projektin tausta ja ongelman kuvaus ............................................................................... 5

2.2 Outokumpu Polarit ..................................................................................................................... 5

2.3 Käsitteet ..................................................................................................................................... 6

2.4 Teräksenvalmistusprosessi.......................................................................................................... 92.4.1 Johdatus teräksenvalmistusprosessiin ................................................................................................................ 9

2.4.2 Sulatus kromikonvertterissa ja valokaariuunissa .............................................................................................. 10

2.4.3 Siirtosenkka, AOD-konvertteri ja prosessin muut osat...................................................................................... 11

2.5 Teräksen valmistukseen liittyvät tekijät ..................................................................................... 112.5.1 Koostumusrajat ja sakkofunktiot ..................................................................................................................... 11

2.5.2 Raaka-aineiden käyttörajoitukset ja saatavuus.................................................................................................. 13

2.6 Johdatus estimointiin ja optimointiin ........................................................................................ 13

3. PROJEKTIN VAIHEET JA OHJELMISTON ARKKITEHTUURI................................................................... 16

3.1 Outokumpu Polarit Oy:n AMRO-projektin historiaa ................................................................. 16

3.2 Projektin vaiheistus .................................................................................................................. 16

3.3 Outokumpu Polarit Oy:n tietojärjestelmät................................................................................. 16

3.4 Arkkitehtuuri ............................................................................................................................ 173.4.1 Periaatteet ...................................................................................................................................................... 17

3.4.2 Yleiskuvaus.................................................................................................................................................... 17

3.4.3 Tietokanta ...................................................................................................................................................... 19

3.4.4 Tietokannan käyttöliittymä.............................................................................................................................. 20

3.4.5 Optimointi- ja estimointimoduuli .................................................................................................................... 20

3.4.6 Huomioita ...................................................................................................................................................... 20

3.5 Projektin analyysi..................................................................................................................... 213.5.1 Tavoitteen saavuttaminen................................................................................................................................ 21

3.5.2 Riskit ............................................................................................................................................................. 21

4. TIETOKANTA .................................................................................................................................. 22

4.1 Johdatus tietokantoihin............................................................................................................. 22

4.2 Tietokantoihin liittyvät käsitteet ................................................................................................ 23

4.3 E/R-kaavion perusteet............................................................................................................... 25

4.4 Johdatus AMRO:n tietokantaan, SQL:ään ja tietokannan ominaisuuksiin ................................. 264.4.1 E/R-kaaviosta SQL:ään................................................................................................................................... 26

4.4.2 Päivitys- ja poistopolitiikat sekä oikeellisuustarkistukset.................................................................................. 27

4.4.3 Indeksit .......................................................................................................................................................... 29

4.5 Tietokannan taulut.................................................................................................................... 294.5.1 Yleiskatsaus tauluihin ..................................................................................................................................... 29

4.5.2 Yleisesti taulujen kentistä ............................................................................................................................... 30

4.6 Offline-tietokannan toteutus Borland Database Enginellä......................................................... 32

3

4.6.1 Borland Database Enginen asetukset ............................................................................................................... 33

4.7 Tietokannan analyysi ................................................................................................................ 344.7.1 Tietokannan suunnittelun periaatteet ............................................................................................................... 34

4.7.2 Tietokannan rajoitukset ja sopivuus käyttötarkoitukseensa ............................................................................... 35

4.7.3 Parannusehdotuksia ........................................................................................................................................ 35

5. TIETOKANNAN KÄYTTÖLIITTYMÄ ................................................................................................... 37

5.1 Johdatus tietokannan käyttöliittymään ...................................................................................... 37

5.2 Perusratkaisut .......................................................................................................................... 37

5.3 Käyttöohje ................................................................................................................................ 385.3.1 Pääikkuna....................................................................................................................................................... 38

5.3.2 Näkymä.......................................................................................................................................................... 39

5.3.3 Tietueen lisäys ja editointi .............................................................................................................................. 40

5.4 Implementaatiotason rakenne ................................................................................................... 435.4.1 Käyttöliittymäohjelmiston rakenne.................................................................................................................. 43

5.4.2 DBStructure ................................................................................................................................................... 44

5.4.3 TableDialog.................................................................................................................................................... 45

5.5 Käyttöliittymän analyysi ........................................................................................................... 455.5.1 Laajennetavuus............................................................................................................................................... 45

5.5.2 Rajoitukset ..................................................................................................................................................... 45

5.5.3 Sopivuus käyttötarkoitukseensa ja parannusehdotuksia .................................................................................... 46

6. OHJELMISTON INTEGEROINTI OUTOKUMMUN JÄRJESTELMIIN ......................................................... 48

6.1 Yleiskuvaus............................................................................................................................... 48

6.2 Toteutus MVC-arkkitehtuurilla ................................................................................................. 48

6.3 Toteutus ilman MVC-arkkitehtuuria.......................................................................................... 49

6.4 Tietokanta ................................................................................................................................ 49

6.5 Käyttöliittymä........................................................................................................................... 50

6.6 Optimointi- ja estimointimoduuli .............................................................................................. 50

7. YHTEENVETO JA POHDINNAT .......................................................................................................... 52

LIITTEET: 1. E/R-KAAVIO

2. TIETOKANNAN SQL-SKRIPTI

3. TAULUKKO YKSILÖJOUKOISTA JA NIITÄ VASTAAVISTA TAULUISTA

4. DBSTRUCTURE:N UML-KAAVIO

5. ARKKITEHTUURISUUNNITELMA 1 (MVC)

6. ARKKITEHTUURISUUNNITELMA 2 (ILMAN MVC:TÄ)

4

1. JOHDANTO

Tämä erikoistyö on osa Outokumpu Polarit Oy:lle tehtävää AMRO-projektia

(Adaptiivinen Metallinvalmistuksen Raaka-aineenkäytön Optimointi; Adaptive

Metallurgical Raw material Optimization), jonka tarkoituksena on tuottaa

asiakasyritykselle uusi valokaariuunin panostuksen optimointijärjestelmä.

Uudella järjestelmällä on tarkoitus korjata vanhassa havaittuja puutteita ja

vähentää raaka-ainekuluja vähintään yhdellä promillella. Ohjelmisto jakaantuu

neljään osaan: tietokantaan, tietokannan käyttöliittymään, optimointi- ja

estimointimoduuliin sekä sen käyttöliittymään. Periaatteellisen jaon lisäksi

ohjelmisto on toteutettu niin, että osat toimivat toisistaan erillisinä

kokonaisuuksina. Kaksi ensimmäistä osaa kuuluvat varsinaisesti tämän

erikoistyön piiriin ja kahta viimeistä käsittelee erikseen julkaistu Jussi

Ikäheimon diplomityö (1999). Ikäheimon diplomityöhön viitataan kuitenkin

soveltuvin osin, jotta lukijalle jää selkeä käsitys kokonaisuuden toiminnasta.

AMRO-ohjelmisto valmistetaan kahdessa vaiheessa. Ensimmäisessä vaiheessa

luodaan Outokummun tietojärjestelmistä irrallaan toimiva, nk. offline-versio,

joka kuitenkin suunnitellaan ja ohjelmoidaan siten, että siirtyminen

Outokummun järjestelmiin tapahtuu toisessa vaiheessa mahdollisimman

vaivattomasti. Toinen vaihe käsittää ohjelman integroimisen asiakasyrityksen

tietojärjestelmiin. Tämä erikoistyö on kirjoitettu ensimmäisen vaiheen

päätyttyä, joten tarkastelun kohteena on AMRO:n offline-versio. Erikoistyön

kuudes kappale on omistettu online-version tarkasteluun.

Erikoistyö on jaoteltu seuraavasti. Kappale 2 esittelee projektin taustan ja

ongelmakentän laajemmin. Kappaleessa 3 keskitytään projektin eri vaiheisiin,

ohjelmiston kokonaisarkkitehtuurin esittelyyn ja kuvataan rajapinnat sekä

ohjelman eri osien välisen kommunikaation kulku. Kappaleet 4 ja 5 on varattu

tietokannan ja sen käyttöliittymän esittelyyn ja arviointiin. Kuudennessa

kappaleessa tutustutaan Outokummun tietojärjestelmiin ja siihen, miten offline-

versio saadaan integroitua niihin online-versioksi. Seitsemäs kappale sisältää

lyhyen yhteenvedon dokumentin pääkohdista.

Janne Gustafssonin työpanos käsittää kappaleet 1, 2, 4 ja 7. Tommi Gustafsson

on laatinut kappaleet 3, 5 ja 6.

5

2. ONGELMAKENTÄN KUVAUS

2.1 AMRO-PROJEKTIN TAUSTA JA ONGELMAN KUVAUS

Romujen käyttö teräksen raaka-aineena on hyvin edullista. Romut muodostavat

vain murto-osan teräksen valmistuskustannuksista, vaikka tyypillisesti lähes

40% teräksen raaka-aineesta on romua. Sen sijaan valtaosa raaka-

ainekustannuksista tulee erilaisista seosaineista. Edulliseen romujen

kierrätykseen liittyy kuitenkin kaksi ongelmaa (Lahdelma et al 1999).

Ensinnäkin romut koostuvat monista, osin havaitsemattomistakin yhdisteistä.

Riippuen valmistettavan teräksen koostumustavoitteista toiset näistä yhdisteistä

voivat olla arvokkaita seosaineita kun taas toiset haitallisia epäpuhtauksia.

Toisekseen romulaatujen sisällä esiintyy koostumusvaihtelua, joten romuista ei

voida tehdä tarkkoja kemiallisia analyysejä. Niinpä on olemassa riski, että

romujen mukana sulaan joutuu suuriakin määriä epätoivottuja aineita, mikä

johtaa pahimmillaan koko sulatuksen hylkäämiseen. Haastena onkin löytää

sellainen panostus, että saadaan mahdollisimman hyvälaatuista terästä

mahdollisimman halvoista raaka-aineista.

AMRO-projekti on VTT:n ja Teknillisen Korkeakoulun yhteistyönä toteuttama

hanke, jonka rahoittajina toimivat TEKES, Imatra Steel, Outokumpu Polarit,

Outokumpu Pori Copper ja Kuusakoski. AMRO:on kuuluu kolme itsenäistä

hanketta, joista yhtä tämä erikoistyö käsittelee. Tämän hankkeen tavoitteena on

kehittää Outokumpu Polaritille ohjelmisto, joka etsii sellaisen romupanostuksen

valokaariuuniin, jolla saadaan laskettua teräksenvalmistusprosessin raaka-aine-

kustannuksia vähintään 0,1 prosenttia. Hanketta tarkastellaan lähemmin

kappaleessa 3.

2.2 OUTOKUMPU POLARIT

Outokumpu on suomalainen metallialan konserni, joka keskittyy

perusmetallien, ruostumattoman teräksen ja kuparin valmistukseen. Vuonna

1976 toimintansa aloittanut, Torniossa toimiva Outokumpu Polaritin

terästehdas valmistaa ruostumatonta terästä ja työllistää noin 1700 henkeä.

Tehtaan teräksen laadun takaa ISO 9002 –sertifioioitu laatujärjestelmä.

Outokumpu Polarit toimii läheisessä yhteistyössä Kemin kromikaivoksen

(Outokumpu Chrome) kanssa, joka toimittaa Tornion tehtaalle kromia

6

ruostumattoman teräksen raaka-aineeksi.

Outokummulla on 10% osuus Euroopan ruostumattoman teräksen markkinoista

ja 4 prosenttia koko maailman markkinoista. Vuonna 1998 Outokumpu Polariin

myynti laski runsaseen 4,3 miljardiin markkaan, mihin vaikutti hintojen lasku

ja vaikea markkinatilanne. Tavaraa toimittettiin kuitenkin hieman edellisvuotta

enemmän, noin 1,1 miljonaa tonnia (Outokumpu WWW).

2.3 KÄSITTEET

Teräksenvalmistukseen liittyy maallikolle melko vieraita käsitteitä, jotka on

aluksi syytä selventää. Lisäksi tilastomatemaattiset ja optimointiin liittyvät

termit voivat olla näihin alueisiin perehtymättömälle outoja. AMRO:n käyttöön

on vakiintunut seuraava termistö.

Alkuaineella (element) tarkoitetaan kemiallista alkuainetta kuten rautaa,

molybdeenia tai nikkelia. Alkuaineilla on kemiallinen merkki, kuten edellä Fe,

Mo tai Ni. Alkuainepitoisuus on alkuaineen prosenttuaalinen osuus

metalliseoksesta.

Raaka-aineet (raw material) ovat teräksen valmistukseen käytettyjä aineita.

Useat AMRO:n raaka-aineet ovat eri alkuaineita sisältäviä romuja (scrap) tai

ferrokromia (FeCr).

Prosessipaikka (process location) on jokin teräksenvalmistusprosessin vaihe.

Prosessin vaihe voi olla esimerkiksi uuni, johon panostetaan raaka-aineita tai

edellisestä uunista tullutta sulaa. Outokummun teräksenvalmistusprosessissa on

neljä uunia: valokaariuuni, AOD-konvertteri, kromikonvertteri ja senkkauuni.

Sula (melt) on metalliseos, joka saadaan sulatuksen jälkeen uunista. Sula ei ole

tavallisesti uuniin panostettujen aineiden summa, vaan uunin saannot

määräävät osuuden, joka panostetuista aineista saadaan sulatuksen jälkeen ulos

sulaan.

Saanto (yield) on se prosenttuaalinen osuus panostetusta aineesta, joka saadaan

sulatuksen jälkeen ulos uunista. Saantoja on kahta lajia: alkuainesaantoja

(element yield) ja raaka-ainesaantoja (raw material yield). Alkuainesaanto

ilmaisee prosenttiosuuden tietystä sulaan saadusta alkuaineesta, kun taas raaka-

7

ainesaanto kertoo, kuinka suuri osuus raaka-aineen massasta välittyy

valmistettavaan sulaan. Ne osat alku- ja raaka-aineista, joita ei saada sulaan,

tavallisesti joko kuonaantuvat uunin seinämiin tai palavat sulatuksen aikana.

Saannot riippuvat uunista, sillä uunin ominaisuudet, kuten lämpötila,

vaikuttavat niissä tapahtuviin kemiallisiin reaktioihin. Raaka-ainesaantoja

voidaan käyttää laskemaan uunista saatavan sulan paino, kun taas

alkuainesaantoilla arvioidaan eri alkuaineiden pitoisuuksia kyseisessä sulassa.

Sulatus (melting, heat) tarkoittaa laajassa mielessä koko teräksen-

valmistusprosessin läpikäymistä raaka-aineiden panostuksesta valmiin teräksen

saapumiseen varastoon. Suppeammassa mielessä se viittaa yhden uunin

panostukseen ja kuumentamiseen.

Tuote (product) on teräslaatu, jonka koostumuksen määräävät sille erikseen

asetetut koostumusrajat (element limits). Koostumusrajat asettavat ylä- ja

alarajan teräslaadun alkuainepitoisuuksille ja määräävät näin tuotteen

kemialliset ominaisuudet.

Estimoinnilla (estimation) tarkoitetaan jonkin asian, tässä tapauksessa romun

alkuainepitoisuuksien, likimääräistä arviointia jollain matemaattisella

menetelmällä. Estimointi suoritetaan suuren havaintoaineiston perusteella, joka

AMRO:ssa saadaan tehdyistä sulatuksista vertailemalla valokaariuuniin

panostettuja romuja ja uunista ulos saadun sulan alkuainepitoisuuksia.

Matemaattisena menetelmänä käytetään rekursiivista pienimmän neliösumman

menetelmää (RPNS). Estimaatti (estimate) on puolestaan estimoinnin tulos; nyt

siis romun arvioitu alkuainepitoisuus.

Optimointi (optimisation) tarkoittaa joidenkin asioiden asettamista niin, että

haluttu kriteeri saa parhaan mahdollisen arvonsa. AMRO:ssa etsitään sellaista

valokaariuunin panostusta, jolla saadaan mahdollisimman hyvälaatuista terästä

mahdollisimman halvalla (kaksi kriteeriä). Optimointiin on käytössä useita

tekniikoita, ja AMRO:ssa sovellettu menetelmä on kuvattu Jussi Ikäheimon

diplomityössä (1999). Optimointi liittyy läheisesti alkuainepitoisuuksien

estimointiin, sillä optimointialgoritmien tulee tietää eri raaka-aineiden

alkuainepitoisuuksien tilastolliset jakaumat, jotka saadaan estimoinnin

tuloksena.

8

Tilastollinen jakauma (statistical distribution) määrää satunnaismuuttujan

saamien arvojen todennäköisyydet. Jakaumat voivat olla hyvinkin eri

muotoisia, mutta yleisin jakaumaperhe on normaalijakauma (normal

distribution) eli Gaussin jakauma, josta on esitetty esimerkki kuvassa 1.

Kaikille jakaumille voidaan määritellä kaksi tilastollista tunnuslukua:

odotusarvo (expectation value) ja varianssi (variance). Nyrkkisääntönä voidaan

sanoa, että odotusarvo kertoo satunnaismuuttujan keskimäärin saaman arvon ja

varianssi kuvaa satunnaismuuttujan saamien arvojen vaihteluväliä. Usein

varianssia havainnollisempi vaihteluvälin mitta on keskihajonta (standard

deviation), joka on varianssin neliöjuuri. Kaikissa normaalijakaumissa 95,3 %

satunnaismuuttujan saamista arvoista jää odotusarvosta kahden keskihajonnan

säteelle.

Jakauman leveys, keskihajonta

Jakauman keskikohta,odotusarvo

Kuva 1. Normaalijakauma odotusarvolla 2 ja keskihajonnalla 1.

9

2.4 TERÄKSENVALMISTUSPROSESSI

2.4.1 JOHDATUS TERÄKSENVALMISTUSPROSESSIIN

Rauta (Fe), kromi (Cr), hiili (C) ja nikkeli (Ni) ovat ruostumattoman teräksen

tärkeimmät aineosat, ja koko teräksenvalmistusprosessi tähtää näiden

alkuaineiden pitoisuuksien säätämiseen valmistettavassa sulassa. Teräkseksi

(steel) kutsutaan rautalejeerinkiä, joka sisältää korkeintaan 2 % hiiltä. Teräksen

raaka-aineet voivat sisältää hiiltä huomattavasti yli tämän määrän, ja niinpä

hiiltä joudutaan polttamaan pois puhaltamalla sulaan happea. Samalla sulasta

poistuu myös lähes kaikki pii (Si). Standardisoidut ruostumattomat teräkset

(stainless steel) sisältävät vähintään 10,5 % kromia ja alle 0,3 % hiiltä. Kromi

muodostaa teräksen pintaan kromioksidikalvon, joka suojaa terästä

hapettumiselta (ruostumiselta). Joihinkin teräslajeihin seostetaan lisäksi

molybdeenia (Mo), nikkeliä (Ni) ja typpeä (N), millä pyritään parantamaan

teräksen ruosteenkestävyyttä ja muita ominaisuuksia kuten muovattavuutta.

Seosaineet muuttavat teräksen kiderakennetta, joten teräksessä olevien ja sieltä

puuttuvien seosaineiden vaikutus teräksen ominaisuuksiin on erittäin suuri

(Outokumpu WWW). Seuraavaksi kuvattu valmistusprosessi pyrkiikin

tuottamaan rautalejeerinkiä, joka täyttää ruostumattomalle teräkselle asetetut

tiukat laatuvaatimukset. Asiakasyrityksen teräksenvalmistusprosessia kuvaava

vuokaavio on esitetty kuvassa 2.

10

2.4.2 SULATUS KROMIKONVERTTERISSA JA VALOKAARIUUNISSA

Valmistusprosessi alkaa ferrokromitehtaalta ja romuvarastosta. Ferrokromi-

tehdas toimittaa ferrokromia kromikonvertterille, jossa ferrokromista poltetaan

pois pii ja suuri osa hiilestä puhaltamalla sulaan happea. Uuniin lisätään

samalla kalkkia kuonanmuodostukseen. Hiilen ja piin poltto muodostaa

runsaasti lämpöä, mikä nostaa uunin lämpötilaa voimakkaasti, ja uunia

joudutaan jäähdyttämään kuivatetulla romulla. Tällöin lämpöenergia saadaan

hyödynnettyä romun sulatukseen. Jäähdytysromua lisätään noin 550 kg jokaista

ferrokromitonnia kohden, joten ferrokromitehtaalta tulevan sulan massa kasvaa

kromikonvertterissa noin 50 %. Samalla myös sulan kromipitoisuus laskee 53

%:sta 35 %:iin (Haapalinna ja Tolvanen 1998).

Kromikonvertterin lisäksi teräksen raaka-ainetta saadaan valokaariuunissa

sulatettavista teräsromuista. Romujen koostumusta ei kuitenkaan tarkaan

tunneta, vaan romut on varastolla karkeasti jaoteltu eri luokkiin. Pääasiallisen

jakoperusteen muodostaa romujen sisältämän teräksen laatu, erityisesti sen

ruosteen- ja haponkestävyys. Romut voidaan jaotella tästä edelleen kokonsa ja

muotonsa perusteella. Teräsromujen alkuainepitoisuuksista on tavallisesti

olemassa romujen toimittajan ilmoitus, mutta toisinaan romut saattavat sisältää

joitakin alkuaineita arviosta hyvinkin poikkeavan määrän. Romuista tehdään

analyysejä, mutta romuluokat ovat sen verran sisäisesti heterogeenisiä, että

FeCr-tehdas Romuvarasto

Kromikonvertteri Valokaariuuni

SulaAOD-panos

AOD-konvertteri

Senkkauuni

Jatkuvavalu

Katkaisu

Hionta

Jäähdytys

Kuva 2. Outokumpu Polaritin teräksenvalmistusprosessi.

11

yhtä, tarkkaa kemiallista analyysia romulajista ei voida tehdä.

Romut lastataan romuvarastolla koreihin panoslaskennan mukaisesti ja

kuljetetaan vaunulla uunihalliin. Täällä romut panostetaan valokaariuuniin.

Romujen sekaan lisätään arvioidun piimäärän suhteessa kalkkia ja happea.

Sulatus tapahtuu sitten sähkövoiman muodostaman valokaaren avulla.

Valokaariuunista saatavan sulan hiilipitoisuus on tyypillisesti 0,5 % - 1 %.

2.4.3 SIIRTOSENKKA, AOD-KONVERTTERI JA PROSESSIN MUUT OSAT

Romujen sulatuksen jälkeen kromikonvertterin ja valokaariuunin sulat

sekoitetaan sopivassa suhteessa siirtosenkkaan, jolla saatu sula kuljetetaan

sitten AOD-konvertteriin. AOD-menetelmällä päästään ruostumattomalle

teräkselle riittävän alhaisiin hiilipitoisuuksiin ilman, että kromipitoisuus laskee

merkittävästi. AOD-konvertterissä seostetaan vielä liian vähäisiksi jääneitä

alkuaineita sekä pyritään poistamaan sulasta epäpuhtauksia. AOD-

konvertterista sula viedään edelleen senkkauuniin, sieltä jatkuvaan valuun sekä

katkaisuun ja hiontaan. Terästä voidaan vielä jatkokäsitellä, esimerkiksi

muovittaa se.

Valmistusprosessin aikana sulan alkuainepitoisuuksista tehdään useita

mittauksia. Analyysejä tehdään ainakin kromikonvertterin, siirtosenkan ja

AOD-konvertterin sulista. Näitä tuloksia voidaan hyödyntää saman sulatuksen

aikana arvioitaessa seostamis- ja laimentamistarvetta sekä myöhemmin

estimoitaessa valokaariuuniin panostettujen romujen alkuainepitoisuuksia.

2.5 TERÄKSEN VALMISTUKSEEN LIITTYVÄT TEKIJÄT

2.5.1 KOOSTUMUSRAJAT JA SAKKOFUNKTIOT

Kun tiettyä teräslaatua ryhdytään valmistamaan, tarvitaan tuotettavan teräksen

spesifikaatiot, koostumusrajat. Ne asettavat ylä- ja alarajan teräslajin

sisältämille alkuainepitoisuuksille ja näin määräävät myös teräksen kemialliset

ominaisuudet. Koostumusrajat määrittelevät siis mistä metalliseoksesta on

kyse; onko se ruostumatonta terästä vai jotain muuta lejeerinkiä. Onkin aivan

ilmeistä, että teräslajin koostumusrajoilla on keskeinen rooli teräksenvalmistus-

prosessissa. Ne muodostavat koko prosessille viitekehyksen, jota seurataan

jatkuvasti sulatuksen alusta loppuun. Koostumusrajat ovat periaatteessa

kullekin teräslaadulle vakiot, mutta toisinaan teräksen tilannut asiakas haluaa

12

erikseen määrittää ne. Tällöin puhutaan asiakaskohtaisista koostumusrajoista.

Koostumusrajoja on kahta lajia: valmistusrajoja ja laadutusrajoja. Kummatkin

rajat muodostavat intervallin, jonka sisään lopullisen tuotteen

alkuainepitoisuuksien halutaan jäävän. Laadutusrajat ovat ne pitoisuudet,

joiden välissä alkuaineiden määrät luvataan asiakkaalle olevan. Laadutusrajat

ovat ehdottomat ja niiden ylittäminen tai alittaminen johtaa sulan

hylkäämiseen. Valmistusrajat ovat puolestaan laadutusrajoja tiukemmat, ja niitä

käytetään terästä valmistettaessa. Näin pyritään varmistamaan, että

satunnaisvaihtelusta huolimatta alkuainepitoisuudet todella jäävät

laadutusrajojen sisään.

Laadutus- ja valmistusrajat pätevät vain valmiille tuotteelle, mutta niistä

saadaan yksinkertaisilla +/- -prosenttiyksikkömuunnoksilla prosessipaikka-

kohtaiset koostumusrajat, joita sovelletaan määritettäessä sulien sallittuja

alkuainepitoisuuksia kyseisessä prosessipaikassa. Prosenttiyksikkömuunnokset

ovat ominaisia kullekin teräslaadulle sekä prosessipaikalle.

Koostumusrajoja mallinnetaan optimoinnissa sakkofunktioilla. Sakkofunktiot

kertovat, kuinka paljon alkuainepitoisuuksien poikkeamisesta johtuva

Tähtäyspiste Yläraja Ehdotonyläraja

AlarajaEhdotonalaraja

Sakko

Alkuaineenpitoisuus

Kuva 3. Sakkofunktio

13

lisäkäsittely nostaa teräksen valmistuskustannuksia. Esimerkki sakkofunktion

kuvaajasta on esitetty kuvassa 3.

2.5.2 RAAKA-AINEIDEN KÄYTTÖRAJOITUKSET JA SAATAVUUS

Teräslaaduille voidaan määritellä maksimi- ja minimikäyttörajoituksia, joita

sovelletaan optimoinnissa. Näin voidaan rajata raaka-aineita, joita

optimointialgoritmin käyttää kullekin teräslajille. Esimerkiksi valmistettaessa

erityisen puhdasta terästä voidaan vaihtelevan laatuisiksi todetut romulajit

jättää pois panostettavien raaka-aineiden listalta. Toisaalta tietyille, runsaasti

saatavissa oleville raaka-aineille voidaan määrätä vähimmäiskäyttömäärät.

Raaka-aineita on käytössä täsmälleen varastoon kirjattu määrä sillä

poikkeuksella, että tehtaalta tulevaa ferrokromia on saatavissa rajattomasti.

Toisinaan kuitenkin ferrokromitehtaalla on huoltoseisakkeja, jolloin

ferrokromia ei ole saatavissa. Tällöin sulan muodostukseen käytetään

pelkästään valokaariuunissa sulatettavia romuja, joihin kromi seostetaan

suoraan siilosta ferrokromierotteena. Raaka-aineille voidaan vielä määritellä

saapumisnopeudet (tonnia / päivä), jotka kuvaavat keskimääräistä nopeutta,

jolla raaka-ainetta saadaan varastoon. Saapumisnopeuksia voidaan hyödyntää

optimoitaessa pitkällä aikavälillä monta peräkkäistä sulatusta, jolloin ei voida

olettaa romujen varastomäärien pysyvän ajan suhteen vakiona. Monen

peräkkäisen sulatuksen yhtäaikaiseen optimointiin tutustutaan paremmin Jussi

Ikäheimon diplomityössä (1999).

2.6 JOHDATUS ESTIMOINTIIN JA OPTIMOINTIIN

Tämä kappale tekee katsauksen AMRO-projektissa käytettyihin optimointi- ja

estimointimenetelmiin. Niiden tarkempi kuvaus löytyy Jussi Ikäheimon

diplomityöstä (1999). AMRO-projektissa suunniteltava ohjelmisto pyrkii

löytämään mahdollisimman halvan valokaariuuniin panostettavan

romuyhdistelmän siten, että lopullisen sulan alkuainepitoisuudet jäävät

haluttuihin rajoihin riittävällä varmuudella. Tehtävä ratkeaisi helposti

lineaarisella ohjelmoinnilla (linear programming, LP), jos romujen

alkuainepitoisuudet tunnettaisiin tarkasti, mutta nyt näin ei kuitenkaan ole.

Varaston romujen alkuainepitoisuuksista on olemassa niiden toimittajan antama

ilmoitus, mutta periaatteessa romujen alkuainepitoisuudet vaihtelevat ennalta

tuntemattoman satunnaisjakauman mukaisesti. Optimointialgoritmilla onkin

14

kaksi vastakkaista tavoitetta: toisaalta löytää mahdollisimman halpa panostus

halutulle teräslaadulle, mutta toisaalta minimoida alkuainepitoisuuksien

varianssia, jotta halutun laatuista terästä saataisiin mahdollisimman varmasti.

AMRO:n optimoinnissa ja estimoinnissa tarkastellaan kolmea eripituista

aikajaksoa, jolle kullekin on suunniteltu omanlaisensa optimointimalli

(Lahdelma et al 1999). Ensimmäisen mallin muodostaa yhden sulatuksen

optimointi, jossa keskitytään prosessin yksityiskohtiin ja pyritään saamaan

mahdollisimman luotettavia tuloksia estimoinnissa. Toisekseen AMRO:ssa

käsitellään monen sulatuksen mallia, jossa saatavilla olevat raaka-aineet

pyritään jakamaan optimaalisesti monen sulatuksen kesken, mutta prosessin

yksityiskohdat joudutaan nyt jättämään vähemmälle huomiolle. Kolmannessa

optimointimallissa pyritään puolestaan optimoimaan romupanostuksia

sulatusten sijasta tuotteille. Tällöin voidaan hyödyntää dataa kaikista aiemmin

tehdyistä sulatuksista ja analyyseistä eikä varastorajoituksia ole.

AMRO:n optimointiprosessin kulku (Ikäheimo 1999) on esitetty kuvassa 4.

Hieman poikkeava kuvaus löytyy toisesta lähdeartikkelista (Lahdelma et al

1999), mutta käytännön erot jäävät pieniksi. Ensimmäisen vaiheen muodostaa

romujen alkuainepitoisuuksien jakaumien estimointi tai estimaattien tarkennus.

Jotta optimointialgoritmia voidaan soveltaa, on tunnettava ensin käytettävien

Panostuksenoptimointi

Prosessin malli(Ennustus)

Prosessin malli(Tarkennus)

Sulanominaisuuksien

ennustus

Todelliset sulanominaisuudet

Romujenpanostus

Mallinparametrit

EstimointiOptimointi

Kuva 4. Optimointi- ja estimointiprosessin kulku (mukailtu lähteestä Ikäheimo, 1999).

15

romujen alkuainepitoisuuksien tilastolliset jakaumat. Nämä eivät ole suoraan

tiedossa, vaan ne joudutaan estimoimaan aiempien sulatusten ja romuista

otettujen näytteiden perusteella. Lisäksi kun saadaan uutta tietoa, esimerkiksi

uuden sulatuksen analyyseja, tulee aiempia estimaatteja näiden valossa

tarkistaa. Estimointiin liittyy monia ongelmakohtia; esimerkiksi panostettujen

romujen alkuaineet eivät sulatuksen yhteydessä siirry suoraan uunista saatavaan

sulaan, vaan osa romujen materiaalista kuonaantuu uunin seinämiin. Lisäksi

ulos tulevan sulan alkuainepitoisuuksiin vaikuttavat sulatuksen aikana eri

yhdisteiden välillä tapahtuvat kemialliset reaktiot. Nämä riippuvat osin romujen

sisältämistä yhdisteistä, ja koska romujen koostumus tunnetaan

parhaimmillaankin vain kohtalaisesti, esiintyy uunin alkuainesaannossa

satunnaisvaihtelua. Kuten romujen alkuainepitoisuudetkin, saannotkin

joudutaan estimoimaan aiemmin tehdyistä sulatuksista. Ongelmaksi muodostuu

se, että yksittäistä sulatusta tarkasteltaessa on mahdotonta tietää, johtuuko

alkuainepitoisuuden poikkeama uunin saannon vai romujen

alkuainepitoisuuksien satunnaisvaihtelusta. Tämän ratkaisuun käytetään ns.

maximum likelihood –menetelmää, eli monen sulatuksen perusteella valitaan

alkuainepitoisuuksille ja saannoille ne jakaumat, joilla sulista havaitut

alkuainepitoisuudet saadaan todennäköisimmin. Jos satunnaismuuttujat

approksimoidaan normaalijakautuneiksi, voidaan soveltaa pienimmän

neliösumman menetelmää (PNS). Joskus, tavallisesti sovitettaessa suora

havaintoaineistoon, PNS-menetelmää kutsutaan lineaariseksi regressioksi.

PNS:n sellaista versiota, joka mahdollistaa estimaattien päivittämisen uuden

tiedon ilmaantuessa, kutsutaan rekursiiviseksi pienimmän neliösumman

menetelmäksi (RPNS). AMRO-projektissa käytetäänkin RPNS-menetelmää.

Estimoinnissa tulee lisäksi pohtia, kuinka aiempien sulatusten ja raaka-aineiden

näytteiden data yhdistään perustellusti. Ei nimittäin ole selvää, miten näytteitä

ja sulatuksien tuloksia painotetaan keskenään määrättäessä optimoinnissa

käytettävien alkuainepitoisuusestimaattien jakaumia.

Prosessin toisessa vaiheessa valokaariuunin panostus optimoidaan saatujen

estimaattien avulla. Sulatuksen jälkeen saadaan vielä sulien analyysit, joiden

perusteella voidaan päätellä, kuinka hyvin romujen alkuainepitoisuuksien

estimointi oli onnistunut. Uusien analyysien tulokset syötetään

estimointimoduulille, jolloin optimointi- ja estimointiprosessi alkaa alusta

estimaattien tarkennuksella. Optimointi ja estimointi onkin rekursiivinen,

itseään korjaava prosessi.

16

3. PROJEKTIN VAIHEET JA OHJELMISTON ARKKITEHTUURI

3.1 OUTOKUMPU POLARIT OY:N AMRO-PROJEKTIN HISTORIAA

Alun perin kaksivuotiseksi suunniteltu AMRO-projekti aloitettiin keväällä

1997. Ensimmäistä, Kuusakoski Oy:lle tehtyä AMRO-projektia, seurasi

keväällä 1998 käynnistetty hanke, jonka tarkoituksena oli optimoida

Outokumpu Polarit Oy:n Tornion tehtaiden valokaariuunin panostus.

Loppukeväästä syntyi aiheesta yksi harjoitustyö (Haapalinna ja Tolvanen 1998)

sekä Jukka Rannan seminaariraportti. Syksyllä 1998 aloitettiin hankkeeseen

tarvittavan ohjelmiston suunnittelu, ja alkukeväästä 1999 siihen liittyvästä

tietokannasta tehtiin tiedonhallintajärjestelmät-kurssin harjoitustyö

(Gustafsson, Gustafsson ja Saarinen 1999). Koska projekti venyi, sille

myönnettiin lisäaikaa vuoden 1999 loppuun. Kevään 1999 alusta projektiin tuli

mukaan Jussi Ikäheimo, joka toteutti diplomityönään valokaariuunin

optimointi- ja estimointialgoritmit.

3.2 PROJEKTIN VAIHEISTUS

Outokumpu Polarit Oy:lle tehtävä ohjelmisto päätettiin toteuttaa kahdessa

vaiheessa. Ensiksi toteutettiin ns. offline-versio, joka olisi yhdessä PC-koneessa

toimiva optimointiohjelmisto. Tästä siirryttäisiin projektin toisessa vaiheessa

online-versioon, joka olisi Outokummun tietojärjestelmiin integroituva

hajautettu ohjelmisto. Tällaiseen vaiheistukseen päädyttiin, koska optimointi- ja

estimointialgoritmien kehittämistä ei haluttu vaikeuttaa asiakasyrityksen tieto-

järjestelmistä aiheutuvilla ongelmilla. Nämä on suunnitelman mukaan tarkoitus

ratkaista vasta siirryttäessä online-versioon. Offline-versio on kuitenkin

toteutettu siten, että siirtyminen Outokummun tietojärjestelmiin tapahtuu

mahdollisimman helposti.

3.3 OUTOKUMPU POLARIT OY:N TIETOJÄRJESTELMÄT

Outokumpu Polarit Oy:llä on kolme AMRO-projektille keskeistä, UNIX-

ympäristössä toimivaa tietojärjestelmää: Informix-tietokanta, sulaton

tietojärjestelmä SUTI sekä keskitetty ohjelmistohälytysten, käyttöhäiriöiden ja

sovellusnotifikaatioiden hallintajärjestelmä ROPI-II. Lisäksi Outokumpu

Polarit Oy:llä on Windows NT-lähiverkko, joka on kytketty UNIX-

järjestelmiin.

17

SUTIin kuuluu osana C-kieliset kirjastot, joilla sovellukset voivat ottaa

yhteyden Informix-tietokantaan. Näitä kirjastoja on tarkoitus käyttää online-

version toteutuksessa. ROPI-II:een kuuluu notifikaatiopalvelu, joka hoitaa

tietoliikennettä tietokannan ja sovellusten välillä. Lisää tietoa Outokumpu

Polarit Oy:n tietojärjestelmistä saa yhtiön ATK-osastolta.

3.4 ARKKITEHTUURI

3.4.1 PERIAATTEET

Online-version arkkitehtuuri on hajautettu, eli ohjelmiston eri osat ovat

itsenäisiä ohjelmia. Tällöin yksittäisiä osia voidaan muuttaa koskematta

muuhun osaa ohjelmistoa (olettaen, että rajapintoja ei muuteta). Teoriassa myös

muut ohjelmistot voivat hyödyntää hajautettuja laskentarutiineja, mutta

käytännössä uudelleenkäyttö on kuitenkin vaikeaa, koska ohjelmiston laskenta-

rutiinit ovat hyvin ongelmaspesifisiä. Ohjelmistojen hajauttaminen on

Outokummun virallinen politiikka.

Offline-version arkkitehtuuri on tarkoitus tehdä mahdollisimman paljon online-

version kaltaiseksi, jotta siirtyminen projektin toiseen vaiheeseen tapahtuu

kitkattomasti. Online-version arkkitehtuuria ei kuitenkaan voida toteuttaa

kokonaisuudessaan offline-versiossa, sillä online-versio on monen käyttäjän

järjestelmä, kun taas offline-versiossa on vain yksi käyttäjä. Monen käyttäjän

järjestelmän kehittäminen vaatii merkittävästi enemmän työtä (mm. lukitukset)

sekä testausta usean käyttäjän kanssa samaan aikaan, joten sellaisen

ohjelmointiin ei offline-vaiheessa katsottu olevan perusteita.

3.4.2 YLEISKUVAUS

Ohjelmisto jakaantuu neljään erilliseen osaan: tietokantaan, tietokannan

käyttöliittymään sekä optimointi- ja estimointimoduuliin ja sen

käyttöliittymään. Jaon taustalla on ohjelmiston tuleva hajautus Outokummun

järjestelmiin. Online-versiossa optimointi- ja estimointimoduuli toimii

erillisenä laskentamoduulina UNIX-ympäristössä. Tietokantana tulee

toimimaan Outokummun Informix-tietokanta, joka myös toimii UNIXissa.

Molemmat käyttöliittymät toimivat Windows NT-koneissa, ja keskustelevat

ohjelmiston muiden osien kanssa Outokummun notifikaatiopalvelun kautta.

18

Tietokanta ja sen käyttöliittymä on suunniteltu Model-View-Controller-

arkkitehtuurin (MVC) mukaisesti (ks. kuva 5). MVC:ssä on yksi tietokanta,

mutta käyttöliittymiä voi olla useampia. Käyttöliittymissä voi olla avoinna

useita näkymiä (ks. kappale 5) tietokannan tauluihin, jotka päivittyvät vain

tietokannan käskystä. Kun jostain käyttöliittymästä muutetaan jotain

tietokannan taulua, lähettää käyttöliittymä käskyn tietokannalle muuttaa

itseään. Käyttöliittymä toimii tällöin komentojen lähettäjänä (controller).

Näihin komentoihin tietokanta vastaa (mikäli toiminto onnistui) lähettämällä

kaikille käyttöliittymille käskyn päivittää muutetettuun tauluun auki olevia

näkymiä. Näin varmistetaan, että käyttöliittymien näkyvät päivittyvät aina, kun

tietokantaa muutetaan. MVC-arkkitehtuurin päädyttiin, koska se tuntui

luonnolliselta ratkaisulta toteuttaa monen käyttäjän tietokanta. Offline-versiossa

MVC-arkkitehtuuri on kuitenkin toteutettu vain osin, koska usean käyttäjän

ongelmia ei esiinny eikä ohjelmistoa olisi voitu testata niiden osalta.

Offline-version eri osien väliset suhteet näkyvät kuvassa 6. Online-versiossa

tämä perusarkkitehtuuri pysyy lähes muuttumattomana. Kappaleessa 6

kuvataan, mitä muutoksia arkkitehtuuriin joudutaan tekemään, kun siirrytään

online-versioon.

Ohjelmisto rakentuu laskentarutiinit sisältävän optimointi- ja estimointi-

moduulin ympärille. Tietokantaan tallennetaan optimointin ja estimoinnin

tarvitsemat tiedot, kuten sulatukset, tuotteet ja raaka-aineet. Tietokannan

käyttöliittymällä voidaan lukea ja muokata tietokannan sisältämiä tietoja, ja se

on tarkoitettu lähinnä tietokannan rakenteeseen perehtyneiden henkilöiden

Näkymä(View)

Komentojenlähettäjät

(Controller)

Tietokanta(Model)

Kuva 5. Model-View-Controller-arkkitehtuuri.

19

käyttöön. Optimointi- ja estimointimoduulin käyttöliittymällä nimensä

mukaisesti käytetään optimointi- ja estimointimoduulia, eli sitä käytetään

sulatuksien panostamisen optimoimiseen. Sen kautta tietokannan tietoja, kuten

sulatuksia, ei voi muuttaa.

Koko ohjelmisto, tietokantaa lukuun ottamatta, on ohjelmoitu Borland C++

Builder 3:lla, joka valittiin yhdessä Outokumpu Polarit Oy:n kanssa

käytettäväksi tämän projektin toteuttamiseen. Tähän ratkaisuun päädyttiin,

koska Borland C++ Builder 3 on Outokummun virallinen, hyväksi havaittu

Windows NT –sovelluksien kehitysympäristö.

3.4.3 TIETOKANTA

Tietokanta tarjoaa alustan optimointi- ja estimointialgoritmien tarvitsemalle

tiedolle. AMRO-projektin offline-versioon suunniteltiin SQL2-kielellä oma

tietokanta, joka lopulta toteutettiin Paradox 7-tietokannalla. SQL-

määrittelyissä kiinnitettiin erityistä huomiota tietokannan käyttöalueen

laajennettavuuteen, redundanssin välttämiseen ja joustavuuteen. Paradox-

toteutus ei kuitenkaan tukenut suunniteltuja ominaisuuksia kaikilta osin, mutta

pääasiassa toteutuksesta tuli ennakoidunlainen. Online-versiossa ei offline-

tietokantaa käytetä lainkaan, vaan ohjelmiston muut osat integroidaan

käyttämään Outokummun omia tietojärjestelmiä, joissa on käytössä Informix-

tietokanta ja oma ROPI-II-notifikaatiopalvelu. Kappale 4 käsittelee offline-

tietokantaa ja kappaleessa 6 keskitytään analysoimaan online-integroinnin

Tietokanta(lokaali)

Tietokantarajapinta

Tietokannankäyttöliittymä

Optimointi- jaestimointimoduuli

Opt./est.-moduulinkäyttöliittymä

Kuva 6. Offline-version arkkitehtuuri.

20

tuomia haasteita.

3.4.4 TIETOKANNAN KÄYTTÖLIITTYMÄ

Tietokannan käyttöliittymän suunnittelussa kiinnitettiin erityistä huomiota

käyttäjäystävällisyyteen ja monipuolisuuteen. Käyttöliittymä toimii yhdessä

pääikkunassa, jonka sisälle avataan omiin ali-ikkunoihinsa näkymiä (view)

tietokannan eri tauluihin. Näkymät esittävät sen osan tietokannan taulun

sisällöstä, joka täyttää näkymän hakuehdon (filter). Näkymien kautta

tietokannan lukeminen ja päivittäminen käy helposti. Tällaista pää- ja ali-

ikkunaratkaisua kutsutaan Multi-Document Interface- eli MDI-ratkaisuksi.

Tietokannan käyttöliittymä on kuvattu tarkemmin kappaleessa 5.

3.4.5 OPTIMOINTI- JA ESTIMOINTIMODUULI

Optimointi- ja estimointimoduuli suorittaa tarvittavat laskutoimitukset

valokaariuunin panostuksen optimoimiseksi, ja se muodostaa AMRO:n ytimen.

Moduuliin kuuluu laskentaosan lisäksi käyttöliittymä algoritmien käsittelyyn ja

tulosten esittämiseen. Tietokannan ja laskentaosan välisessä keskustussa

käytetään koko projektin yhteistä tietokantarajapintaa, millä saadaan

vähennettyä osien yhteiskoodimäärää merkittävästi. Optimointi- ja

estimointimoduuli kuuluu Jussi Ikäheimon diplomityön piiriin, eikä sitä

tarkastella tässä lähemmin.

3.4.6 HUOMIOITA

Jos moduuleista on käytössä usempia versioita, saattaa olla, että kaikki eri

versiot eivät toimi keskenään. Kehitystyössä täytyy siis varmistua siitä, että

versiot ovat yhteensopivia. Moduulien testaaminen on työlästä, jos joudutaan

käymään läpi kaikki käytössä olevat versiokombinaatiot (integrointitestaus,

katso Haikala ja Märijärvi 1998). Esimerkiksi, jos neljästä eri moduulista on

kustakin käytössä kolme eri versiota, joudutaan testaamaan 43=64 eri

versiokombinaatiota. Jos ohjelmiston eri osat ovat käytössä vain yhdessä

paikassa, ei tällaisia ongelmia esiinny. Ne voidaan välttää myös päivittämällä

kaikki osat kerralla johonkin testattuun kokoonpanoon.

21

3.5 PROJEKTIN ANALYYSI

3.5.1 TAVOITTEEN SAAVUTTAMINEN

Projektin tavoitteena on vähentää teräksen valmistuksen raaka-ainekuluja

0.1%:lla. Käytännössä näin pienen muutoksen havaitseminen on kuitenkin

lähes mahdotonta, sillä raaka-ainekuluihin liittyy panostuksesta riippumatonta

epävarmuutta kuten inhimillisiä tekijöitä. Näin ollen joudutaan käyttämään

suhteettoman suuria otoksia, jotta pieni liukuminen raaka-ainekustannusten

odotusarvossa voitaisiin havaita. Raaka-ainekustannusten todellisen säästön

arvioimiseksi täytyykin käyttää tilastollisia menetelmiä, mutta pienellä

otoskoolla (< 100 sulatusta) nämäkin tuottavat liian epätarkan tuloksen.

Teoriassa optimoinnin teho voidaan kuitenkin selvittää esimerkiksi Monte

Carlo –simuloinnilla, kun verrataan aikaisempia sulatuksia ja optimoinnin

antamia panostusestimaatteja (Lahdelma et al 1999).

3.5.2 RISKIT

Projekti on kestänyt jo vuosia, ja henkilöstön vaihtuuvuus on ollut suurta.

Syynä tähän on ollut se, että suuri osa projektista on toteutettu Teknillisen

Korkeakoulun oppilaiden harjoitus-, erikois- ja diplomitöinä. Kun työ on

valmistunut, oppilaat ovat yleensä lähteneet projektista, jonka jälkeen on

jouduttu rekrytoimaan uusia työntekijöitä, jotka ovat joutuneet tutustumaan

projektiin alusta alkaen. Vaihtuvuuden takia pätevästä työvoimasta saattaa tulla

pulaa.

Toisen vaiheen integrointityö vaatii täysipäiväistä työskentelyä Outokummun

Tornion tehtailla. Tähän työhön saattaa olla vaikea hankkia opiskelijoita, joiden

tarvitsee olla lukukausien aikana opiskelupaikkakunnallaan. Näin ollen toisen

vaiheen integrointityö joudutaan mitä ilmeisimmin suorittamaan jollain muulla

työvoimalla. Uuden osapuolen tuominen mukaan prosessiin ei välttämättä

onnistu, koska projekti vaatii monen alan asiantuntemusta. Tästä syystä

integrointivaiheen aloittaminen ja läpivieminen vaatii tarkkaa suunnitelua

projektin johtoryhmältä. Yhteistyö projektin ensimmäisen vaiheen toteuttajien

kanssa on todennäköisesti välttämätöntä.

22

4. TIETOKANTA

4.1 JOHDATUS TIETOKANTOIHIN

Tietokanta (database) on kokoelma tietoa, jota käsittelee tietokannan-

hallintajärjestelmä (database management system, DBMS). Ensimmäiset

tietokannat luotiin pankkien ja lentoyhtiöiden tarpeisiin, mutta ne levisivät

nopeasti myös teollisuuslaitosten käyttöön. Koska tietokannat veivät

tyypillisesti useita gigatavuja levytilaa, vielä ennen 1990-lukua tietokannat

sijoitettiin lähes poikkeuksetta suuriin keskustietokoneisiin (remote database).

Myös Outokumpu Polaritilla tietokannat sijaitsevat keskustietokoneiden

kovalevyillä. Nykyään kuitenkin tietotekniikan ja kovalevyjen koon nopean

kehityksen ansiosta PC-koneissa voidaan käyttää paikallisia tietokantoja (local

database), jollaisen yhteyteen myös AMRO:n offline-versio on ohjelmoitu.

Tietokantaan mallinnettavia ongelmakentän käsitteitä kuvataan tietojen-

käsittelyopissa usein E/R-kaaviolla (entity-relationship diagram). E/R-kaavio

on graafinen tapa esittää erilaiset käsitteet eli yksilöjoukot (entity set),

käsitteiden ominaisuudet eli attribuutit (attributes) ja käsitteiden väliset suhteet

(relationship) laatikkoina, soikioina ja salmiakkeina. E/R-kaavioiden

termistöön palataan tarkemmin kappaleessa 4.2. Todelliset tietokannat eivät

kuitenkaan perustu E/R-kaavioihin vaan huomattavasti suppeampaan ja

yksinkertaisempaan relaatiomalliin (relational model), joka kuvaa, miten

käsitteet on todellisuudessa talletettu tietokantaan. Relaatiomalliin perustuva

tietokanta jakaa käsitteet relaatioihin (relation), jotka jakautuvat attribuutteihin

kuten E/R-kaavion yksilöjoukotkin. Relaatiomalliin läheisesti liittyvässä SQL-

kielessä relaatioita kutsutaan tauluiksi (table) ja attribuutteja kentiksi (field).

Varsinaisia suhteita relaatiomallissa ei ole, mutta ne voidaan toteuttaa tauluilla

ja viitekentillä (reference). Relaatiomalliin perustuvan tietokannan

implementaatio on yksikäsitteinen ja helppo toteuttaa, ja suurin osa

markkinoilla olevista tietokannoista käyttääkin relaatiomallia. Poikkeuksen

muodostavat lähinnä uudet, oliopohjaiset tietokannat. E/R-kaaviota käytetään

kuitenkin tavallisesti havainnollistamaan tietokannan rakennetta.

Tietokantoja käsitellään relaatiomalliin perustuvalla, jo standardiksi

muodostuneella SQL-kielellä (structured query language). SQL:stä on

olemassa kuitenkin eri valmistajien laajennuksia, mutta ne kaikki pohjautuvat

samaan SQL-standardiin. Laajennusten myötä perus-SQL:stä on standardoitu

23

SQL2-kieli, jota suurin osa nykyisistä tietokannoista ainakin teoriassa tukee.

Viimeisin tulokas SQL-perheeseen on SQL3, joka uusien innovaatioiden myötä

lisää standardiin mm. laukaisimet (triggers). Monet kaupalliset tietokannat

ovatkin lähempänä SQL3:sta kuin SQL2-standardia. Lisää tietoa tietokannoista

löytyy esimerkiksi kirjasta A First Course in Database Systems (Ullman ja

Widom 1997).

4.2 TIETOKANTOIHIN LIITTYVÄT KÄSITTEET

Tietokantatermistö on hyvin kirjavaa ja varsinkin suomenkielinen sanasto on

vakiintumatonta. Edellinen kappale antoi jo katsauksen tiedonhallinta-

järjestelmissä vallitsevaan moninaiseen termistöön, joka on syytä nyt käydä

läpi tarkemmin. E/R-kaavion ja relaatiomallin termien ero johtuu suurelta osin

siitä, että E/R-kaavio on käsitetason malli, joka pyrkii kuvaamaan

ongelmakentän käsitteitä ja niiden välisiä yhtyksiä. Relaatiomalli on puolestaan

tauluihin perustuva implementaatiotason malli, joka kertoo, miten E/R-kaavion

käsitteet ovat todellisuudessa talletettu tietokantaan. Seuraavaksi pyritäänkin

antamaan myös kuva siitä, kuinka eri mallinnustapojen käsitteet liittyvät

toisiinsa.

Tietokanta (database) on kokoelma tietoa. Tietokanta koostuu joukosta tauluja.

Taulu (table) on joukko yhden tyyppisiä tietoja tietokannassa. Taulu kuvaa

tavallisesti jotain mallinnettavaa käsitettä, esimerkiksi terästehtaan sulia.

Relaatiomallissa tauluja kutsutaan relaatioiksi (relation), ja E/R-kaavioiden

yhteydessä puhutaan puolestaan yksilöjoukoista (entity set). Käsitteellinen ero

taulun ja yksilöjoukon välillä on pieni. Yksilöjoukot ovat tavallaan varsinaisia

tietokantaan talletettavia käsitteitä, joita vastaa tietokannassa aina oma taulu.

Tauluja voi kuitenkin joutua luomaan yksilöjoukkojen lisäksi mm. E/R-kaavion

monesta-moneen suhteille, joten taulu on yksilöjoukkoa hieman yleisempi

kokonaisuus. Taulu jakaantuu kenttiin sen mukaan, mitä tietoja sen käsite

sisältää. Sulataulussa kenttiä olisivat ainakin sulan koodi ja massa.

Kenttä (field) sisältää taulussa yhtä, määrätyn sisältöistä tietoa, esimerkiksi

sulien massoja. Sekä E/R-kaavioissa että relaatiomallissa kenttiä kutsutaan

attribuuteiksi. Kenttä voi olla tietotyypiltään ainakin merkkijono, kokonaisluku

tai liukuluku.

24

Tietotyyppi (data type) määrittelee toteutustasolla, minkä tyyppistä (ei niinkään

minkä sisältöistä) tietoa kenttä sisältää. SQL-standardit sisätävät ainakin

seuraavat tietotyypit: tarkalleen n:n pituinen merkkijono CHAR(n), korkeintaan

n:n pituinen merkkijono VARCHAR(n), tarkalleen n:n pituinen bittijono

BIT(n), korkeintaan n:n pituinen bittijono BIT VARYING(n), kokonaisluku

INTEGER (tai INT), liukuluku FLOAT (tai REAL), päivämäärä DATE ja

kellonaika TIME.

Tietue (tuple) on yksi tauluun tallennettu tietorivi, joka käsittää arvon kullekin

taulun kentälle. Toisinaan tietueita kutsutaan monikoiksi ja E/R-kaavioissa

yksilöksi (entity).

Taulun kentät voivat olla yksilöiviä (unique). Tällöin taulun kahdella tietueella

ei voi olla kentässä samaa arvoa, vaan sellaiset lisäykset ja muutokset, joiden

tuloksena kentään tulisi kaksi samaa arvoa, estetään. Kentät voivat olla myös

yhdessä yksilöiviä. Tällöin taulussa ei saa esiintyä samaa kenttien arvojen

yhdistelmää useasti. Kentät ovat usein pakollisia (mandatory, NOT NULL),

jolloin kenttiin on pakko syöttää jokin arvo. Pakollisia yksilöiviä kenttiä

voidaan käyttää tietueen yksikäsitteiseen tunnistamiseen taulusta.

Taulun avain (key) on se pakollinen yksilöivä kenttä (tai joukko kenttiä), jonka

perusteella tietueet tunnistetaan taulusta. Avain voi myös olla joukko pakollisia

kenttiä, joiden yhdistelmä on yksilöivä. Jokaiselle taululle on määriteltävä yksi

avain.

Viite (reference) on kenttä (tai kenttäjoukko), joka voi saada arvoikseen vain

toisen taulun avaimen arvoja. Mikäli kohdetaulun avain on joukko useita

kenttiä, käsittää myös viite yhtä monta kenttää. Viitteet voivat lisäksi olla joko

yksilöiviä (single value constraint) tai viite-eheitä (referential integrity).

Yksilöivä viite voi joko osoittaa yhteen kohdetaulun tietueeseen tai olla

viittaamatta yhteenkään, jolloin kentän arvo on NULL. Viite-eheä viite

puolestaan osoittaa aina täsmälleen yhteen kohdetaulun tietueseen. Viitteet ovat

relaatiomallin käsitteitä, ja niitä käytetään tavallisesti toteuttamaan E/R-kaavion

suhteita.

Suhde (relationship) on yhteys kahden yksilöjoukon (ks. taulu) välillä.

Tällainen voisi olla esimerkiksi viittaus sulatuksesta teräslajiin. Suhteella

voitaisiin tällöin määritellä, mitä teräslajia (toisen taulun tietueita) sulatuksessa

25

valmistetaan. Suhteet voidaan toteutaa tietokannoissa monella tavalla.

Systemaattisin tapa on luoda kaikille suhteille omat taulunsa, joista on viitteet

suhteeseen liittyviin tauluihin. Osa näistä suhdetauluista (tarkkaan ottaen kaikki

attribuutittomat monesta-yhteen suhteet) voidaan kuitenkin redusoida yhdeksi

viitekentäksi monesta-pään tauluun. Suhteet voidaan luokitella kolmeen eri

ryhmään niiden moninaisuuden (multiplicity) perusteella: yhdestä-yhteen,

monesta-yhteen ja monesta-moneen. Moninaisuus määrittelee, kuinka moneen

kohdetaulun tietueeseen taulun yhdestä tietueesta voi olla viittaus ja

päinvastoin.

4.3 E/R-KAAVION PERUSTEET

Kuvassa 7 on esitetty E/R-kaavion tavallisimmat symbolit merkityksineen.

Laatikot kuvaavat ongelmakentän peruskäsitteitä, yksilöjoukkoja.

Yksilöjoukkon attribuutit esitetään puolestaan soikioina laatikon vieressä.

Alleviivatut attribuutit osoittavat, mitkä kentät muodostavat kyseistä

yksilöjoukkoa vastaavan taulun avaimet. Suhteita kuvataan E/R-kaaviossa

salmiakkikuvioilla, jotka yhdistävät ainakin kaksi yksilöjoukkoa toisiinsa. E/R-

kaaviossa voi yksilöjoukkojen lisäksi myös suhteilla olla attribuutteja. Kuten

yksilöjoukkojenkin attribuutit suhteiden attribuutit kuvataan E/R-kaaviossa

(Vahva) Yksilöjoukko

Heikko yksilöjoukko

Heikkosuhde

Attribuutti Avain

Suhde

Attribuutti

Viite-eheys

Yksilöiväarvovaatimus

Kuva 7. E/R-kaavion merkinnät.

26

salmiakkikuvioon yhdistetyillä soikioilla. Suhteilla ei kuitenkaan voi olla

avainattribuutteja; se on taulujen erityispiirre.

Jotkut E/R-kaavion yksilöjoukoista ovat ns. heikkoja yksilöjoukkoja, jotka

merkitään kaavioon kaksinkertaisilla viivoilla. Heikkoon yksilöjoukkoon liittyy

aina vähintään yksi heikko suhde, joka on osoitettu kaksinkertaisella

salmiakilla. Heikko suhde on suhde, joka on samalla yksilöjoukon avain tai sen

osa. AMRO:n E/R-kaaviossa on useita heikkoja yksilöjoukkoja. Tällainen on

esimerkiksi “Raaka-aineista otetut näytteet” -taulu. Kyseisen yksilöjoukon

avain muodostuu attribuutista (koodi) ja suhteesta raaka-ainelajeihin.

Ainoastaan näiden kenttien arvojen yhdistelmä on yksilöivä ja siispä eri raaka-

ainelajeista otetuilla näytteillä voi olla samat koodit. Heikkoa yksilöjoukkoa

ajatellaankin usein hierarkkiana: heikko yksilöjoukko on hierarkkiassa sen

yksilöjoukon alla, johon heikko suhde viittaa. AMRO:n E/R-kaaviosta löytyy

myös kolmitasoinen hierarkkia: sulatukseen kuuluu monia sulia ja suliin monia

näytteitä.

Suhteiden yksilöivyys on osoitettu E/R-kaaviossa nuolilla. Täytetty nuoli (¦ )

kuvaa, että suhteen toinen pää on viite-eheä (täsmälleen yksi). Tavallinen nuoli

(← ) osoittaa puolestaan yksilöivää arvovaatimusta (0 tai 1). Nuoleton viiva

kuvaa suhteen monesta-päätä.

4.4 JOHDATUS AMRO:N TIETOKANTAAN, SQL:ÄÄN JA TIETOKANNAN OMINAISUUKSIIN

AMRO:n offline-version tietokannan E/R-kaavio on esitetty liitteessä 1.

Vaatimusmäärittelyn sekä optimointi- ja estimointiosan implementaatio-

vaatimusten perusteella tietokantaan on luotu 25 taulua. Taulujen formaaliin

määrittelyyn (liite 2) on käytetty SQL2-kieltä, jota kuitenkaan offline-version

Borland Database Engine (BDE) ei tue kaikilta osin. Niinpä esitetty

implementaatio on tehty silmällä pitäen vaativampia tietokantoja, erityisesti

Outokummun Informixia. Taulut on kuvattu tarkemmin kappaleessa 4.5 ja

niiden toteutukseen BDE:llä tutustutaan kappaleessa 4.6.

4.4.1 E/R-KAAVIOSTA SQL:ÄÄN

Tietokannan taulut on E/R-kaaviossa numeroitu (nollasta alkaen)

yksilöjoukkojen ja suhteiden viereen. Yllämainittun periaatteen mukaisesti

attribuutittomat monesta-yhteen suhteet on toteutettu yhdellä kentällä monesta-

27

puolen taulussa. Tällaisia suhteita ovat kaikki heikot suhteet sekä muutama

muu suhde. Suurimmalle osalle E/R-kaavion suhteista luodaan kuitenkin omat

taulunsa. Taulut ja näiden kentät nimettiin tietokantaan englanniksi päinvastoin

kuin E/R-kaavioon, jossa käytettiin suomea. Perusteena ajateltiin, että on

luontevampaa käyttää SQL:ssä sen alkuperäiskieltä, jolloin mm.

ääkkösongelmat, jotka kohdataan skandinaavisten kielten kanssa, eivät vaikeuta

tietokannan tekoa. Sen sijaan E/R-kaavion ensisijainen vaatimus on sen

havainnollisuus ja tältä osin turhien kielimuurien pystyttäminen nähtiin

tarpeelliseksi välttää. Jotta taulujen ja kenttien yhteydet englanninkielisen

tietokannan ja suomenkielisen E/R-kaavion välillä tulisivat selviksi, liitteessä 3

on esitetty tietokannan taulut ja niitä vastaavat yksilöjoukot attribuutteineen.

Kentät on esitetty siinä järjestyksessä kuin ne esiintyvät tietokannan

taulumäärittelyissä.

Tietokannan taulut luova SQL-skripti on liitteessä 2. Tämä SQL-ohjelma

määrittelee viime kädessä miten todellinen tietokanta toimii, mutta sen pitäisi

olla täysin yhteneväinen E/R-kaavion kanssa. Taulujen SQL-skriptistä voidaan

todeta pari asiaa. SQL on muutoin hyvin selkeää, mutta viitteiden määrittelyyn

tulee kiinnittää huomiota. Yhden kentän viitteet luodaan SQL-kielellä

avainsanalla REFERENCES. Mikäli viite käsittää useita kenttiä, tulee käyttää

edellisen sijasta FOREIGN KEY (… ) REFERECES (… ) –rakennetta

taulunmäärittelyn lopussa. Taulujen avaimet määritellään sanoilla PRIMARY

KEY joko heti avainkentän jälkeen tai sitten taulunmäärittelyn lopussa, jolloin

voidaan määritellä suluilla myös avainkenttäryhmiä.

4.4.2 PÄIVITYS- JA POISTOPOLITIIKAT SEKÄ OIKEELLISUUSTARKISTUKSET

Viite-eheyksien hallintaan määritellään tietokannoissa usein päivitys- ja

poistopolitiikat (update / deletion policy). Perusajatuksena viite-eheyksissä on,

että riippumatta tietokantaan tehtävistä lisäyksistä, poistoista ja muutoksista

viite-eheydet säilyvät aina eikä olemattomiin tietueisiin viittaavia viitteitä pääse

syntymään. Päivitys- ja poistopolitiikat kertovat tietokannan hallinta-

järjestelmälle, kuinka jonkun tietueen avainkenttää muutettaessa (tai tietue

poistettaessa) kyseiseen tietueeseen viittaavat tietueet päivitetään. Päivitys- ja

poistopolitiikkoja ei ole kuitenkaan niiden pituuden tähden kirjoitettu liitteen 2

SQL-skriptiin, vaan ne lisätään, jos Outokummun Informix-tietokanta tukee

niitä.

28

Viitteitähän oli kahta lajia: yksilöiviä ja viite-eheitä, joista viite-eheys oli

rajoittavampi. Viite-eheille viitteille voidaan määritellä kaksi poistopolitiikkaa:

estopolitiikka (default policy) ja ketjupolitiikka (cascade policy). Estopolitiikka

estää tietueen poiston niin kauan, kun siihen on olemassa yksikin viittaus.

Ketjupolitiikka puolestaan poistaa myös kaikki poistettavaan tietueeseen

viittaavat tietueet. Monen tason ketjupolitiikalla saadaankin helposti aikaiseksi

suurten tietomäärien tuhoutuminen, kun yksi ylimmän tason tietue poistetaan.

Esimerkiksi tällöin AMRO:n tietokannassa tuotteen poistaminen tuhoaisi

kaikki siitä tehdyt sulatukset, mikä puolestaan poistaisi kaikki näiden sulat,

niistä tehdyt analyysit ja niille lasketut tavoitepitoisuudet. Tästä syystä

AMRO:ssa käytetäänkin yksilöjoukkojen välisten suhteiden viitteissä

estopolitiikkaa. Sen sijaan suhdetaulujen viitteissä poistopolitiikkana on

ketjupolitiikka. Tämän perusteena on se, että suhteista ei ole

ketjuuntumismahdollisuuksia pidemmälle ja suhteiden attribuuttien arvot ovat

merkityksettömiä ilman niiden viitetietueita. Attribuutittomat suhteet pitää

luonnollisestikin poistaa, kun niihin liittyvä tietue poistetaan. Yksilöiville

suhteille voidaan määritellä vielä lisäksi nolla-arvopolitiikka (set-null policy),

joka poiston tapahtuessa asetaa viitteiden arvoksi NULL. Tämä onkin yleisin

yksilöivien viitteiden poistopolitiikka myös AMRO:ssa.

Päivityspolitiikkoja on kummallekin viitetyypille vain kaksi: estopolitiikka

(default policy) ja ketjupolitiikka (cascade policy). Estopolitiikka toimii kuten

poistopoliitiikankin yhteydessä, mutta ketjupolitiikka muuttaa nyt viitteiden

arvot vastaamaan muuttetun avaimen uusia arvoja. Offline-toteutuksessa tätä

hyvin hyödyllistä ominaisuutta on kuitenkin käytetty rajatusti, sillä BDE:n

Parodox 7 –tietokanta ei tue monen tason ketjupolitiikkaa. Periaatteessa

päivityspolitiikkana tulisi kuitenkin poikkeuksetta olla ketjupolitiikka.

Tietokannan oikeellisuuden valvontaan voidaan SQL2-standardissa määritellä

vielä tarkistuksia (check) ja assertioita (assertion). Tarkistus on kenttä- tai

taulukohtainen sisällön oikeellisuuden tarkastus. Assertiot puolestaan

määritellään taulujen ulkopuolelle ja ne voivat valvoa toisistaan riippuvien

taulujen oikeellisuutta. Näitä voitaisiin suunnitella AMRO:on hyvinkin suuri

joukko, mutta eri tietokantojen tukemisepäselvyyksien vuoksi niitä on tehty

minimaalinen määrä. Tarkistukset voidaan muutenkin toteuttaa ohjelmallisesti

käyttöliittymän päässä, mikä on turvallisempaa ja helpompaa Windows-

sovellusten tietokantoja paremman päivitettävyyden takia. Joitakin

tietokantapuolen tarkistuksia kuitenkin käytetään: erityisesti otoskoko –kentistä

29

tarkistetaan, että asetettu kokonaisluku on nollaa suurempi. Assertioita ei

AMRO:n tietokantaan ole luotu lainkaan.

4.4.3 INDEKSIT

Tietokantojen kenttiä voidaan indeksoida, jolloin tietokantaan luodaan

eräänlainen “puhelinluettelo” kentän sisältämistä arvoista ja niitä vastaavista

tietueista. Tietueiden haku indeksoidun kentän arvojen perusteella onkin

merkittävästi nopeampaa (~ log(N)) kuin haku vastaavanlaisesta mutta

indeksoimattomasta kentästä (~ N). Indeksoinnin haittapuolena on tietokannan

päivitysten hidastuminen, kun tietueiden arvojen lisäksi myös indeksit pitää

päivittää. Indeksejä kannattaakin käyttää vain sellaisille kentille, joiden

perusteella tehdään usein hakuja. Mikäli tietokantaa päivitetään hyvin harvoin,

voi olla perusteltua luoda vähemmän käytetyillekin kentille omia indeksejä.

Tietokannat luovat tavallisesti kaikkien taulujen avainkentille indeksit

automaattisesti. Koska AMRO:ssa suurin osa hauista tehdään juuri

avainkenttien perusteella ja lisäksi kun tiedetään, että tietokantaa päivitetään

varsin usein, ei projektin tietokantaan ole luotu lisää indeksejä.

4.5 TIETOKANNAN TAULUT

Tässä kappaleessa kuvataan lyhyesti, mitä vaatimuksissa esitettyjä

ominaisuuksia tietokannan eri taulut toteuttavat ja mitä tauluilla saadaan

ohjelmiston kannalta aikaan. Esitys on pyritty pitämään tarkoituksella

mahdollisimman kompaktina. Numerointi vastaa liitettä 3.

4.5.1 YLEISKATSAUS TAULUIHIN

AMRO:ssa on viisi vahvaa yksilöjoukkoa: raaka-ainelajit (0), alkuaineet (2),

prosessipaikat (4), tuotteet (5) ja sulatukset (6). Nämä muodostavat tietokannan

ytimen.

Raaka-ainelajeista otetaan näytteitä, joiden pitoisuustulokset talletetaan

tauluihin 1 ja 8. Estimointi tuottaa lisäksi alkuaineittain pitoisuusestimaatteja,

jotka tallennetaan tauluihin 3 ja 7. Prosessipaikoittain halutaan vielä tallentaa

estimoinnin antamat raaka-ainesaannit, ja nämä on sijoitettu tauluihin 9 ja 10.

Estimoinnista niin ikään saatavat prosessipaikkojen alkuainesaantianalyysit on

talletettu tauluihin 11 ja 12.

30

Sulan koostumus valmistusprosessin eri vaiheissa (prosessipaikoissa) talletaan

tauluhin 13, 14 ja 15. Sulan koostumus määritetään siitä otetuista näytteistä, ja

näiden tiedot ovat nyt kahdessa jälkimmäisessä taulussa. Sulille lasketut

tavoitepitoisuudet halutaan myös talletaa jälkitarkasteluja varten tietokantaan,

ja tätä varten on perustettu taulu 16. Erityissulat –taulu (23) osoittaa tyyppi-

kentän perusteella mm. estimoinnissa viimeiseksi käytetyn sulatuksen.

Tauluihin 18 ja 19 voidaan tallettaa tuotteen koostumusrajat ja asiakaskohtaiset

koostumusrajat, jotka ovat luonnollisesti tärkeitä valmistusprosessin ja

optimointialgoritmin kannalta. Lisäksi taulu 20 sisältää suuren osan muita

optimointiin tarvittavia parametrejä kuten sakkofunktioiden määrittelyn ja

koostumusrajojen muunnosparametrit. Taulussa 17 määritellään kunkin

tuotteen raaka-ainerajoitukset ja tauluun 21 talletetaan lopulta optimoinnin

tuloksena saatavat panostusarvot. Tauluun 21 voidaan määritellä tyyppi-kentän

perusteella myös muita arvoja kuten panostuksessa todellisuudessa käytetyt

arvot.

Rekursiivisen pienimmän neliösumman menetelmän tarvitsemat kovarianssi-

matriisit talletaan tietokannan tauluihin 22 ja 24.

4.5.2 YLEISESTI TAULUJEN KENTISTÄ

Seuraavaksi pyritään valottamaan eri taulujen kenttien merkityksiä, ja sitä,

miksi kentän ylipäätään tulee olla taulussa. Jussi Ikäheimon diplomityöstä

(1999) saa laajemman käsityksen AMRO-projektissa käytetystä

tilastoanalyysistä; tässä pyritään antamaan asiasta vain nopea katsaus.

Monessa AMRO:n taulussa (mm. analyysit, katso taulukko 1) esiintyy

tilastoanalyyttisiä termejä kuten odotusarvo, odotusarvon keskihajonta ja

keskihajonta. Toisissa (näytteet) käytetään puolestaan sanoja keskiarvo ja

otoskeskihajonta. Näillä termeillä on tarkka käsitteellinen ero. Keskiarvo ja

otoskeskihajonta lasketaan aina todellisista otoksista (useasta näytteestä tai

näytesarjasta). Keskiarvo on tulosten aritmeettinen keskiarvo ja

otoskeskihajonta lasketaan käyttämällä samantyyppistä kaavaa. Odotusarvo ja

keskihajonta, jotka kuvattiin jo kappaleessa 2.3, ovat puolestaan jonkun

hyvinmääritellyn tilastollisen jakauman tunnuslukuja. Lisäksi

normaalijakaumissa odotusarvo ja keskihajonta ovat samalla jakauman

31

parametrejä, joilla määrätään jakauman huipun paikka x-akselilla ja jakauman

leveys. AMRO:n estimointiosuus pyrkii määrittämään romujen

alkuainepitoisuuksien tilastolliset jakaumat eli juuri nämä kaksi parametriä.

Estimoinnin tuloksena saadaankin siis estimaatit romujen alkuainepitoisuus-

jakaumien odotusarvolle ja keskihajonnalle. Estimointi ei kuitenkaan anna

ainoastaan todennäköisintä arvoa (varsinainen estimaatti) parametreille vaan

myös parametrin mahdollisten arvojen jakauman, jonka leveyttä kuvaa

estimaatin keskihajonta. Odotusarvon yhteydessä tätä kutsutaan odotusarvon

keskihajonnaksi ja varianssin (keskihajonnan neliö) yhteydessä varianssin

keskihajonnaksi. Tietokantaan voisi siis periaatteessa talletaan neljä tietoa:

odotusarvon, odotusarvon keskihajonnan, varianssin ja varianssin

keskihajonnan. Varianssin keskihajonnan merkitys optimoinnissa on kuitenkin

niin mitätön (paitsi laskujen vaikeuttamisessa), että se on jätetty pois

optimointialgoritmistä ja täten myös tietokannasta. Sen sijaan muut estimoinnin

antamat tulokset hyödynnetään optimoinnissa. Edellä esitetystä voidaankin

päätellä, että näytteitä tallettaviin tauluihin tulee sisällyttää kentät keskiarvo ja

otsokeskihajonta, kun taas estimaatteja sisältävillä tauluilla tulee olla

odotusarvo, odotusarvon keskihajonta ja keskihajonta.

Useassa taulussa esiintyvä lähde –kenttä kertoo tavallisesti kuka tai mikä on

tiedon tietokantaan syöttänyt. Päiväyskenttä on sisällytetty useimpiin tauluihin

aikaperspektiivin säilyttämiseksi. Otoskoko liittyy hyvin läheisesti keskiarvoon

ja keskihajontaan, ja se on erityisen tärkeä laskettaessa alkuainepitoisuuksien

tilastolllisia jakaumia. Mitä suurempi otoskoko, sitä tarkemmin raaka-aineen

tilastolliset jakaumat saadaan estimoitua. Myös SSR-kenttä (Sum of Squared

Residuals) liittyy estimointiin, ja se kuvaa estimaatin tarkkuutta. Sen

absoluuttinen arvo on kuitenkin mitäänsanomaton, mutta jakamalla se

kokonaisneliösummalla (vertaa Ikäheimo, 1999) saadaan käyttökelpoinen

vertailusuure. SSR-kenttää tarvitaan rekursiivisessa (itseään tarkentavassa)

estimoinnissa. Alkuaineiden laskennassa-kentällä voidaan säätää optimoinnin

ja estimoinnin huomioimia alkuaineita, ja raaka-ainelajien käytössä-kenttä ajaa

saman asian romujen osalta. Käytössä-kentällä on kuitenkin kolme eri arvoa:

“estimoinnissa”, “käytössä” ja “poissa käytöstä”. Estimoinnissa oleva romu

otetaan mukaan uuteen estimointiin mutta käytössä olevaa ei. “Poissa käytöstä”

–asetus määrää, että romua ei käytetä estimoinnissa eikä optimoinnissa.

Prosessipaikan muunnos- ja sakkoparametritaulu on eräänlainen moninaisten

parametrien kokoelma. Tänne on kerätty kaikki sakkofunktion määrittelyyn

32

tarvittavat parametrit: sakko ala- ja ylärajalla, sakkofunktion kulmakerroin ylä

ja alarajan jälkeen, sakkofunktion referenssiala- ja ylärajat sekä

romutuspitoisuus. Referenssirajat viittaavat yhteen viidestä

koostumusrajataulun rajoista ja romutuspitoisuus kertoo alkuaineen sen

prosenttimäärän, jonka ylitys johtaa välittömästi sulan romuttamiseen. Taulussa

on lisäksi prosessipaikkojen muunnosparametrit, joilla valmiin teräksen

koostumusrajat saadaan muutettua prosessipaikkakohtaisiksi rajoiksi

yksinkertaisilla +/- -prosenttiyksikkömuunnoksilla.

4.6 OFFLINE-TIETOKANNAN TOTEUTUS BORLAND DATABASE ENGINELLÄ

Offline-version tietokanta luotiin käyttämällä Borland C++ Builder 3:n mukana

tulevaa Database Desktopia, jonka käyttöliittymä näkyy kuvassa 8. Database

Desktop käyttää Borland Database Engineä (BDE), joka on C++ Builderiin

integroitu tietokantarajapinta. BDE:n avulla voidaan vaivattomimmin luoda

käyttöliittymästä saavutettava tietokanta, ja niinpä Database Desktop oli

luonnollinen valinta offline-tietokannan tekemiseen.

Database Desktop sallii useiden eri tietokantaformaattien käytön, mukaan

lukien dBase, Foxpro, Paradox ja monta muuta. Näiden joukosta pyrittiin

löytämään sellainen, joka tuki parhaiten SQL2-standardia, jolla AMRO:n

tietokanta oli suunniteltu. Monen vaiheen jälkeen päädyttiin Paradox 7 -

tietokantaan, joka oli myös BDE:n oletusformaatti. Jostain syystä Database

Desktop katsoi parhaaksi muuntaa tauluja Paradox 4.0, 5.0, 6.0 ja 7 –

formaattien välillä riippuen taulussa käytetyistä SQL-ominaisuuksista, joten

lopulta AMRO:n tietokanta muodostui varsin monentyyppisistä Paradox-

tauluista. Nämä toimivat kuitenkin saumattomasti yhteen, joten suurta

Kuva 8. Database Desktop.

33

käytännön merkitystä tällä ei juuri ollut. Paradoxin tietotyypit eivät suoraan ole

saman nimisiä kuin SQL2-standardissa, mutta seuraavia vastaavuuksia

käytettiin: Alpha (koko 255) – VARCHAR(255), Long Integer – INTEGER, ja

Number – FLOAT. Paradox ei myöskään tukenut usean tason ketjupolitiikkaa,

joten tätä käytettiin ainoastaan alimmilla tasoilla (suhteissa) ja muutoin

käytettiin estopolitiikkaa. Nolla-arvopolitiikkaa Paradox ei näyttänyt tukevan

lainkaan. Muutoin tietokannan määrittely onnistui varsin helposti.

4.6.1 BORLAND DATABASE ENGINEN ASETUKSET

AMRO:n offline-versio vaatii BDE:n toimiakseen, joten tietokoneessa, jossa

halutaan AMRO:n offline-versiota käyttää tulee olla C++ Builder 3 tai ainakin

sen BDE-osa asennettuna. C++ Builder vaatii oman lisenssin joka tapauksessa,

mutta ei ole aivan selvää, voiko BDE:tä käyttää lisenssittä, vai joudutaanko

sillekin hankkimaan oma lisenssi.

BDE:n tulisi asentua automaattisesti C++ Builderin asennuksen yhteydessä.

Asennuksen jälkeen Windowsin ohjauspaneeliin (Control Panel) tulisi ilmestyä

BDE Administrator -ikoni, josta BDE:n hallintajärjestelmän saa käynnistettyä.

Täällä jokaiselle BDE-tietokannalle tulee luoda oma aliaksensa (alias), joka

Kuva 9. BDE Administrator.

34

määrittelee tietokannan ajurit ja mistä hakemistosta tietokannan tiedostot

löytyvät. AMRO:n offline-versio käyttää "AMRODB"-nimistä aliasta. Tämä

saadaan luotua valitsemalla Object -valikosta New. Tietokannan tyypiksi tulee

Standard, Default Driver on Paradox, Enable BCD False ja Path viittaa

hakemistoon, johon tietokannan tiedostot on asennettu. Kuvassa 9 on esitetty

BDE Administrator ja AMRODB:n oikeat asetukset.

4.7 TIETOKANNAN ANALYYSI

4.7.1 TIETOKANNAN SUUNNITTELUN PERIAATTEET

Tietokantaa suunniteltaessa on sekä ajateltu joustavuutta että vältetty

redundanssia. Joustavuudella pyritään mahdollistamaan tietokannan rakenteen

laajentaminen ja muuttaminen yksinkertaisesti. Joustavuuden perustan

muodostaa ongelmakentän käsitteiden jakaminen omiksi yksilöjoukoikseen

E/R-kaavion avulla, jolloin päästään uusien riippuvuussuhteiden luonnin ja

tietokannan laajentamisen kannalta parhaaseen rakenteeseen. Redundanssin eli

toisteisuuden välttäminen viittaa puolestaan turhan tai toisteisen tiedon

poistamiseen tietokannasta. On selvää, että saman tiedon tallettaminen moneen

paikkaan tietokannassa on sekä tilaa vievää että päivittämistä hankaloittavaa.

AMRO:ssa onkin jouduttu jakamaan käsitteitä kahteen tauluun, jotta toisteiselta

tiedolta vältyttäisiin. Esimerkiksi sulan näytteet ja niiden tulokset ovat eri

tauluissa (yksilöjoukkona ja attribuutillisena suhteena alkuaineisiin). Näytteelle

on määritelty päiväys ja otoskoko, jotka ovat yhteisiä koko näytteelle. Jos

näyte-taulu haluttaisiin poistaa ja yhdistää nämä tiedot näytteen

alkuainepitoisuustauluun, olisi tuloksena sama päiväys ja otoskoko kyseisen

näytteen kunkin pitoisuustuloksen jälkeen. Tällöin tietokantaan syntyisi

toisteista tietoa eli redundanssia. Tietokanta, jossa ei ole toisteista tietoa, on

Boyce-Codd-normaalimuodossa (Boyce-Codd normal form, BCNF, ks. Ullman

ja Widom 1997). Näin voidaankin todeta, että myös AMRO:n tietokanta on

BCNF:ssä.

Käyttäjäystävällisyyteen on kiinnitetty erityistä huomiota suunniteltaessa

viitteiden päivitys- ja poistopolitiikkoja (kappale 4.4.2), joilla poistot ja

päivitykset viitetietueissa automatisoidaan. Lisäksi tietokannan käsitteiden

joukko on alusta alkaen valittu niin suureksi, että optimoinnin ja estimoinnin

laajentaminen koskemaan koko prosessia valokaariuunin sijasta ei välttämättä

aiheuttaisi muutoksia tietokantaan. Erityisesti prosessipaikka –taulu on luotu

35

sovellusalueen laajentamista ajatellen. Prosessipaikka -taululla voidaan

tietokantaan mallintaa halutunlainen valmistusprosessi, eikä sen tarvitse

välttämättä muistuttaa Outokummulla käytössä olevaa prosessia.

Tietokannan suunnittelun periaatteina voitaisiin vielä pitää oikeellisuutta ja

johdonmukaisuutta. Näiden mukaan tulee varmistaa, että riippumatta tehdyistä

päivityksistä tietokanta pysyy aina eheänä eikä virheellisiä viittauksia tai muita

epätoivottuja asioita pääse syntymään. Näiden periaatteiden toteutumiseen on

kiinnitetty huomiota viitteiden määrittelyssä.

4.7.2 TIETOKANNAN RAJOITUKSET JA SOPIVUUS KÄYTTÖTARKOITUKSEENSA

Huolimatta joustavuusperiaatteesta on tietokanta jouduttu rajaamaan

suhteellisen tarkasti. Tietokanta on suhteellisen joustamaton käytettävän

estimointimenetelmän suhteen, ja sen vaihtaminen saattaa vaatia osin suuriakin

muutoksia tietokantaan. Optimointi- ja estimointiosuuden tietojen talletus olisi

myös mahdollista suunnitella systemaattisemmin, mutta johtuen projektin

aikana tehdystä jatkuvasta optimointi- ja estimointialgoritmien kehitystyöstä ei

näiden vaatimaa tiedontallennustarvetta ole voitu etukäteen arvioida kattavasti.

Niinpä tuloksena on tietoja talletellaankin hieman kirjavasti eri tauluhin.

Offline-tietokanta on suunniteltu erityisesti ajatellen asiakasyrityksen

valmistusprosessia, joten katsomme, että se sopii erinomaisesti

käyttötarkoitukseensa. Ongelman saattaa kuitenkin tulevaisuudessa muodostaa

ohjelmiston integroiminen Outokummun tietojärjestelmiin, joissa tulisi käyttää

siellä valmiiksi olevia tauluja. Mikäli näitä ei ole eriytetty joustavasti, saattaa

integroimisvaiheessa esiintyä merkittäviäkin ongelmia esimerkiksi tärkeiden

suhdetaulujen luomisessa.

4.7.3 PARANNUSEHDOTUKSIA

Parannusehdotukset on projektin aikana pyritty toteuttamaan valmisteilla

olevaan ohjelmistoon, joten niiden määrä tähän kappaleeseen on

ymmärrettävästi jäänyt pieneksi. Tämän kappaleen parannusehdotukset

koskevat pääasiassa AMRO:n offline-tietokantaa.

Suurin parannus offline-version tietokantaan saataisiin vaihtamalla sen alusta

vaativampaan käyttöön tarkoitettuun tietokantajärjestelmään, esimerkiksi

Microsoftin SQLServer 7.0:aan. Tällöin kaikki tarvittavat päivitys- ja

36

poistopolitiikat voitaisiin helposti toteuttaa ja liitteen 2 SQL-listausta

kyettäisiin suoraan käyttämään tietokannan taulujen luontiin. SQLServerin tai

muun vastaavan tasoisen tietokannan hankintaan ei ole kuitenkaan ryhdytty

kustannussyistä, sillä saavutettava hyöty on pieni ja yhteensopivuusongelmat

Borland C++ Builder 3:n ja tietokannan välillä saattavat osoittautua

merkittäviksi.

AMRO-projektissa E/R-kaavio ja SQL-skripti luotiin toisistaan erillään, mikä

saattaa aiheuttaa niissä poikkeavuuksia. Markkinoilta on kuitenkin saatavilla

E/R-kaavioiden luontiin erikoistuneita ohjelmistoja, joiden kaaviot voidaan

suoraan muuntaa SQL-kielelle. Tällaisen ohjelmiston käyttö olisi ollut myös

AMRO:ssa suotavaa, mutta kustannussyistä ja koulutustarpeen takia tähänkään

ei lähdetty, vaan E/R-kaavio toteutettiin Microsoft PowerPointilla ja SQL-

listaus tekstieditorilla.

AMRO:n offline-version tietokanta olisi voitu suunnitella muistuttamaan

enemmän Outokummun omaa tietokantaa, mutta tietokannan dokumentaatiota

ei kuitenkaan onnistuttu saamaan suunnitteluryhmän käyttöön ennen offline-

version valmistumista. Niinpä integroimisvaiheeseen jää hieman enemmän

työtä, kun osa tauluista joudutaan korvaamaan Outokummulla jo valmiina

olevilla tauluilla ja suhdetaulut joudutaan sopeuttamaan tehtyihin muutoksiin.

Tietokannassa on lisäksi ratkaisematon tehokkuusongelma. Tämän hetkisellä

toteutuksella kovarianssimatriisien (taulut 22 ja 24) käsittely on tuskastuttavan

hidasta eteenkin, jos estimoinnissa on mukana paljon eri raaka-ainelajeja.

Kovarianssimatriisien alkioiden määrä on verrannollinen raaka-ainelajien

neliöön, ja niinpä romujen määrän kasvaessa tiedontallennustarve nousee

voimakkaasti. Tällä hetkellä jokainen kovarianssimatriisin alkio joudutaan

talletamaan erikseen tietokannan eheyden takaamiseksi raaka-ainelajeja

poistettaessa ja lisättäessä, minkä seurauksena koko kovarianssimatriisin

talletus on suhteettoman hidasta.

37

5. TIETOKANNAN KÄYTTÖLIITTYMÄ

5.1 JOHDATUS TIETOKANNAN KÄYTTÖLIITTYMÄÄN

Tietokannan käyttöliittymä on tehty tietokannan taulujen sisältämän tiedon

muokkaamista ja lukemista varten. Se ei tarjoa erikoistyökaluja, mutta sen

perusimplementaatio riittää useimpien toimenpiteiden tehokkaaseen suoritta-

miseen. Käyttöliittymällä ei kuitenkaan voi muuttaa tietokannan rakennetta,

vaan se on tarkoitettu ainoastaan taulujen tietuiden käsittelyyn. Tietokannan

käyttöliittymää ei tule sekoittaa optimointi- ja estimointimoduulin

käyttöliittymään, joka on oma ohjelmansa.

5.2 PERUSRATKAISUT

Käyttöliittymän pääikkuna on MDI-ikkuna (Multi-Document Interface), jonka

sisälle näkymät (view) aukeavat ali-ikkunoihin. Näkymä on ikkuna, joka liittyy

johonkin tietokannan tauluun. Se sisältää ne taulun tietueet, jotka täyttävät

näkymän hakuehdon (filter). Näkymiä avataan pääikkunan valikoista, ja

samaan aikaan voi olla auki useita eri näkymiä.

Viitteet on toteutettu käyttöliittymässä siten, että kohdetietue valitaan

näkymästä, joka avautuu, kun viitekenttää yritetään muuttaa. Tällä tavoin

käyttäjä näkee, mitä vaihtoehtoja on olemassa, ja joutuu valitsemaan näistä

yhden. Näin varmistetaan, että viitekenttään voidaan syöttää vain sallittu arvo.

Valintanäkymä toimii samalla lailla kuin tavallinen näkymä, eli siitä voidaan

luoda, muuttaa ja poistaa tietueita. Tämä sallii kohdetietueen luomisen samalla,

kun sitä ollaan valitsemassa.

Tietuiden poistoissa ja niiden avainkenttiä muutettaessa viite-eheys säilytetään

joko esto- tai ketjupolitiikalla (default policy tai cascade policy). Se, kumpaa

käytetään, on viitekohtainen ominaisuus, joka on määrätty tietokannassa.

Offline-version Paradox 7 ei kuitenkaan tue kuin yhden tason ketjupolitiikkaa,

mikä ei riitä AMRO-tietokannan tarpeisiin. Monen tason ketjupolitiikka on

kuitenkin toteutettu ohjelmallisesti offline-version käyttöliittymässä, mutta se

toimii ainoastaan tietueiden poistoissa. Tästä syystä tietueiden avainkenttiä ei

voi muuttaa, jos niihin on monen tason viittauksia.

38

5.3 KÄYTTÖOHJE

5.3.1 PÄÄIKKUNA

Kuvassa 10 on tietokannan käyttöliittymän pääikkuna. Raw Materials-,

Meltings-, Products-, Elements- ja Process Locations-valikoista voi avata

näkymiä tietokannan tauluihin. Kuitenkin jos käyttäjä yrittää avata jo olemassa

olevan näkymän toiseen kertaan, ei uutta näkymää luoda, vaan olemassa oleva

näkymä tuodaan etualalle. Samaan tauluun voi kuitenkin olla auki monta

erilaista näkymää, jotka poikkeavat toisistaan hakuehdon (filter) osalta.

Pääikkunan Main-valikossa on Toggle Recursive Deletion -toiminto, jolla

valitaan, käytetäänkö ketjupolitiikkaa (vai estopolitiikkaa) tietueiden poistoissa.

Perusasetuksena on estopolitiikka. Tämä toiminto implementoi ohjelmallisesti

monitasoisen ketjupoiston, mutta luonnollisesti sitä ei tarvitse käyttää, jos

tietokanta tukee toimintoa. Monitasoinen ketjupolitiikka on toteutettu ajatellen

offline-version Paradox 7 –tietokantaa, joka on hyvin rajoittunut viite-eheyden

käsittelyssä.

Windows-valikko sisältää MDI-ikkunan perustoiminnot ali-ikkunoiden

lajittelemiseksi: Cascade, Tile ja Arrange Icons. Cascade lajittelee auki olevat,

minimoimattomat näkymät siistiin pinoon. Tile taasen jakaa pääikkunan tilan

Kuva 10. Pääikkuna, jossa on auki kaksi näkymää.

39

tason auki olevien kesken. Arrange Icons –toiminnolla voi lajitella minimoidut

näkymät siten, että ne muodostavat rivin pääikkunan alalaitaan.

Pääikkunan Help-valikon Contents-toiminto avaa käyttöliittymän ohje-

tiedoston. Offline-versioon ohjetiedostoa ei ole tehty.

5.3.2 NÄKYMÄ

Näkymät aukeavat omiin ali-ikkunoihinsa. Ali-ikkunan otsikkorivillä lukee sen

taulun nimi, mihin näkymä osoittaa. Taulun nimen perässä on näkymän

hakuehto, joka on muotoa <kenttä> = <arvo>. Kun pääikkunasta avataan

näkymä, sen hakuehdoksi tulee “All”, eli siinä näkyvät kaikki kyseisen taulun

tietueet (ks. kuva 11).

Näkymän pääosan muodostaa taulukko, jonka riveillä näkymän tietueet ovat.

Tietueita ei voi lisätä tai muokata suoraan taulukosta, vaan se tehdään erillisestä

ikkunasta, joka avautuu Add- tai Edit-napista (ks. kappale 5.2.3). Tietueiden

poisto käy valitsemalla poistettavat rivit ja painamalla Delete-nappia. Jos

poistettaviin tietueihin on viittauksia, on viite-eheyden säilyttämiseksi

käytettävä jotain poistopolitiikkaa. Mikäli on valittuna estopolitiikka, ei poistoa

suoriteta, vaan ne tietueet, joista on viittaus, pitää poistaa ensiksi käsin (jos ne

ylipäätänsä halutaan poistaa). Jos käytössä on ketjupolitiikka, poistaa tietokanta

automaattisesti ne tietueet, joista on viittaus poistettavaan tietueeseen..

Yksi näkymän tärkeimmistä toiminnoista on filtteröidyn näkymän avaus

sellaiseen tauluun, josta on viite näkymän tauluun. Tämän tapahtuu

valitsemalla näkymästä tietue ja painamalla hiiren oikeaa nappia, jolloin

avautuu popup-valikko (ks. kuva 12). Tässä valikossa on kaikkien niiden

Kuva 11. Pääikkunasta avattu näkymä. Hakuehtona on “All”.

40

taulujen nimet, joista on viittaus auki olevaan tauluun (sekä Refresh-toiminto,

jolla näkymä voidaan päivittää manuaalisesti). Välttämättä yhdestäkään

taulusta ei ole viittausta näkymään, jolloin valikko on Refresh-toimintoa lukuun

ottamatta tyhjä. Valitsemalla jokin taulu valikosta avautuu uusi näkymä tähän

tauluun. Tämän näkymän hakuehdossa lukee edellisestä näkymästä valitun

tietueen avain, esimerkiksi “Element ID = Cu” (ks. kuva 13). Tällä tavoin

voidaan valita ensiksi Meltings-taulusta sulatus ja avata Melts-taulu tällä

sulatuksella, jolloin Melts-taulusta näkyvät vain ne sulat, jotka liittyvät

valittuun sulatukseen. Melts-taulusta voidaan yhä avata Melt Samples -taulu,

jolloin nähdään kyseisestä sulasta otetut näytteet. Melt Samplesistä voidaan

edelleen avata Melt Sample Contents, josta löytyy kyseisen sulanäytteen

sisältö. Useimpien taulujen käyttö onkin vaikeaa, ellei mahdotonta, ilman

tällaista filtterointia. Ilman filtteröintejä voi käyttää lähinnä RawMaterials-,

Meltings-, Products-, Elements- ja ProcessLocations-tauluja. Käyttäessään

käyttöliittymää kannattaakin aloittaa näistä tauluista ja filtteröidä haluamansa

tiedot muista tauluista.

5.3.3 TIETUEEN LISÄYS JA EDITOINTI

Tietueita lisätään ja muutetaan erillisestä ikkunasta, jossa näkyvät eri kenttien

ominaisuudet (ks. kuva 14). Kentät voivat olla pakollisia (mandatory), avaimia

(primary key), viitteitä (reference) ja/tai yksilöllisiä (unique). Nämä on merkitty

erikoismerkillä kentän nimen perään. Pakollisia kenttiä ei voi jättää tyhjäksi.

Avainkenttiä voi olla taulussa yksi tai useampia. Ne määräävät yhdessä

tietueelle yksilöllisen tunnisteen. Avaimien avulla tietokanta etsii ja tunnistaa

Kuva 12. Popup-valikko, josta voi avata filtteröityjä näkymiä.

41

tietueita, ja näkymät myös filtteröidään avaimien mukaan. Viitteet voivat

muodostua yhdestä tai useammasta kentästä riippuen siitä, kuinka monta

avainta viittauksen kohdetaulussa on. Viittaus osoittaa aina kohdetaulun

avainkenttiin. Joskus myös avainkentät ovat viittauksia, jolloin taulua sanotaan

heikoksi yksilöjoukoksi. Yksilöllisissä kentissä kahdella tietueella ei saa olla

samaa arvoa.

Kun tietueen lisääminen aloitetaan, käyttöliittymä tarjoaa uusiksi arvoiksi

kunkin kentän perusarvoja. Usein esimerkiksi päivämääräkenttiin tarjotaan sen

hetkistä päivämäärää. Kun muutetaan olemassa olevaa tietuetta, muokkaus-

ikkunassa näkyvät tietueen alkuperäiset arvot. Tietueen kenttiä voi muuttaa

napsauttamalla niitä hiirellä kahdesti tai painamalla Enteriä. Kentät eivät

hyväksy mitä tahansa arvoja, vaan ne ovat joko merkkijonoja (string),

kokonaislukuja (integer), desimaalilukuja (real) tai päivämääriä (date). Niiden

tyyppiä ei näe käyttöliittymästä, mutta yleensä se selviää kentän nimestä.

Erityisesti ID-tyyppiset kentät ovat merkkijonoja. Päivämääräkenttien

hyväksymä päivämäärän muoto riippuu tietokoneen asetuksista. Windows NT

–käyttöjärjestelmässä päivämäärän muoto asetetaan ohjauspaneelin (Control

Panel) maakohtaiset asetukset (Regional Settings) –valikosta. Samasta paikasta

voidaan myös asettaa desimaalierottimen tyyppi.

Kun viitekenttää yritetään muuttaa, avautuu uusi näkymä siihen tauluun, johon

viittaus osoittaa (ks. kuva 15). Tästä taulusta valitaan se tietue, johon

viittauksen halutaan osoittavan, ja painetaan OK-nappia. Kyseinen tietue

voidaan myös luoda avautuneesta näkymästä, mikäli se on tarpeen. Kun

Kuva 13. Filtteröity näkymä Element Yields –tauluun. Hakuehto on “ElementID = Cu”.

42

viitetietue on valittu, sen avaimet kopioituvat viitekenttiin.

Tietuiden lisäys suoritetaan erillisessä ikkunassa, koska kaikki muutokset pitää

kirjoittaa tietokantaan kerralla. Tällä tavoin mahdollistetaan myös muutosten

peruminen, mikä ei olisi mahdollista, jos näkymän kenttiä muutettaisiin

välittömästi. Online-versiossa tietokannan taulut pitää lukittaa siksi aikaa, kun

tietueita muutetaan, jotta eri käyttäjät eivät muuttaisi samaan aikaan samoja

tietueita.

Kuva 14. Ikkuna tietueen lisäämiseen ja muuttamiseen. Quantityn, ArrivalRaten, Pricen ja In Usen aloitusarvot näkyvät kuvassa.

Kuva 15. Elements-tauluun avattu valintanäkymä. Ainoa ero tavalliseennäkymään on oikeassa alareunassa olevat OK- ja Cancel-napit.

43

5.4 IMPLEMENTAATIOTASON RAKENNE

Tässä kappaleessa käsitellään tietokannan käyttöliittymän koodin rakennetta ja

siihen liittyviä kysymyksiä. Nämä tiedot on tarkoitettu lähinnä käyttöliittymää

kehittävien henkilöiden tiedoksi.

5.4.1 KÄYTTÖLIITTYMÄOHJELMISTON RAKENNE

Käyttöliittymän ikkunat on lueteltu taulukossa 5.1, ja sen koodi rakentuu

taulukon 5.2 mukaisesti.

Taulukko 5.1. Käyttöliittymän ikkunat.

Ikkuna KuvausAboutBox Ilmoittaa tietoja ohjelmistosta ja sen tekijöistä.DBForm Sisältää tietokannan käsittelyyn vaadittavat kontrollit.EditForm Tietueiden lisäykseen ja muokkaukseen käytetty

ikkuna.MainForm Käyttöliittymän pääikkuna.TableDialog Näkymä tietokantaan.

Taulukko 5.2. Käyttöliittymän koodin rakenne.

Tiedosto SisältöAbout.cppAbout.h

AboutBoxin implementaatio. Generoitua koodia.

AmroDBMgr.cppAmroDBMgr.h

Alkuproseduuri. Generoitua koodia.

DBCtrls.cppDBCtrls.h

DBFormin implementaatio. Generoitua koodia.

DBFunc.cppDBFunc.h

C++ tietokantarajapinta.

DBStructure.cppDBStructure.h

C++ implementaatio tietokannan rakenteesta.Riippuvuus tietokannan rakenteeseen.

Edit.cppEdit.h

EditFormin toiminnallisuus.

Global.cppGlobal.h

Globaalit muuttujat.

globaldef.cppglobaldef.h

Globaalit määrittelyt.

iniwrite.cppiniwrite.h

Ini-tiedoston luku- ja kirjoitusrutiinit.

MainCode.cppMainCode.h

MainFormin toiminnallisuus.

TableMDIDialog.cppTableMDIDialog.h

TableDialogin toiminnallisuus.

WindowPos.cppWindowPos.h

Ikkunan keskitys- ja paikantallennusrutiinit. Vaatiiiniwrite.cpp:n toimiakseen.

Keskeiset tiedostot ovat MainCode.cpp, Edit.cpp, TableMDIDialog.cpp,

44

DBStructure.cpp ja DBFunc.cpp sekä näihin liittyvät header-tiedostot. Näistä

kolme ensimmäistä implementoivat käyttöliittymän keskeiset ikkunat ja kaksi

viimeistä vastaavat käyttöliittymän rajapinnasta tietokantaan.

5.4.2 DBSTRUCTURE

DBStructure.cpp ja DBStructure.h vaativat erityistä huomiota, sillä ne

implementoivat tietokannan rakenteen. Tietokannan taulut, viitteet ja kentät on

implementoitu olioina, eli kyseessä on relaatiotietokannan mallintaminen

oliopohjaisesti. Relaatiotietokannan osia vastaavat DBStructuressa DBTable-,

DBReference- ja DBField-oliot. Näiden välisiä suhteita kuvaa liitteenä 4 oleva

DBStructuren UML-kaavio. DBTable-olioiden välisiä suhteita kuvaavat linkit

(link). DBTablen linkit ovat osoittimia sellaisiin tauluihin, joista on

DBReference-viite kyseiseen tauluun. Käytännössä ne implementoivat

viitteiden takaperoisen navigoitavuuden, joita tarvitaan näkymien

filtteröinnissä. Linkkien tallettaminen DBTable-olion listaan on oikeastaan

tiedon monistamista, sillä sama tieto saataisiin käymällä kaikki viittaukset läpi

ja valitsemalla niistä ne, jotka osoittavat kyseiseen DBTable-olioon. Näin ei

kuitenkaan menetellä, koska viittausten läpikäyminen olisi työlästä ja se monin

paikoin epäselventäisi koodia.

Tietokannan rakenne on koodattuna edellä mainituilla oliolla

DBStructure.cpp:n funktiossa CreateAmroDatabase(). Tämän rakenteen on

ehdottomasti vastattava todellisen tietokannan rakennetta. Mikäli tietokannan

rakennetta muutetaan, esim. lisäämällä uusi kenttä johonkin tauluun, on

vastaava muutos tehtävä myös DBStrucure.cpp:hen. Jos näin ei menetellä,

käyttöliittymä olettaa tietokannan muodoksi muuta, kuin mitä se

todellisuudessa on, mikä todennäköisesti johtaa virhetilanteisiin.

Liitteenä 1 olevassa E/R-kaaviossa, jokainen tietokannan taulu on numeroitu

yksilöllisellä numerolla. Tämä numero edustaa taulujen luomisjärjestystä sekä

SQL-skriptissä että DBStructure.cpp:ssä. Se on erityisen tärkeä

DBStructure.cpp:ssä, jossa – vastoin kuin SQL:ssä – ei voida viitata tauluihin

niiden nimen perusteella, vaan täytyy käyttää luomisjärjestyksen numeroa.

DBTable-oliot luodaan tables-listaan, joka on määritelty DBStructure.h:ssa. On

tärkeää huomata, että tauluja ei voida luoda missä järjestyksessä tahansa, vaan

on noudatettava melko tarkkaan määrättyä järjestystä. Rajoitukset muodostuvat

siitä, että sellaisiin tauluihin, joita ei ole luotu, ei voida viitata.

45

Mikäli tietokannan viittauksia muutetaan radikaalilla tavalla, voi olla, että

taulut joudutaan luomaan eri järjestyksessä, jolloin myös niiden numerointi

muuttuu. Tällöin suuri osa CreateAmroDatabase()-proseduurista joudutaan

kirjoittamaan uudestaan, mikä on aikaa vievää ja virhealtista.

5.4.3 TABLEDIALOG

Tietokannan näkymäikkuna, TableDialog, toimii kahdessa eri moodissa: MDI-

alaikkunana ja modaalina dialogina. Ensimmäisessä moodissa ikkuna on

“tavallinen” näkymä tietokantaan, joka avautuu pääikkunan sisälle.

Jälkimmäiseen moodiin ikkuna avataan vain, kun siitä tehdään viitteen

valintaikkuna. Tällöin ikkuna avautuu pääikkunan ulkopuolelle erilliseksi

dialogiksi, ja siihen myös ilmestyy OK- ja Cancel-napit. OK-nappia

painettaessa valinta talletetaan TableDialogin selectedKeys-muuttujaan, josta se

voidaan jälkeen päin lukea. Dialogimoodissa näkymästä ei voida avata

filtteröityjä näkymiä.

5.5 KÄYTTÖLIITTYMÄN ANALYYSI

5.5.1 LAAJENNETAVUUS

Tässä dokumentissa käsitelty tietokannan käyttöliittymää voidaan käyttää

minkä tahansa staattisen tietokannan käyttöliittymänä (tietokannan, jonka

tauluja ja kenttiä ei muuteta, eikä uusia tauluja luoda). Tämä edellyttää

DBStructuressa määritellyn tietokannan muodon uudelleenkoodaamista.

5.5.2 RAJOITUKSET

Käyttöliittymällä ei voida muuttaa tietokannan rakennetta, eikä sitä voida

käyttää kuin staattisten tietokantojen kanssa. Se on tarkoittettu yksin omaan

tietueiden muokkaamiseen. Koska AMRO-projektin yhteydessä käytettävä

tietokannan rakennetta ei muuteta aktiivisesti, oli luonnollista, että rajoituttiin

vain tällaisten tietokantojen käsittelyyn. Koska koko tietokanta sisältää vain

optimoinnin ja estimoinnin vaatimaa tietoa, ei sen rakennetta voida muuttaa

ilman, että muutoksen vaikutukset optimointi ja estimointimoduulissa

huomioidaan.

Tietokannan käyttöliittymä ei tue vapaita SQL-kyselyjä, vaikkakin niiden

46

toteutus olisi verrattain yksinkertaista. Käyttöliittymä on kuitenkin tehty juuri

SQL-kutsujen korvaamiseksi, joten toimintoa ei nähty tarpeelliseksi toteuttaa.

Monimutkaisia SQL-kutsuja ei ole myöskään toteutettu. Niistä keskustellaan

enemmän seuraavassa kappaleessa.

5.5.3 SOPIVUUS KÄYTTÖTARKOITUKSEENSA JA PARANNUSEHDOTUKSIA

Tietokannan käyttöliittymän käyttäminen vaatii melko hyvää tuntemusta

tietokannan rakenteesta, koska näkymien filtteröinnin hallinta vaatii sitä.

Esimerkiksi jos haluaa tarkastella tietyn tuotteen laadutusrajoja, ei pidä avata

laadutusrajataulua, vaan tuotetaulu, josta sitten avaa filtteröidyn näkymän

laadutusrajatauluun. Tämän hetkinen filtteröinti sallii ainoastaan karsinnan

avainkenttien perusteella. Toiminnallisuutta esimerkiksi siihen, että haluaa

hakea tiettynä päivänä tapahtuvat sulatukset, ei ole.

Käyttöliittymä ei tarjoa erikoistyökaluja yleisimpiin toimintoihin, vaan niihin

on käytettävä käyttöliittymän näkymiä. Erikoistyökaluja ei ole voitu toteuttaa,

koska ei ole tutkittu, mitkä toiminnot olisivat tärkeitä ohjelmiston käyttäjille.

Yksi yleisimmistä ohjelmistoprojektien virheistä on turhien ominaisuuksien

toteutus (Haikala ja Märijärvi 1998). On selvää, että väärien tai turhien

ominaisuuksien kehittäminen ohjelmistoon sekä vaikeuttaa ohjelmiston

jatkokehitystä että hukkaa resursseja. Kuitenkin kun ohjelmistoa integroidaan

Outokummun tietojärjestelmiin, voidaan käytettävyysanalyysi suorittaa, ja sen

perusteella päättää, mitkä toiminnot vaativat parempia ominaisuuksia käyttö-

liittymältä ja mitkä kannattaa suorittaa jo olemassa olevalla toiminnallisuudella.

Tietokannan käyttöliittymästä puutuvat online-ohjeet. Niiden tekeminen ei

kuitenkaan ollut ajankohtaista ensimmäisessä vaiheessa, sillä käyttöliittymä

tulee todennäköisesti muuttumaan, kun siirrytään Outokummun järjestelmiin.

Käyttöliittymään tulisi jatkossa implementoida kaikki tärkeimmät tietokanta-

toiminnot. Nämä tulisi selvittää käytettävyysanalyysin perusteella. Näitä

olisivat sellaiset SQL-kyselyt, joita ei voisi suorittaa näkymän filtteröinnillä.

Esimerkiksi tekememättä olevien sulatusten haku on tällainen toiminto.

Näkymiä tulisi voida filtteröidä vapaamuotoisen hakuehdon perusteella,

esimerkiksi “Päivämäärä <= 1.1.1999” tai “Source = N.N.”. Jotta hakuehdoista

saataisiin käytettäviä, niiden implementaatio tulisi miettiä tarkkaan.

47

Hakuehtojen avulla käyttäjä voisi valita sellaiset tietueet, joita ei saa tämän

hetkisellä filtteröinneillä tehtyä. Esimerkiksi tiettynä päivänä tehtyjen

sulatusten haku onnistuisi tällaisilla filttereillä.

Tietuiden muokkausikkunassa kenttien tyypit voisi lisätä erikoismerkkilistaan.

Toisaalta liiallinen erikoismerkkien paljous voi haitata käytettävyyttä.

Pahimmillaan kentän nimen perässä voisi siis olla neljä tai viisi erikoismerkkiä,

ja tällöin katoaisivat tavalliset kentät, joiden nimen perässä ei ole yhtään

erikoismerkkiä.

Parantamista löytyy myös SQL-kyselyden virheilmoitusten hallinnasta. Käyttö-

liittymä voisi ilmoittaa tarkan virheilmoituksen eikä ainoastaan että virhe

tapahtui.

DBStructureen voisi lisätä tulevaisuuden varalta tietotyypin time, jota SQL

tukee.

Tulevaisuudessa on mahdollista luoda tietokantaeditori, jolla tietokannan

muoto voitaisiin koodata ja tallettaa tiedostoon, josta käyttöliittymä lukisi sen.

Paras mutta työläin tapa olisi tehdä käyttöliittymään SQL-kieltä ymmärtävä

parseri, joka lukisi tietokannan rakenteen suoraan tietokannan luovista SQL-

skripteistä. Tällainen toteutus mahdollistaisi myös dynaamisen tietokanta-

arkkitehtuurin, jossa tauluja ja uusia kenttiä voitaisiin luoda ajon aikana.

Tällöin vastaava toimenpide pitäisi suorittaa myös DBStructuressa.

Jotkut edellä mainituista ominaisuuksista jätettiin toteuttamatta offline-

versioon, koska rajallisen ajan puitteissa pyrittiin keskittymään vain

ohjelmiston olennaisiin osiin. Osaa ominaisuuksista ei voitu toteuttaa, koska

niiden tarpeellisuudesta ei ollut varmuutta (vrt. Haikala ja Märijärvi 1998).

48

6. OHJELMISTON INTEGEROINTI OUTOKUMMUN JÄRJESTELMIIN

6.1 YLEISKUVAUS

Projektin toisessa vaiheessa ohjelmiston offline-versio integroidaan

Outokumpu Polarit Oy:n Tornion tehtaiden tietojärjestelmiin, eli siitä tehdään

online-versio. Online-versiossa ohjelmiston eri osat on hajautettu siten, että

tietokanta ja laskentamoduuli ovat UNIX-ympäristössä, ja käyttöliittymät

keskustelevat niiden kanssa Windows-ympäristöstä notifikaatiopalvelimen

avulla. Tietoliikenne tapahtuu TCP/IP-protokollalla, joten periaatteessa se voi

kulkea internetin kautta. Kuitenkin turvallisuuskysymykset saattavat estää näin

laajan käytön. Todennäköisesti ohjelmistoa tullaan kuitenkin käyttämään vain

Outokummun Tornion tehtaiden sisäisessä verkossa.

Online-versio on suunniteltu toteutettavaksi MVC-arkkitehtuurilla, jonka

pääperiatteet kerrottiin kappaleessa 3. Tässä kappaleessa taas keskitytään

online-version yksityiskohtiin.

6.2 TOTEUTUS MVC-ARKKITEHTUURILLA

Liitteenä 5 olevassa kaaviossa on kuvattu, kuinka ohjelmiston arkkitehtuuri

muuttuu siirryttäessä online-versioon. BDE:stä luovutaan ja siirrytään

käyttämään Outokummun notifikaatiopalvelua. Eri ohjelmien funktioiden

rajapinnat pidetään samanlaisina kuin ennenkin, mutta itse funktiot muutetaan

käyttäämään sqlclient-kirjastoa, jolla tietoliikenne notifikaatiopalvelun kautta

tapahtuu.

MVC-arkkitehtuuri vaatii, että tietokanta rekisteröi siihen yhteydessä olevat

käyttöliittymät, jotta päivityskutsut voitaisiin lähettää. Tästä syystä joudutaan

lisäämään käyttöliittymiä kirjaava palvelu tietokannan ja käyttöliittymien

väliin. Tästä palvelusta käytetään tässä nimeä AMRO-SQL-Server. Se myös

vastaanottaa kaikki tietokannalle tulevat SQL-kyselyt ja lähettää ne edelleen

tietokannalle. Jos kyselyn tuloksena tietokanta muuttui, AMRO-SQL-Server

lähettää päivityspyynnön kaikille siihen kirjautuneille käyttöliittymille.

AMRO-SQL-Server toteutetaan käyttämällä Outokummun sqlserver02-

kirjastoa.

Tietokannan käyttöliittymille joudutaan kirjoittamaan prosessi, joka kuuntelee

49

jatkuvasti, mitä pyyntöjä AMRO-SQL-Server lähettää. Tyypillisin näistä on

näkymien päivityspyyntö, mutta myös virheilmoitukset lähetetään samalla

tavalla. Virheilmoitukset menevät tyypistä riippuen yhdelle tai useammalle

käyttöliittymälle. Tietokanta ja sen käyttöliittymät toimivat ikään kuin client-

server-arkkitehtuurissa.

6.3 TOTEUTUS ILMAN MVC-ARKKITEHTUURIA

Online-versio voidaan toteuttaa myös ilman MVC-arkkitehtuuria. Kaavio tästä

vaihtoehdosta on liitteenä 6. Tässä arkkitehtuurissa käyttöliittymät päivittävät

itse tietojaan aina silloin, kun niitä tarvitaan. Käyttäjä ei kuitenkaan voi olla

varma, näkyykö näkymissä tietokannan todellinen sisältö vai onko se ehtinyt

muuttua. Hän voi kuitenkin päivittää näkymän halutessaan. Tämä arkkitehtuuri

on ongelmallinen poistojen ja muutosten yhteydessä, koska käyttäjä ei voi olla

varma, onko hänen valitsemaansa tietuetta jo muutettu tai onko sitä enää

olemassa. Tällaiset tilanteet johtavat helposti omituisiin virheilmoituksiin,

joissa todetaan esimerkiksi, ettei valittua tietuetta löydy.

Tämän toteutuksen etuna on se, ettei AMRO-SQL-Serveriä tarvita, eikä

suhteellisen monimutkaista client-server-kommunikointia tarvitse siis toteuttaa.

Jos tietokannalla on melko vähän käyttäjiä tai käyttäjät operoivat yleensä eri

tauluja, virhetilanteet ovat harvinaisia.

6.4 TIETOKANTA

Online-versiossa Paradox 7 vaihdetaan Informix-tietokantaan, joka on

Outokummun virallinen tietokanta. Koko tietokanta joudutaan luomaan alusta

lähtien. Mikäli Informix tukee SQL-skriptejä, voidaan tietokanta luoda liitteenä

2 olevalla skriptillä. Tähän tietokantaan lisätään ne tietokannan eheyden

säilyttämiseen tarvittavat rajoitukset, joita Paradox 7 ei tukenut (ks. kappale 4).

Riippumatta online-version arkkitehtuurivalinnasta käyttöliittymä joutuu

lukittamaan tietokannan taulun aina, kun se on muuttamassa sitä. Lukitettua

taulua ei voi muuttaa muista käyttöliittymistä. Tämä takaa sen, että useampi

käyttäjä ei voi muuttaa samaa tietuetta samaan aikaan. Mikäli tällainen tilanne

syntyy, käyttäjät joutuvat odottamaan, että edellinen lukitus vapautuu, ennen

kuin he voivat itse lukittaa taulun. Tämä voi hidastaa tietokannan käyttöä

merkittävästi.

50

Mikäli Outokummulla on tietokantatauluja, joiden käytöstä he eivät halua

luopua, on mahdollista, että ne halutaan integroida ohjelmistoon. Tämä voi olla

kuitenkin suhteellisen vaikeaa tai jopa mahdotonta, jos taulut eivät sisällä

kaikkea optimoinnin ja estimoinnin tarvitsemaa tietoa. Lisäksi, jos taulujen

rakenne ja hierarkia poikkeavat merkittävästi offline-versiossa olleesta,

joudutaan ohjelmisto kirjoittamaan paikoin kokonaan uudelleen. Erityisen

vaikeaa tämä on optimointi- ja estimointimoduulin kohdalla, jonka

muuttaminen vaatii käytettyjen algoritmien tuntemusta.

6.5 KÄYTTÖLIITTYMÄ

Jos online-versio toteutetaan MVC-arkkitehtuurilla, käyttöliittymään joudutaan

implementoimaan prosessi, joka vastaanottaa AMRO-SQL-Serveriltä viestejä –

erityisesti päivityspyyntöjä. Vanhasta päivitystoiminnallisuudesta säilytetään

näkymien Refresh-toiminto (ks. kappale 5.3.2), jolla käyttäjä voi halutessaan

varmistua siitä, että taulun tiedot ovat ajan tasalla. Lisäksi tietueita

muutettaessa täytyy huomioida, että kyseisen tietueen taulu voi olla lukitettuna.

Online-versioon siirryttäessä tietokannan taulujen rakenne saattaa muuttua.

Varsinkin, jos Outokummulla on olemassa jo valmiita tietokantatauluja, jotka

ovat olleet pitkään käytössä ja joihin he ovat tottuneet (ja joiden rakenne on

todennäköisesti aivan erilainen kuin offline-versiossa oleva), on mahdollista,

että näitä joudutaan käyttämään. Tällöin DBStrucuressa oleva tietokannan

rakenne (ks. kappale 5.4.2) joudutaan koodaamaan uudelleen.

6.6 OPTIMOINTI- JA ESTIMOINTIMODUULI

Optimointi- ja estimointimoduulin integrointi ei varsinaisesti kuulu tämän

erikoistyön piiriin, mutta muutamia yleisiä huomioita voidaan tehdä.

Optimointi- ja estimointimoduuli käyttää samaa rajapintaa (DBFunc)

tietokantaan päin kuin tietokannan käyttöliittymä, joten tietokantakutsuja ei

tarvitse uudelleenkirjoittaa kuin kertaalleen.

Optimointi- ja estimointimoduuli ja sen käyttöliittymä on muokattava

toimimaan MVC-arkkitehtuurissa. Itse moduuli operoi tietokantaa AMRO-

SQL-Serverin kautta. Tarvittavat taulut – joita on paljon – on joka tapauksessa

51

lukitettava optimoinnin ja estimoinnin ajaksi, jotta tiedot eivät muuttuisi kesken

prosessia. Optimointi- ja estimointimoduulin käyttöliittymään on joko tehtävä

samat MVC-arkkitehtuurimuutokset kuin tietokannan käyttöliittymään tai sen

on lukitettava tarvitsemansa taulut käynnistyessään. Jälkimmäinen tapa on

kömpelömpi mutta helpompi toteuttaa.

Tietokannan lukittumisen takia online-versiossa optimoiminen ja estimoiminen

on syytä toteuttaa silloin, kun tietokantaa ei muuteta, esimerkiksi iltaisin tai

öisin. Mikäli tällaiseen ei haluta ryhtyä, niin tietokanta voidaan kopioida

optimointia ja estimointia varten. Tällöin alkuperäistä tietokantaa ei tarvitsisi

lukita.

52

7. YHTEENVETO JA POHDINNAT

Outokumpu Polarit AMRO-projektin pääasiallisen haasteen muodostaa jatkossa

offline-version integroiminen osaksi Outokummun tietojärjestelmiä. Projektin

toisen vaiheen riskit voidaan jakaa viiteen luokkaan: tietokantaan, tietokannan

käyttöliittymään, optimointi- ja estimointimoduuliin, arkkitehtuuriin sekä

projektin hallintaan liittyviin riskeihin. Tietokantaan liittyvän riskin muodostaa

erityisesti Outokummun käytössä olevan tietokannan rakenne, joka saattaa

poiketa ennakoidusta. Lisäksi kovarianssimatriisien talletusongelma vaatii

pikaista ratkaisua. Tietokannan käyttöliittymään kohdistuu riskejä

toiminnallisuuden riittävyyden osalta. Optimointi- ja estimointimoduulin

riskejä ei ole tarkemmin kartoitettu, sillä ne eivät varsinaisesti kuulu tämän

erikoistyön piiriin. Arkkitehtuurin tulevana haasteena on monen käyttäjän

MVC-arkkitehtuurin onnistunut toteuttaminen. Projektin hallinnollisista

riskeistä vakavin on projektin henkilöstön voimakas vaihtuvuus, joka hidastaa

projektin etenemistä, kun uudet työntekijät joudutaan tutustuttamaan aiemmin

tehtyihin asioihin.

Katsomme, että offline-version tietokanta ja sen käyttöliittymä suoriutuvat

tehtävistään mainiosti. Lisäksi ohjelmiston MVC-arkkitehtuuri, tietokannan

joustavuus ja käyttöliittymän oliopohjaisuus ovat periaatteita, joiden pohjalta

jatkokehityksen tulisi olla helppoa ja vaivatonta. Uskommekin, että online-

version riskit voidaan välttää asianmukaisella riskien ja projektin hallinnalla.

53

Lähdeteokset

Gustafsson, Janne, Gustafsson, Tommi, Saarinen, Mikko (1999). Terästehtaan sulatusten optimointi, Tik-76.143 Tietojenhallintajärjestelmät, harjoitustyö, TKK.

Haapalinna, Ville, Tolvanen, Tuomas (1998). Valokaariuunin panostuksen simulointi. Case: OutokumpuPolarit Oy, Tornio. Mat-2.170 Simulointi, 3. harjoitustyö, Systeemianalyysin laboratorio, TKK.

Haikala, Ilkka, Märijärvi, Jukka (1998). Ohjelmistotuotanto, Suomen ATK-kustannus.

Ikäheimo, Jussi (1999): Adaptive raw material charge optimization system for a steel plant,Systeemianalyysin laboratorio, TKK.

Kuronen, Tommi (1998). AMRO-vaatimusmäärittely, Outokumpu Polarit.

Lahdelma, Risto, Hakonen, Henri, Ikäheimo, Jussi (1999). AMRO - Adaptive Metallurgical Raw MaterialOptimization.

Outokumpu Polarit (1995). 9113 ROPI-II Keskitetty ohjelmistohälytysten, käyttöhäiriöiden jasovellusnotifikaatioiden hallinta: Toiminnalliset vaatimukset.

Outokumpu Polarit (1998). SUTI / 9113 ROPI-II, The Connect to the Dynamic Database Server: FunctionalDefinitions.

Ullman, Jeffrey D., Widom, Jennifer (1997). A First Course in Database Systems, International Edition,Prentice-Hall.

WWW-osoitteita

http://www.outokumpu.com/