Johdanto ● Kiinteistöhuoltoyhtiö tarvitsee järjestelmän huoltopyyntöjen hallinnointiin ● Asiakas voi tehdä huoltopyynnön lähettämällä kirjeen tai sähköpostin?

Esitys aiheesta: "Johdanto ● Kiinteistöhuoltoyhtiö tarvitsee järjestelmän huoltopyyntöjen hallinnointiin ● Asiakas voi tehdä huoltopyynnön lähettämällä kirjeen tai sähköpostin?"— Esityksen transkriptio:

1 Johdanto ● Kiinteistöhuoltoyhtiö tarvitsee järjestelmän huoltopyyntöjen hallinnointiin ● Asiakas voi tehdä huoltopyynnön lähettämällä kirjeen tai sähköpostin? ● Asiakas voi tehdä huoltopyynnön soittamalla puhelinvastaajaan?

2 Johdanto ● Ongelma: Vapaamuotoisen tiedon (esimerkiksi puhe, teksti tai kuva) koneellinen käsittely vaikeaa ● Sisältö on jäsentämätöntä – Jotain säännönmukaisuuksia esiintyy (merkistö, tiedoston tallennusformaatti...) ● Voidaan säilyttää kokonaisuutena

3 Johdanto ● Kiinteistöhuoltoyhtiö tarvitsee järjestelmän huoltopyyntöjen hallinnointiin ● Asiakas voi täyttää lomakkeen netissä? ● Asiakas voi soittaa huoltoyhtiössä olevalle toimistotyöntekijälle joka kirjaa huoltopyynnöt? – ja kysyy tarvittavat tiedot.

4 Johdanto ● Jos tiedetään tarvittu data eli tieto, (esimerkiksi asiakkaan nimi, kohteen sijainti, asiakkaan yhteystiedot), voidaan se säilöä jäsenneltynä ● Tiedolle voidaan määritellä rakenne ● Koneellinen käsittely helppoa ● On mahdollista hakea vain tiettyä kenttää, eli tiedon osiin pääsee käsiksi helpommin kuin jäsentämättömässä datassa (esimerkiksi yhteystietojen hakeminen)

5 Tiedon säilöminen ● Ratkaisu: Säilötään järjestelmän tiedot ohjelman sisäisiin tietorakenteisiin ● Esim. Lista-rakenne Huoltopyynto-olioita ● Huoltopyynto-luokka määrittelee tiedot, joita huoltopyyntö-oliolla on (esim asiakas, asiakkaan puhelinnumero, kohde,...)

6 Tiedon säilöminen ● Ratkaisu: Säilötään järjestelmän tiedot ohjelman sisäisiin tietorakenteisiin ● Ongelma: tietorakenteet käytettävissä vain kun ohjelmaa suoritetaan – Tiedot menetetään kun ohjelman suoritus päättyy ● voi tapahtua sekä kontrolloidusti että kontrolloimattomasti – Käyttäjä sulkee ohjelman – Ohjelma kaatuu –... ● Ratkaisu?

7 Tiedon säilöminen ● Tieto tulee tallentaa pysyväismuistiin (tiedosto kiintolevyllä, ssd-levyllä, usb-tikulla...) ● Mahdollisuus tallentaa olioita suoraan levylle sarjallistamalla (Java: rajapinta Serializable) ● Kiinteistöhuoltoyhtiö toivoo että tietoa pystyy käsittelemään tulevaisuudessa muillakin ohjelmilla ● Tallennusmuodon tulee olla toteutuksesta eli ohjelmasta riippumaton ● Tallennetaan tiedostoon jolla määritelty rakenne

8 Tiedoston rakenne ● CSV-muoto (comma-separated values) ● Tekstitiedosto, tietoon liittyvät kentät erotettu toisistaan pilkuilla ● Jokaisella rivillä oma tietue (olio, instanssi,...) – Ensimmäinen rivi voi usein otsikkorivi jossa kenttien selitykset – Jos kentässä on erikoismerkkejä, kenttä ympäröidään lainausmerkeillä

9 Tiedoston rakenne ● CSV-muoto (comma-separated values) ● Otsikkorivi ja kaksi huoltopyyntöä: asiakas, kohde, ongelma arto, exactum, tulostinpaperi loppunut luokassa B221 arto, exactum, CK112 ilmastointilaite jäätävän tehokas ● CSV-formaatti sopii hyvin taulukkomuotoisen tiedon tallentamiseen ● Entä jos asiakas haluaa lisätä useita kohteita? – Klassinen CSV-ratkaisu: kohteet eritelty välilyönneillä tai muilla erikoismerkeillä ● Onko tiedostomuoto tällöin toteutuksesta riippumaton?

10 Tiedoston rakenne ● XML-muoto (extensible markup language) ● Tekstitiedosto, tiedon merkitys kuvataan tiedon kanssa ● Paljon käytetty, mm. järjestelmien välisenä tiedonsiirtoformaattina ● XML-dokumentti alkaa otsakkeella (prologi, header,...), joka sisältää XML-version ●

11 Tiedoston rakenne ● XML-muoto (extensible markup language) ● Otsakkeen jälkeen alkaa data ● Data koostuu elementeistä – Elementit kuvaavat rakennetta ja niillä on alku- ja lopputagi (, ) – Elementtien attribuutit ja sisäiset tekstikentät kuvaavat tietoa ● teksti

12 Tiedoston rakenne ● XML-muoto (extensible markup language) ● Elementtejä voi olla rajattomasti sisäkkäin, tekstikenttiä yleensä vain sisimmällä tasolla ● teksti ● XML on puumainen rakentenne – Ensimmäinen elementti on juurielementti, jonka sisällä oksat – viimeinen, sisin taso, sisältää lehdet

13 Tiedoston rakenne ● XML-muoto (extensible markup language) ● Hyvin muodostettu (well-formed) XML-dokumentti täyttää seuraavat säännöt – Dokumentissa on tasan yksi juurielementti – Elementeillä on sekä alku- että loppumerkki (tyhjät elementit poikkeustapaus: ) – Jokainen attribuutti on lainausmerkkien sisällä – Elementit voivat olla sisäkkäisiä, mutta ne eivät saa mennä ristiin toisten elementtien kanssa. EI: arvo

14 Tiedoston rakenne ● Huoltoyhtiön huoltopyynnot, esimerkiksi: arto exactum tulostinpaperi loppunut luokassa B221 arto exactum CK112 ilmastointilaite jäätävän tehokas ● Onko ylläoleva XML-dokumentti hyvin muodostettu?

15 Tiedoston rakenne ● Ei ole. Dokumentissa pitää olla tasan yksi juurielementti, edellisessä on kaksi. Korjataan... arto exactum tulostinpaperi loppunut luokassa B221 arto exactum CK112 ilmastointilaite jäätävän tehokas

16 Tiedoston rakenne arto exactum tulostinpaperi loppunut luokassa B221 arto exactum CK112 ilmastointilaite jäätävän tehokas ● Huomaa myös kuvaava elementtien nimentä.

17 Tiedoston rakenne ● Toisen kohteen lisääminen? arto exactum physicum tulostinpaperi loppunut luokassa B221...

18 Tiedoston rakenne ● Toisen kohteen lisääminen? arto exactum physicum tulostinpaperi loppunut luokassa B221...

19 Tiedoston rakenne ● Entä jos halutaan tallentaa kohteet erikseen? ● Eräs ratkaisu: kaksi XML-dokumenttia – toisessa huoltopyynnöt, toisessa kohteet – kohde tunnistetaan huoltopyynnöissä tunnuksen perusteella ● Huoltopyynnössä viite kohteeseen

20 Tiedoston rakenne ● Tiedosto 1: Huoltopyynnöt ● arto 1...... ● Tiedosto 2: Kohteet ● 1 exactum......

21 Tiedoston rakenne ● Ongelmia XML-formaatissa? ● Elementit vievät paljon tilaa (huoltopyyntö-esimerkissä vain noin 30% XML-dokumentista oleellista informaatiota) ● Lukeminen hidasta – täytyy lukea koko tiedosto jotta tiedetään mitä se sisältää ● XML-standardia tukevat ohjelmakirjastot eivät ole täydellisiä – yhteensopivuusongelmat muiden kirjastojen kanssa ● Muita ratkaisuja rakenteellisen tiedon esittämiseen: JSON

22 Johdanto ● Kiinteistöyhtiö kiittää järjestelmästä.

23 Johdanto ● Ja palaa takaisin muutaman kuukauden kuluttua: ● “Ohjelma tekee koneesta hitaan. Meillä on nyt kymmeniä ellei satoja tuhansia huoltopyyntöjä. Kun ohjelma on päällä kone hidastuu huomattavasti. Tarvitsemme konetta myös muuhun, joten käynnistämme ohjelman vain tarpeen vaatiessa.” ● Ongelma: – Kun ohjelma on päällä, tiedostot on ladattu keskusmuistiin joka ilmeisesti loppuu kesken – Ratkaisu?

24 Johdanto ● Järjestelmää muutetaan siten, että se lukee tiedostoa kovalevyltä vain kun on tarve. Kiinteistöhuoltoyritys: ● “Tietojen hakeminen ja lisääminen on liian hidasta. Ohjelma ei toimi!” ● Ongelma: – Pysyväismuistista lukeminen on huomattavasti hitaampaa kuin keskusmuistista lukeminen – tässä tapauksessa liian hidasta – Ratkaisu?

25 Johdanto ● Kaikkea ei voida pitää muistissa, mutta tiedoston lukeminen levyltä on hidasta ● Tiedostoon perustuvassa ratkaisussa muitakin ongelmia: – Mitä käy jos useampi ohjelma kirjoittaa samaan tiedostoon samaan aikaan? – Ohjelmat yhä riippuvaisia tiedoston määrittelystä – jos tiedostomuoto muuttuu, täytyy ohjelmaa muuttaa ● Tarvitaan välimuoto, jonka avulla voidaan käyttää vain osaa tiedosta kerrallaan

26 Johdanto ● Luodaan erillinen ohjelma, joka hallinnoi tietoa ● Ohjelma pitää yllä tietorakenteita, jotka mahdollistavat nopean levyltä hakemisen ● Muistissa pidetään vain hakua helpottavia tietorakenteita, itse data on tallennettuna levylle – Useampia tietorakenteita joista kukin mahdollistaa tietyt hakuoperaatiot (kriteereihin perustuvat haut) ● Haku aikavälin perusteella ● Haku asiakkaan perusteella ● Haku kohteen perusteella ●...

27 Johdanto ● Luodaan erillinen ohjelma, joka hallinnoi tietoa ● Mahdollistaa tiedon käytön useamman ohjelman toimesta samanaikaisesti – Jos tietuetta muokataan, ohjelma lukitsee tietueen vain muutoshetkeksi – Tarjoaa erilaisia näkymiä tiedosta ohjelmille ● Hallinnointiohjelma näkee eri tiedot kuin vikailmoitusohjelma ● Tietoa käyttävillä ohjelmilla voi olla erilainen käsitys tiedon rakenteesta ● Varmuuskopiointi: – Käyttöhistoria ● Mahdollisuus tietoturvaan ja käyttäjien hallintaan

28 Johdanto ● Keksittiin pyörä uudestaan ● Tietokannanhallintajärjestelmät on luotu juuri tarvettamme varten

29 Tietokanta (Database) ● Tietokanta muodostuu kokoelmasta toisiinsa liittyviä säilytettäviä tietoja ● Rakenne suunnitellaan yleensä tiettyä käyttötarkoitusta varten (asiakasrekisterit, pankkijärjestelmät, puhelinluettelot, kurssikirjanpidot,...)

30 Tietokannanhallintajärjestelmä ● Toimii rajapintana tietokannan ja sovellusohjelmien välillä ● Tarjoaa palveluita tietokannan käsittelyyn ● Suorakäyttöliittymät – Kyselyiden ajaminen tietokannassa ● Hallintaliittymät – Tietokannan rakenteiden muokkaus, käyttöoikeudet, tietokannan asetukset ● Ohjelmointirajapinnat – Mahdollistavat tietokannan käytön sovellusten kautta

31 Tietokantajärjestelmä ● Sisältää ● Tietokannan ● Tietokannanhallintajärjestelmän ● Tietokantaa käyttäviä sovellusohjelmia

32 Tietomalli ● Tietomallilla (data model) tarkoitetaan tiedon rakenteen ja tiedolle suoritettavan käsittelyn määrittelevää käsitteistöä ● Tietoa voidaan tutkia eri näkökulmista, eri abstraktiotasoilla ● Tavoitteena jakaa tiedon kuvaaminen ja määrittely osiin, “hajoita ja hallitse”, ja tätä kautta yksinkertaistaa tietokuvauksia ● Tarvitaan useampia -- eri abstraktiotasojen -- kuvauksia

33 Abstraktiotasot ● Tietoa mallinnettaessa tieto jaetaan perinteisesti kolmeen tasoon ● Käsitetaso (conceptual level) ● Rakennetaso (structural level, logical level) ● Talletustaso (physical level, storage level)

34 Käsitetaso ● Ohjelmistosta riippumaton kuvaus tiedosta ● “Järjestelmässä on tietoa kiinteistöjen laitteistoista, huoltotapahtumista ja huoltohenkilökunnasta. Laitteistoista tallennetaan merkki, ostovuosi, ja sijainti. Huoltohenkilökunnasta tallennetaan nimi, puhelinnumero, aloitusvuosi, lopetusvuosi. Huoltotapahtumat liittyvät aina laitteeseen ja ne suoritetaan tietyn huoltohenkilön toimesta.”

35 Käsitetaso ● Ohjelmistosta riippumaton kuvaus tiedosta ● Miten tiedot liittyvät yhteen ● Mitä sääntöjä tietoihin liittyy (esim huoltotapahtumassa pitää olla aina tapahtuman suorittaja) ● Mitä tietoja käsitellään – Millainen on se kohde, jota tiedoilla pitäisi kuvata – Asiat, joita pitäisi esittää – Minkälaisia arvoja tiedon elementit voivat saada, ja mitä arvot tarkoittavat

36 Rakennetaso ● Minkälaisia käsiteltäviä rakenteita tiedot muodostavat ● Esim ohjelmointikielen näkemys tiedosta ● Tietokannan rakenne ● … ● Minkälaisina rakenteina ohjelmoijat näkevät tiedot

37 Rakennetaso ● Laite ● Merkki ● Ostovuosi ● Sijainti ● Huotohenkilö ● Nimi ● Puhelinnumero ● Aloitusvuosi ● Lopetusvuosi ● Huoltotapahtuma ● Laite ● Huoltohenkilö ● Kuvaus

38 Rakennetaso ● Tietokantataulut ● Laite (id, merkki, ostovuosi, sijainti) ● Huotohenkilö (id, nimi, puhelinnumero, aloitusvuosi,...) ● Huoltotapahtuma (laite id, henkilö id, kuvaus)

39 Talletustaso ● Fyysinen kuvaus tiedosta levyllä ● Tiedosto laitteet.xml levyllä /fs/, toteuttaa määritelmän...

40 Abstraktiotasot tiedon käsittelyssä ● Käsitetaso ● Tietosisällön suunnittelu ● Rakennetaso ● Ohjelmointi, rajapinnat, kyselyt ● Talletustaso ● Tallennustapa, tehokkuus, hajauttaminen useille levypalvelimille

41 Mitä malleja eri abstraktiotasoilla? ● Käsitetaso ● Oliomallit (UML) ● ER-mallit (Entity-Relationship) ● Semanttiset tietomallit (RDF) ● Rakennetaso ● Relaatiomalli, Oliomallit, XML,... ● Talletustaso ● Toimittaja- ja laitekohtaiset käsitteet