TEEMU IMMONEN VERKKOPALVELUN TIETOMALLI JA INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA KETTERÄSSÄ OHJELMISTOPROJEKTISSA. Diplomityö

Koko: px
Aloita esitys sivulta:

Download "TEEMU IMMONEN VERKKOPALVELUN TIETOMALLI JA INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA KETTERÄSSÄ OHJELMISTOPROJEKTISSA. Diplomityö"

Transkriptio

1 TEEMU IMMONEN VERKKOPALVELUN TIETOMALLI JA INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA KETTERÄSSÄ OHJELMISTOPROJEKTISSA Diplomityö Tarkastajat: Erikoistutkija Ossi Nykänen (TTY) Professori Seppo Pohjolainen (TTY) Tarkastajat ja aihe hyväksytty Tietotekniikan osastoneuvoston kokouksessa 20. elokuuta 2007

2 II TIIVISTELMÄ TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Hypermedia IMMONEN, TEEMU: Verkkopalvelun tietomalli ja informaatiosisällön säilyvyydenhallinta ketterässä ohjelmistoprojektissa Diplomityö, 75 sivua, 1 liitesivu Kesäkuu 2008 Tarkastajat: erikoistutkija Ossi Nykänen, professori Seppo Pohjolainen Avainsanat: tietomalli, informaatiosisältö, informaation mallintaminen, säilyvyys, säilyvyydenhallinta, tietokanta, ORM, mukautuva verkkopalvelu, ketterä ohjelmistokehitys, sovelluskehys Sovelluksen tietomallin määrittely ja suunnittelu ovat keskeinen osa nykyaikaista ohjelmistokehitysprosessia. Tietomallilla on tärkeä rooli myös sovelluksen koko arkkitehtuurin kannalta ja se mahdollistaa muun muassa sovelluksen informaatiosisällön säilyvyydenhallinnan toteuttamisen. Hyvin suunniteltu ja selkeä tietomalli mahdollistaa omalta osaltaan myös suoraviivaisen ja helposti ylläpidettävän sovelluslogiikan suunnittelun ja toteuttamisen. Tässä työssä perehdytään informaatiosisällön mallintamisen peruskäsitteisiin ja esitellään tietomallin määrittely- ja suunnitteluprosessi sekä informaatiosisällön säilyvyydenhallinta osana koko sovelluksen kehitysprosessia. Työssä esitellään kolme vaihtoehtoista teknologiaa informaatiosisällön säilyvyydenhallinnan toteuttamiseksi sekä arvioidaan niiden vahvuuksia ja heikkouksia tuotekehitysprosessin näkökulmasta. Lisäksi perehdytään Web-sovelluskehyksiin, missä yhteydessä niitä arvioidaan muun muassa niiden tuotekehitysprosessille tuomien etujen ja rajoituksien näkökulmasta. Työn konkreettisena tehtävänä on suunnitella ja toteuttaa Aatu-verkkopalvelun tietomalli ja informaatiosisällön säilyvyydenhallinta valituilla toteutusteknologioilla sekä arvioida teknologiavalintojen soveltuvuutta osana ketterää ohjelmistoprojektia. Kirjoitetun dokumentin lisäksi työn tuloksena syntyy Aatu-verkkopalvelun tietomalli ja informaatiosisällön säilyvyydenhallinnan toteutus. Työ osoittaa, että tietomallin ja säilyvyydenhallinnan suunnittelu sekä toteutus ORM-teknologiaa käyttäen, on parhaimmillaan hyvin suoraviivaista, joustavaa ja tuottavaa tuotekehitysprosessin näkökulmasta. Näin ollen valitut toteutusteknologiat sopivat hyvin myös ketterään ohjelmistokehitykseen. Työ osoittaa myös sen, että vaikka käytetyt teknologiat ja menetelmät mahdollistaisivat tietomallin ketterän suunnittelun, niin tietomalli tulisi silti suunnitella pääpiirteiltään mahdollisimman valmiiksi hyvin aikaisessa vaiheessa kehitysprosessia.

3 III ABSTRACT TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Hypermedia IMMONEN, TEEMU: Web Service s Data Model and Information Persistence Management in Agile Software Project Master of Science Thesis, 75 pages, 1 Appendix page June 2008 Examiners: Senior Researcher Ossi Nykänen, Professor Seppo Pohjolainen Keywords: data model, data modeling, information modeling, persistence, persistence management, database, ORM, agile software development, iterative software development, application framework, adaptive web service Defining and designing of application s data model is an essential part of modern software development process. Data model has an important role in application s overall architecture as well and it for instance enables persistence management for application s information content. Well designed and clear data model also enables designing and implementation of straightforward and easily maintainable application logic. This thesis familiarizes oneself with basic concepts of information modeling and represents the design process of data model and information persistence management as a part of application s overall development process. Thesis represents three alternative technologies for information persistence management and evaluates their assets and weaknesses from the software development process s perspective. Web-frameworks are also briefly introduced and evaluated on the grounds of what benefits and restrictions they may bring into software development process. The concrete objective of this thesis is to design and implement the data model and information persistence management for Aatu web service with the chosen technologies and to evaluate technology selections as a part of an agile software project. As a result of this thesis, data model and information persistence management of Aatu web service are designed and implemented. Thesis indicates that data model design and information persistence management using ORM-technology are, in best cases, very straightforward, flexible and productive from the software development process s point of view. Consequently, the chosen technologies are suitable for agile software development. Study shows, on the other hand, that despite the fact that technologies and methods allows the agile design of data model, it should still be designed as ready as possible in the very early phases of the development process.

4 IV ALKUSANAT Diplomityöni on tehty Raha-automaattiyhdistyksen rahoittamassa Aatu-projektissa Tampereen teknillisen yliopiston Hypermedialaboratoriossa osa-aikaisena tutkimusapulaisena. Haluan kiittää Hypermedialaboratoriota mahdollisuudesta työskennellä erittäin mielenkiintoisessa Aatu-projektissa sekä lisäksi hyvin joustaneista työaikajärjestelyistä ja rennosta työilmapiiristä, jotka omalta osaltaan edesauttoivat tämän työn valmistumista varsinaisen päivätyöni ohessa. Esitän erityisen kiitokseni työn ohjaajana ja tarkastajana toimineelle erikoistutkija Ossi Nykäselle työn sisältöön sekä rakenteeseen liittyvistä parannusehdotuksista ja kommenteista. Kiitän myös työn toista tarkastajaa professori Seppo Pohjolaista ja tutkija Jukka Huhtamäkeä hyvistä kommenteista työhön liittyen. Lopuksi haluan kiittää Aatu-projektin kehitysryhmän jäseniä tasapuolisesti mukavasta projektityöilmapiiristä sekä tuesta tämän työn tekemisen aikana. Tampereella Teemu Immonen Sommerinkatu 9 A Tampere

5 V SISÄLTÖ Tiivistelmä... II Abstract...III Alkusanat...IV Lyhenteet ja merkinnät... VII 1. Johdanto Informaatiosisällön mallintaminen osana sovelluksen suunnittelua Verkkopalvelun pysyvä informaatiosisältö Tietomallin määrittely- ja suunnitteluprosessi Ohjelmistotuotannon tiedonmallintamismenetelmiä ER-malli UML-malli Informaatiosisällön säilyvyydenhallinta Tietokannat Relaatiomalli Periaate Informaation eheys ja relaatiotietokantaoperaatiot Relaatiomalli tuotekehityksen näkökulmasta Oliotietomalli Periaate Edut tuotekehityksen näkökulmasta Rajoituksia ja haasteita ORM (Object Relational Mapping) Periaate ORM-sovelluskehystyypeistä ORM-sovelluskehysten yleisiä eroja Edut tuotekehityksen näkökulmasta Rajoituksia ja haasteita Teknologiavaihtoehtojen arviointi tuotekehityksen näkökulmasta Sovelluskehyksistä Sovelluskehykset ja verkkopalvelut MVC-malli Web-sovelluskehykset Django Säilyvyydenhallinta ja luokkien väliset yhteydet One-to-many yhteydet Many-to-many yhteydet Mallien perintä ja one-to-one yhteydet MVC-mallin toteutus Sovelluskehysten arviointi tuotekehityksen näkökulmasta Tietomalli ja säilyvyydenhallinta AATU-Projektissa...55

6 5.1. Sovelluksen kehitysprosessi Ketterä ohjelmistokehitys Ketterien menetelmien soveltaminen AATU-projektissa Odotukset teknologiavalinnoilta kehitysprosessin näkökulmasta Tietomallin ja säilyvyydenhallinnan suunnittelu Suunnittelun tulokset ja toteutus Tietosisällön hallinnointi osana kehitysprosessia Suunnittelun ja toteutuksen tulosten arviointi Jatkokehitysideat Yhteenveto...72 Lähteet...74 Liite 1: Aatu-verkkopalvelun tietomalli UML-luokkakaaviona...76 VI

7 VII LYHENTEET JA MERKINNÄT TTY ER UML CSV SQL ORM DBMS RDBMS OODM OID OODBMS OQL EJB-QL HQL JDOQL ORDBMS MVC GUI URL XML XPath XP DSDM Tampereen teknillinen yliopisto Entity Relationship Unified Modeling Language Comma Separated Values Structured Query Language Object Relational Mapping Database Management System Relational Database Management System Object Oriented Data Model Object Identifier Object Oriented Database Management System Object Query Language Enterprise Java Bean Query Language Hibernate Query Language Java Data Object Query Language Object Relational Database Management System Model View Controller Graphical User Interface Uniform Resource Locator Extensible Markup Language XML Path Language Extreme Programming Dynamic Systems Development Model

8 1 1. JOHDANTO Sovelluksen tietomallin (data model) määrittely ja suunnittelu ovat keskeinen osa lähes jokaisen nykyaikaisen ohjelmiston kehitysprosessia. Tietomallilla tarkoitetaan tiedon rakenteen määrittelevää kehikkoa ja käsitteistöä [1]. Tässä työssä tietomalli kuvaa sen, minkälaisista rakenteellisista alkioista sovelluksen tai verkkopalvelun käsittelemä informaatio (informaatiosisältö) koostuu ja minkälaisia riippuvuuksia eri tietoalkioiden välillä sovelluksen näkökulmasta on. Tietomalli määrittelee siis sovelluksen informaatiosisällön käsitteistön eli käytännössä sen, mitä ja minkälaista tietoa sovellus käsittelee. Kuvitteellisen verkkokaupan informaatiosisältöä kuvaava tietomalli voisi sisältää esimerkiksi seuraavia tietoalkiota: käyttäjä, tuote, mainos ja ostoskori. Tietomallilla on tärkeä rooli sovelluksen koko arkkitehtuurin kannalta. Tietomalli mahdollistaa muun muassa sovelluksen informaatiosisällön säilyvyydenhallinnan, jolla tarkoitetaan sovelluksen käsittelemien tietojen tallentamista pysyvästi sovelluksen eri käyttökertojen välillä. Säilyvyydenhallinnan toteuttaminen edellyttää siis käytännössä, että tallennettavaksi tarkoitettu informaatiosisältö on ensin mallinnettu jollakin menetelmällä eli sovelluksen tietomalli on olemassa. Esimerkiksi tietokannan käsitteistön ja taulujen rakenteen suunnittelu ei olisi käytännössä mahdollista ilman tietomallia. Hyvin suunniteltu ja selkeä tietomalli mahdollistaa myös suoraviivaisen ja helposti ylläpidettävän sovelluslogiikan sekä käyttöliittymän suunnittelun ja toteuttamisen. Tietomallin keskeisen roolin vuoksi se tulisi suunnitella mahdollisimman aikaisessa vaiheessa kehitysprojektia. Tietomalli saattaa olla lopulta kohtalaisen pieni osa monimutkaista tietojärjestelmää, mutta muutokset siihen voivat tulla hyvin kalliiksi. Pienikin muutos tietomalliin saattaa aiheuttaa suuria muutoksia sovellukseen kokonaisuutena, ja niillä puolestaan voi olla hyvin epäedullisia vaikutuksia projektin aikatauluihin ja kustannuksiin. Tämän työn tarkoitus on perehtyä informaatiosisällön mallintamisen peruskäsitteisiin ja esitellä tietomallin määrittely- ja suunnitteluprosessi sekä informaatiosisällön säilyvyydenhallinnan toteuttaminen osana koko sovelluksen kehitysprosessia. Työssä esitellään kolme vaihtoehtoista teknologiaa informaatiosisällön säilyvyydenhallinnan toteuttamiseksi sekä arvioidaan niiden vahvuuksia ja heikkouksia tuotekehitysprosessin näkökulmasta. Lisäksi perehdytään Web-sovelluskehyksiin, missä yhteydessä esitellään muun muassa työn käytännön osuudessa käytetyt toteutusteknologiat sekä arvioidaan sovelluskehyksiä niiden tuotekehitysprosessille tuomien etujen ja rajoituksien näkökulmasta. Työn konkreettisena tehtävänä on suunnitella ja toteuttaa Aatu-

9 2 verkkopalvelun tietomalli sekä informaatiosisällön säilyvyydenhallinta valituilla toteutusteknologioilla sekä arvioida teknologiavalintojen soveltuvuutta osana ketterää ohjelmistoprojektia. Verkkopalvelulla tarkoitetaan tässä työssä Internetin välityksellä toimivaa sovellusta tai järjestelmää. Ketterällä ohjelmistoprojektilla tarkoitetaan tässä yhteydessä puolestaan ohjelmistoprojektia, joka soveltaa niin sanottuja ketteriä ohjelmistokehityksen menetelmiä. Ketterät menetelmät esitellään tässä työssä tarkemmin myöhemmin. Työn ensimmäinen luku määrittelee työn aihealueen kannalta keskeisiä käsitteitä sekä kuvaa työlle asetettavat yleiset tavoitteet. Toisessa luvussa perehdytään sovelluksen informaatiosisällön mallintamisen peruskäsitteisiin sekä kuvataan tietomallin määrittely- ja suunnitteluprosessi osana sovelluksen koko suunnitteluprosessia. Lisäksi esitellään ohjelmistotuotannon tarjoamia tiedonmallintamismenetelmiä tietomallin käytännön suunnittelutyön tueksi. Kolmas luku keskittyy informaatiosisällön säilyvyydenhallintaan. Luvussa esitellään kolme vaihtoehtoista teknologiaa sovelluksen informaatiosisällön pysyvään tallentamiseen sekä arvioidaan kunkin vaihtoehdon vahvuuksia ja heikkouksia tuotekehitysprosessin näkökulmasta. Neljännessä luvussa kuvataan sovelluskehyksien yleisiä periaatteita sekä arvioidaan sovelluskehyksien käytön vaikutuksia tuotekehitysprosessille. Luvussa esitellään myös tässä työssä käytetty sovelluskehys soveltuvin osin. Viides luku keskittyy tapausesimerkkinä käytetyn Aatu-verkkopalvelun tietomallin ja säilyvyydenhallinnan suunnittelun ja toteutuksen käsittelyyn sekä työn tulosten arviointiin. Luvussa esitellään lyhyesti myös Aatu-projektin taustat ja tarkoitus sekä se, kuinka tämä työ liittyy kyseiseen projektiin. Lisäksi luvussa perehdytään ketterän ohjelmistokehityksen perusperiaatteisiin sekä niiden soveltamiseen Aatu-projektissa. Kuudennessa ja viimeisessä luvussa on työn yhteenveto, joka tiivistää ja kertaa lyhyesti työn keskeisen sisällön sekä tulokset.

10 3 2. INFORMAATIOSISÄLLÖN MALLINTAMINEN OSANA SOVELLUKSEN SUUNNITTELUA Nykyaikaisen verkkopalvelun tekninen määrittely, suunnittelu ja toteutus muistuttavat hyvin paljon perinteistä ohjelmistotuotantoa eri vaiheineen. Verkkopalvelun tekninen toteutusprojekti onkin käytännössä monesti kuin perinteinen ohjelmistoprojekti, jonka lopputuloksena syntyy jokin tuotteeksi miellettävä kokonaisuus. Näin ollen verkkopalveluiden kehitykseen soveltuvat myös monet perinteisen ohjelmistokehityksen suunnittelu- ja toteutusmenetelmät. Verkkopalveluiden suunnittelu eroaa kuitenkin jossakin määrin perinteisten ohjelmistojen suunnittelusta muun muassa sisällöntuotannon osalta. Verkkopalveluiden yhteydessä palvelun sisältö voi esimerkiksi tulla kokonaan tai osittain ulkopuolisilta sisällöntuottajilta, kuten uutispalveluiden uutiset niitä tuottavilta toimittajilta. Perinteisten ohjelmistojen tapauksessa täysin ulkopuolinen sisällöntuotanto on hieman harvinaisempaa, sillä monesti ohjelmistojen sisältö on miellettävissä kiinteäksi osaksi tuotteita itseään, jota ei ole mahdollista päivittää kuten verkkopalveluiden sisältöä tai sisältöä ei ole ollenkaan sen varsinaisessa merkityksessä. Ohjelmistoja saatetaankin käyttää monesti varsinaisen sisällön tuottamiseen, kuten tekstinkäsittelyohjelmia tekstin tuottamiseen tai piirto-ohjelmia kuvien piirtämiseen sekä käsittelyyn. Verkkopalveluiden sisällöntuotanto on melko laaja ja itsenäinen kokonaisuus, joka on luonteva erottaa verkkopalveluiden teknisestä määrittelystä ja suunnittelusta omaksi osaprojektikseen, joten siihen ei tässä yhteydessä keskitytä tämän tarkemmin, vaan verkkopalveluiden suunnitteluprosessia tarkastellaan jatkossa puhtaasti toteutusteknisestä näkökulmasta. Todetaan kuitenkin, että verkkopalveluiden ja perinteisten ohjelmistojen tekninen suunnittelu ja toteutus on hyvin samankaltaista, vaikka erojakin muun muassa edellä mainitun sisällöntuotannon alueelta on löydettävissä. Sisällöntuotantoa käsitellään myöhemmin toteutettavaa verkkopalvelua käsittelevässä luvussa. Verkkopalvelun teknisen suunnittelun ja toteutuksen vaiheisiin kuuluvat muun muassa palvelun tekninen määrittely, suunnittelumenetelmien valinta, tekninen suunnittelu sekä varsinainen toteutustyö valituilla teknologioilla. Yksi keskeinen vaihe verkkopalvelun tai ohjelmiston kehitystyössä on sovelluksen tietomallin määrittely ja suunnittelu. Tietomallin suunnittelusta puhuttaessa käytetään tässä työssä myös termiä informaatiosisällön mallintaminen, joka käsittää sekä tietosisällön käsitteistön että eri

11 4 tietoalkioiden välisten riippuvuuksien määrittelyn sekä näiden kuvauksen jollakin tiedonmallintamismenetelmällä. Tiedonmallintamismenetelmiä käsitellään tarkemmin myöhemmin. Luku perustuu pääasiassa lähteisiin [2; 3] Verkkopalvelun pysyvä informaatiosisältö Verkkopalvelun informaatiosisältöä voidaan tarkastella eri näkökulmista ja abstraktiotasoilla. Edellä mainittiin jo käsitetaso (kohdetaso, conceptual level), joka määrittelee mitä tietoja käsitellään, miten tiedot liittyvät yhteen ja millainen on se kohde, jota tiedoilla pitäisi kuvata; asiat, joita pitäisi esittää. Rakennetaso (looginen taso, structural level) puolestaan määrittelee minkälaisia käsiteltäviä rakenteita tieto muodostaa esimerkiksi eri ohjelmointikielten tai tietokantojen näkemykset tiedosta. Talletustaso (fyysinen taso, physical level) määrittelee, minkälaisina koneenläheisinä rakenteina tiedot tallennetaan ja miten niitä voidaan käsitellä minkälaiset rakenteet tehostavat hakua ja ovatko tiedot hajautettu vai keskitetysti samassa paikassa. [1] Verkkopalvelun pysyvällä informaatiosisällöllä tarkoitetaan tässä yhteydessä sellaista tietoa, joka säilyy muuttumattomana sovelluksen eri käyttökertojen välillä. Pysyvä informaatiosisältö määrittelee sovelluksen käsittelemien tietojen käsitteistön ja rakenteen siten, että tietojen ohjelmallinen käsittely ja säilyvyydenhallinta on mahdollista toteuttaa. Pysyvällä informaatiosisällöllä ei tässä yhteydessä siis tarkoiteta esimerkiksi pelkästään tietokantaan talletettua dataa itsessään vaan pikemminkin tallennuksen mahdollistavaa määritelmää tallennettavasta tiedosta ja sen rakenteesta. Varsinaisesta verkkopalvelun käyttämästä datasta puhuttaessa käytetään termiä verkkopalvelun käyttämä informaatio tai tieto. Verkkopalvelun pysyvän informaatiosisällön mallintamisen prosessi sisältää usein kaikki edellä mainitut informaatiosisällön abstraktiotasot, sovelluksen käsitteistön määrittelystä sekä tiedon rakenteen kuvauksesta aina mahdolliseen talletustason määrittelyyn ja valintaan asti. Pysyvän informaatiosisällön mallintaminen mahdollistaa siis palvelun käsittelemän informaation säilyvyydenhallinnan, joka yleensä hoidetaan jonkin ulkoisen tietovaraston kuten tietokannan tai tiedoston avulla. Säilyvyydenhallintaa käsitellään tarkemmin omassa luvussaan. Tässä yhteydessä todetaan kuitenkin, että jotta palvelun käsittelemän informaation säilyvyydenhallinta olisi mahdollista käytännössä toteuttaa, on tallennettava tieto sitä ennen yleensä mallinnettava jollakin menetelmällä Tietomallin määrittely- ja suunnitteluprosessi Tietomallin määrittely ja suunnittelu voidaan nähdä prosessina, jonka tuloksena syntyy verkkopalvelun tai ohjelmiston vaatimusmäärittelyä vastaava tietomalli. Tunnettu ja yleinen menetelmä tämän prosessin läpiviemiseksi on niin sanottu ER-malli (Entity

12 5 Relationship Model), jossa tietomallin suunnittelu alkaa sovellusalueen entiteettien (reaalimaailman oliot, sovelluksen substantiivit) tunnistamisesta ja nimeämisestä. Entiteetit (oliot) voivat olla joko abstrakteja tai konkreettisia, mutta yhteistä niille on se, että niillä on jokin merkitys sovelluksen kannalta. Entiteetit esimerkiksi määrittelevät mitä ja minkä tyyppistä tietoa sovellus hallinnoi, käsittelee ja mahdollisesti tallentaa. Verkkokaupan tapauksessa sovellusalueen konkreettisia entiteettejä voisivat olla muun muassa käyttäjä, ostoskori, tuote, lasku ja mainos tai esimerkiksi hieman abstraktimpi, kuten ostotapahtuma. Entiteettien tunnistamisen ja nimeämisen jälkeen niiden ominaisuuksia tarkennetaan attribuuteilla, jotka kuvaavat ja kapseloivat nimetyn olion sekä sen sisältämät tiedot loogiseksi kokonaisuudeksi. Attribuutteja ovat mitkä tahansa tiedot, jotka kuvaavat entiteetin (olion) ominaisuuksia ja määrittelevät mistä tiedon osasista sovelluksen käsittelemä informaatio lopullisesti koostuu. Tuotteen attribuutteja voisivat olla esimerkiksi nimi, tuotteen kuvaus ja hinta. Entiteettien on oltava yksilöllisesti tunnistettavissa sekä näin ollen erotettavissa muista saman tyypin olioista. Näin esimerkiksi verkkokaupan eri tuotteet on erotettavissa toisistaan, vaikka kukin niistä tuotetta entiteettitasolla edustaakin. Entiteettien tunnistaminen tehdään perusavaimeksi (primary key) kutsutulla attribuutilla, jonka arvo näin ollen on yksilöllinen jokaisella oliolla. Monesti perusavaimen arvona käytetään automaattisesti tuotettua lukuarvoa, IDtunnistetta, koska muuta luonnollista tapaa yksilöidä olioita harvemmin löytyy. Entiteettien väliset yhteydet (relationship, relaatio) sekä rajoitukset on mahdollista määritellä ja kuvata sitten, kun kaksi tai useampi sovellusalueen entiteeteistä on tunnistettu sekä niiden ominaisuudet on määritelty attribuuteilla. Entiteettien välinen yhteys voi olla periaatteessa mikä hyvänsä assosiaatio, linkki tai yhdistävä tekijä, jolle on annettu nimi ja jolla on merkitystä suunniteltavan sovelluksen kannalta. Yhteys voi olla kahden eri entiteetin välinen tai se voi olla entiteetin sisäinen, jolloin relaatio viittaa entiteettiin itseensä. Entiteettien välisten yhteyksien rajoituksia kuvataan muuan muassa lukumääräsuhteilla sekä perintä- ja koostehierarkioilla. Ostoskorin ja tuotteen välillä voi olla esimerkiksi yhteydet nimeltä sisältää ja kuuluu Asiaa havainnollistetaan kuvassa 3.1 yksinkertaisen ER-kaavion (Entity Relationship Diagram) avulla. Kuva 3.1. ER-kaavio entiteettien välisestä yhteydestä. ER-kaavio on kuvallinen esitysmuoto sovellusalueen entiteeteistä ja niiden välisistä yhteyksistä. Entiteetit kuvataan niissä laatikoina ja yhteydet entiteettien väliin piirretyillä viivoilla. Yhteyksien rajoitukset, kuten lukumääräsuhteet, voidaan

13 6 tarvittaessa myös lisätä kaavioon. ER-kaaviot kuvaavat suunniteltavan sovelluksen tietomallin joskus hieman karkealla, mutta kuitenkin ilmaisuvoimaisella tavalla. ERkaavioita on mahdollista myöhemmin käyttää esimerkiksi tietokannan taulujen rakenteen suunnittelussa. Kuvan 3.1 kaavio ilmaisee siis sen, että ostoskorissa voi olla yksi tai useampi tuote ja tuote saattaa kuulua yhteen tai useampaan ostoskoriin. Entiteettien väliset yhteydet voidaan jakaa kolmeen eri tyyppiin sen perusteella, kuinka entiteetit suhtautuvat toisiinsa niiden lukumääräsuhteiden kautta. Nämä tyypit ovat oneto-one (1:1), one-to-many (1:N) ja many-to-many (M:N). Kuvan 3.1 kaaviossa ostoskorin ja tuotteen välillä on many-to-many -tyyppinen yhteys, koska yksi ostoskori voi sisältää useampia tuotteita ja tuote voi kuulua useampaan ostoskoriin. Seuraavissa kuvissa on puolestaan esimerkit one-to-one ja one-to-many - yhteyksistä. Kuva 3.2. ER-kaavio one-to-one - yhteydestä. Kuva 3.3. ER-kaavio one-to-many - yhteydestä. Kuvan 3.2 ER-kaavio ilmaisee, että sormenjälki kuuluu vain yhdelle käyttäjälle ja yksi käyttäjä omistaa vain yhden sormenjäljen. Kuvan 3.3 ER-kaavio puolestaan ilmaisee, että kategoria voi sisältää yhden tai useampia tuotteita, mutta kukin yksittäinen tuote kuuluu vain yhteen kategoriaan. One-to-one yhteys kuvaa siis tilannetta, jossa yksittäinen entiteetti A on yhteydessä toiseen yksittäiseen entiteettiin B ja päinvastoin. One-to-many yhteys puolestaan kuvaa tilannetta, jossa yksittäinen entiteetti A on yhteydessä yhteen, useampaan kuin yhteen tai ei yhteenkään entiteetin B instanssiin. Yksittäinen entiteetti B on kuitenkin yhteydessä vain yhteen entiteetin A instanssiin. Many-to-many yhteys on kyseessä silloin, kun yksittäinen entiteetti A on yhteydessä yhteen, useampaan kuin yhteen tai ei yhteenkään entiteetin B instanssiin ja päinvastoin. Aikaisemmin todettiin, että tietokannan taulujen rakenne on muodostettavissa ERmallin avulla. ER-kaavion laatikot (entiteetit) vastaavat relaatiotietokannan tauluja ja entiteettien väliset viivat puolestaan kuvaavat taulujen välisiä viiteavaimia (foreign key). Viiteavain on taulun sarake, joka sisältää toisen taulun perusavaimen arvoja. Kuvan 3.3

14 7 kaavion perusteella on mahdollista muodostaa taulut Kategoria ja Tuote. Tuote-taulu sisältää myös viiteavaimen, jonka arvot ovat Kategoria-taulun perusavaimen arvoja. Monet reaalimaailman yhteydet ovat many-to-many tyyppisiä, kuten aikaisemmin esimerkkinä käytetyn ostoskorin ja tuotteen välinen suhde. Nämä relaatiot ovat tietokannan suunnittelun kannalta ongelmallisia, koska niistä ei voida suoraan muodostaa relaatiotietokannan tauluja käyttäen viiteavaimia. Tuotteessa ei esimerkiksi voida säilöä viiteavainta ostoskoriin, koska tuote saattaa kuulua yhteen tai useampaan ostoskoriin. Tämä rajoitus on puhtaasti tietokantajärjestelmien sisäisestä toteutustavasta aiheutuva, sillä sovelluslogiikkakerrokselle näiden monimutkaisten relaatioiden hallinta ei ole mikään ongelma, koska ohjelmointikielten syntaksi mahdollistaa paljon monimutkaisempienkin tietorakenteiden käyttämisen. Ongelma on ratkaistavissa korvaamalla many-to-many yhteys uudella entiteetillä (association entity) ja yhdistämällä alkuperäiset entiteetit sitten tähän uuteen entiteettiin one-to-many ja many-to-one yhteyksillä. Ostoskorin ja tuotteen välinen many-to-many tyyppinen yhteys on ratkaistu seuraavassa kuvassa. Kuva 3.4. Ostoskorin ja tuotteen välisen many-to-many - relaation ratkaisu. Kuvan 3.4 kaavio tulkitaan siten, että ostoskori sisältää yhden tai useamman ostotapahtuman ja tuote saattaa kuulua yhteen tai useampaan ostotapahtumaan. Ratkaisua kutsutaan many-to-many yhteyden normalisoiduksi muodoksi, joka on mahdollista toteuttaa myös relaatiotietokannan tauluina viiteavaimia käyttäen. Ratkaisun pohjalta luotavaan tietokantaan tulisi näin ollen taulut Ostoskori, Ostotapahtuma ja Tuote. Ostotapahtuma sisältäisi viiteavainkentät, jotka saisivat Ostoskori- ja Tuote taulujen perusavaimen arvoja. Näin ollen alkuperäinen normalisoimaton many-to-many yhteys olisi johdettavissa näiden kolmen taulun avulla. Many-to-many yhteyksien normalisointi tulisi tehdä hyvin pian niiden tunnistamisen jälkeen, koska kuten aikaisemmin todettiin, ne estävät muuten tietomallin perusteella toteutettavan tietokannan taulurakenteen suunnittelun etenemisen.

15 8 Tietomallin suunnitteluprosessi etenee siis sovellusalueen entiteettien tunnistamisesta ja nimeämisestä (käsitetaso) niiden sisältämien tietojen tarkempaan määrittelyyn attribuuttien avulla (rakennetaso). Entiteettien väliset suhteet kuvataan vielä relaatiolla, jotka normalisoidaan tarvittaessa aikaisemmin kuvatulla tavalla, jonka jälkeen sovelluksen tietomallin voidaan katsoa olevan määritelty. Tämän jälkeen verkkopalvelun tai ohjelmiston kehitystyö jatkuu usein tietomallia vastaavan tietokannan suunnittelulla (talletustaso). Tietokannan taulujen rakenteen määrittely ja suunnittelu on oma laaja kokonaisuutensa, jota ei kuitenkaan tässä kohtaa käsitellä, koska tässä yhteydessä keskitytään pääasiassa sovellusalueen tietomallin määrittelyyn, joka ei ole tallennus- tai sovelluslogiikkatasojen toteutuksesta riippuvainen. Tietomallin määrittely- ja suunnitteluprosessi kuvattiin edellä käyttäen ER-mallia esimerkkinä. Sama toimintatapa on kuitenkin sovellettavissa moniin muihinkin tiedonmallintamismenetelmiin, kuten esimerkiksi UML- (Unified Modeling Language) tai oliomallinnukseen. Eri menetelmien käyttämä terminologia saattaa erota hieman toisistaan, mutta tiedonmallintamisprosessin periaate on kaikissa hyvin samankaltainen. Prosessissa pyritään löytämään sovellusaluetta kuvaavat reaalimaailman ilmentymät (oliot, substantiivit), nimetään ne ja määritellään niiden sisältämät yksityiskohtaiset tiedot attribuuttien avulla sekä kuvataan olioiden väliset suhteet relaatioiden avulla. Ohjelmistotuotannon eri tiedonmallintamismenetelmiä käsitellään lyhyesti kohdassa 2.3, jossa edellä mainitun ER-mallin notaatiotakin tarkastellaan yksityiskohtaisemmin Ohjelmistotuotannon tiedonmallintamismenetelmiä Ohjelmistotuotanto tarjoaa joitakin jo vakiintuneitakin ja yleisesti tunnettuja menetelmiä ja työkaluja ohjelmistojen tietomallin käytännön suunnittelutyön tueksi. Näitä tiedonmallintamismenetelmiä ovat muun muassa ER- ja UML-mallit, jotka mahdollistavat informaation mallintamisen hyvin ilmaisuvoimaisella tavalla. Menetelmien avulla on mahdollista kuvailla tietomallin määrittely ja suunnittelutyön tulokset tietyllä usein projektikohtaisesti sovitulla tavalla. Näin ollen kehitysprojektin eri henkilöiden ja sidosryhmien välinen kommunikointi tietomalliin liittyvissä asioissa helpottuu huomattavasti, koska käytössä on yksi yhteinen käytäntö ja kieli kyseisestä asiasta keskustelemiseen. ER- ja UML-mallit sopivat hyvin informaation käsite- ja rakennetason suunnittelutyön tueksi, koska niiden avulla muodostetut mallit ovat riippumattomia järjestelmän lopullisista teknisistä toteutustavoista. Menetelmien avulla on siis mahdollista visualisoida mallinnettavan järjestelmän tietosisältö ilmaisuvoimaisesti sekä käsite- että rakennetasolla ilman, että riippuvuuksia syntyy esimerkiksi toteutustekniikaksi valittavasta ohjelmointikielestä tai tietokannan tyypistä. Seuraavassa esitellään edellä mainitut menetelmät lyhyesti sekä pohditaan hieman niiden sopivuutta suunnittelutyön tueksi tietomallin määrittelyprosessin näkökulmasta.

16 ER-malli ER-malli (Entity Relationship Model), johon kohdan 2.2 esimerkeissä käytetyt kaaviot perustuvat, on käsitteellinen tietomalli, joka kuvaa reaalimaailmaa entiteettien ja niiden välisten relaatioiden avulla. Mallin peruskomponentti on ER-kaavio, jonka avulla visualisoidaan varsinaisen mallin entiteetit ja niiden väliset suhteet. Malli esiteltiin alun perin 1970-luvulla menetelmäksi, jonka tavoitteena oli yhdenmukaistaa eri tietokantatyyppien näkymien kuvaustekniikat. Mallia on laajennettu tämän jälkeen vuosien kuluessa ja nykyisin se on yleisesti käytetty tietokantojen suunnittelumenetelmä. ER-mallin yleistymistä tietokantasuunnittelun menetelmänä ovat edesauttaneet muun muassa seuraavat seikat. Se soveltuu hyvin relaatiomallin kuvaamiseen, jolloin ER-mallin mukainen suunnitelma on yleensä suoraviivaista toteuttaa relaatiotietokannan tauluina. ER-malli on myös suhteellisen yksinkertainen ja helppo oppia sekä hyvin ilmaisuvoimainen, joten se sopii hyvin sekä tietokantasuunnittelijoiden että muiden tuotekehitysprojektin sidosryhmien väliseen kommunikointiin. ER-mallin avulla on lisäksi mahdollista suunnitella tietokannan rakenne siten, että se ei ole riippuvainen mistään tietystä tietokantatuotteesta tai tietokannanhallintajärjestelmästä Näin ollen suunnitelma tietokannan rakenteesta on tarvittaessa mahdollista tehdä ennen kuin esimerkiksi tiedetään mitä tietokantatuotetta tuotekehityksessä tullaan käyttämään. ER-malli siis määrittelee järjestelmän tietomallin käsite- ja rakennetasolla entiteettien ja niiden välisten suhteiden avulla sekä visualisoi mallin käyttäen ER-kaaviota. ERkaavioiden esittämiseen ei ole olemassa standardia, joten näin ollen ER-malliin perustuvien eri mallintamismenetelmien käyttämät notaatiot eroavat silloin tällöin hieman toisistaan. Toisaalta eri notaatioiden väliset erot eivät ole yleensä merkittäviä, joten hieman erilaisella kuvaustekniikalla tehtyjen kaavioiden tulkitseminen yhden notaation hyvin hallitsevalle henkilölle ei ole yleensä ongelma. Standardin puuttumisesta huolimatta eri notaatiolla on hyvin paljon yhteisiä piirteitä. Esimerkiksi entiteetit esitetään poikkeuksetta suorakulmaisina laatikoina ja niiden väliset relaatiot niitä yhdistävinä viivoina. Entiteetit nimetään melkein poikkeuksetta yksittäisillä substantiiveilla ja relaatiot puolestaan verbeillä. Attribuutit sijoitetaan entiteettien sisään ja nimetään yksittäisillä substantiiveilla. Suurimmat erot eri notaatioiden välillä liittyvät yleensä relaatioita kuvaavien lukumääräsuhteiden eli kardinaliteettien (cardinality, multiplicity) ja olemassa olon (existence) esittämiseen. Relaatiota kuvaava viiva loppuu yleensä haaroitukseen kardinaaliluvun ollessa suurempi kuin yksi. Jos viiva ei haaroitu, niin kardinaaliluku on yksi. Entiteettien välisen relaation olemassa oloa puolestaan kuvataan usein relaatiota esittävän viivan päähän lisättävällä ympyrällä tai kohtisuoralla viivalla. Kohtisuora viiva entiteetin vieressä tarkoittaa sitä, että kyseisen entiteetin instanssin olemassa olo on pakollinen ja ympyrä puolestaan sitä, että entiteetti on vaihtoehtoinen. Kuva 3.5 havainnollistaa erästä ER-kaavioiden kuvaamisessa käytettyä notaatiota.

17 10 Kuva 3.5. Esimerkki ER-kaaviosta [3]. ER-malli on siis käsitteellinen malli, joka kuvaa reaalimaailmaa entiteeteillä, niiden välisillä relaatioilla ja entiteettien ominaisuuksilla eli attribuuteilla sekä esittää mallintamisen tulokset ER-kaavioiden avulla. Se sopii erityisen hyvin relaatiomalliin perustuvien relaatiotietokantojen suunnitteluun sekä mahdollistaa muun muassa tehokkaan kommunikoinnin tuotekehitysprojektin eri sidosryhmien välillä järjestelmän tietomalliin liittyvissä kysymyksissä UML-malli UML (Unified Modeling Language) on graafinen kieli, jolla on mahdollista ilmaisuvoimaisesti kuvata muuan muassa ohjelmistoille ja tietojärjestelmille asetettavia vaatimuksia, arkkitehtuuria sekä määrittely- ja suunnitteluprosessia yleensä. UML julkaistiin vuonna 1997 ja sen tarkoitus oli määritellä yhtenäinen syntaksi, jolla voitaisiin mallintaa sekä ohjelmistojen komponentit sekä sovelluksien informaatiosisältö eli tietomalli. UML on julkaisunsa jälkeen saavuttanut suuren suosion ohjelmistoteollisuudessa ja on tällä hetkellä yksi yleisimmin käytetyistä suunnittelutyön tulosten dokumentointimenetelmistä ohjelmistojen ja järjestelmien kehityksessä. UML on standardoitu ja hyvin monipuolinen mallintamiskieli, joka koostuu joukosta erilaisia kaavioita (diagrams), jotka on kehitetty helpottamaan ohjelmistojen ja järjestelmien suunnittelijoita suorittamaan muun muassa seuraavia tehtäviä: määrittely, arkkitehtuurisuunnittelu, oliosuunnittelu sekä dokumentointi ja visualisointi. UML tarjoaa useita erilaisia menetelmiä ja malleja esimerkiksi ohjelmistojen toiminnallisen määrittely- ja suunnittelutyön tueksi. Tässä yhteydessä keskitytään kuitenkin tarkastelemaan UML:ää ainoastaan sovellusten tietomallin määrittelyn näkökulmasta.

18 11 Kuten aikaisemmin todettiin, niin ER-malli sopi hyvin relaatiomallin mukaisten relaatiotietokantojen tietomallien suunnitteluun. ER-malli on hyvin tietokeskeinen (data-oriented) suunnittelumenetelmä, joka keskittyy entiteettien ja niiden välisten relaatioiden suunnitteluun informaatiosisällölle asetettujen vaatimusten perusteella. Informaatiosisällölle asetettavat vaatimukset sitten määrittelevät muut ohjelmistoa koskevat suunnitteluratkaisut. Tätä lähestymistapaa tai paradigmaa kutsutaan tietokeskeiseksi suunnitteluksi (data-oriented design). Oliokeskeisissä (object-oriented) suunnittelumenetelmissä ohjelmistot mallinnetaan puolestaan joukkona olioita, jotka keskenään kommunikoiden muodostavat ohjelmiston toiminnallisuuden. Olioille asetettavat vaatimukset (olioanalyysi) määrittelevät muut ohjelmistoa koskevat suunnitteluratkaisut. Oliokeskeisen suunnittelun (olioparadigman) mukaan sovellukset koostuvat siis olioista, jotka sisältävät sekä sovelluksen käsittelemän informaation että toiminnallisuuden. Tämä erottaa oliot ER-mallin käyttämistä entiteeteistä, vaikka niillä molemmilla mallinnetaan periaatteessa samoja asioita reaalimaailman asioita ja ilmiöitä. UML tarjoaa paljon erilaisia työkaluja ja menetelmiä myös oliokeskeisten järjestelmien määrittelyyn ja suunnitteluun, mutta kuten aikaisemmin todettiin, niin tässä yhteydessä keskitytään ainoastaan sovellusten tietomallin suunnitteluun tarkoitettuihin menetelmiin. UML:ssa sovellusten tietomalli määritellään luokkakaavioiden (class diagram) avulla. Luokkakaaviot ovat UML:n looginen vastine ER-mallin ER-kaavioille sillä erolla, että ne määrittelevät luokkien sisältämien tietojen lisäksi tarvittaessa myös niiden sisältämän toiminnallisuuden eli operaatiot. Luokkakaavio muodostuu siis luokista, joilla mallinnetaan reaalimaailman asioita aivan kuten ER-mallin entiteeteillä. Luokat sisältävät ominaisuuksia eli attribuutteja, jotka määrittelevät kyseisen luokan olioiden sisältämät tiedot. Luokkakaavio sisältää tiedon myös luokkien välisistä yhteyksistä eli assosiaatioista. Periaatteessa UML:n luokkakaaviot tuovat lisää ER-kaavioihin nähden ainoastaan mahdollisuuden esittää kaaviossa myös olioiden operaatiota. Toisaalta UML:n avulla oliokeskeisen järjestelmän mallintaminen onnistuu ER-mallia hieman luontevammin, koska UML:n tarjoaa erityisesti olioparadigmaa tukevia piirteitä hyvin kattavasti. Näitä ovat muun muassa oliojärjestelmille hyvin tyypilliset olioiden kooste- ja perintäsuhteet. Koostesuhde on kyseessä silloin kun olio koostuu toisista olioista ja perinnässä luokka puolestaan laajentaa perittävän kantaluokan ominaisuuksia jollakin tavalla. Kuvassa 3.6 havainnollistetaan UML:n käyttöä esittämällä kuvan 3.5 ER-malli luokkakaavion avulla. Kaaviossa on käytetty lisäksi myös kooste- ja perintäsuhdetta.

19 12 Kuva 3.6. Esimerkki UML:n luokkakaaviosta. UML- ja ER-mallien avulla saavutetaan hyvin pitkälti samoja etuja tuotekehitysprojektin näkökulmasta. Molemmat mahdollistavat ohjelmiston informaatiosisällön mallintamisen hyvin ilmaisuvoimaisella tavalla sekä helpottavat projektin eri sidosryhmien välistä kommunikointia erityisesti sovelluksen tietomalliin liittyvissä kysymyksissä. ER-malli sopii ehkä hieman UML-mallia paremmin relaatiotietokantojen suunnitteluun ja UML-mallien vahvuus tulee puolestaan hyvin esille puhtaasti oliokeskeisiä järjestelmiä suunniteltaessa. Oliojärjestelmien monimutkaiset oliohierarkiat eivät välttämättä sellaisenaan sovi kovin suoraviivaisesti relaatiotietokantojen relaatiomalliin, jolloin niiden mallintaminen niille suunnatuilla työkaluillakaan ei välttämättä ole kovin tuottavaa tuotekehitysprojektin näkökulmasta. UML-kaaviot puolestaan tukevat hyvin oliosuunnittelua ja mahdollistavat näin ollen tehokkaan ja suoraviivaisen oliomallintamisen. Oliojärjestelmien ja relaatiotietokantojen yhteensovittamisesta aiheutuviin haasteisiin perehdytään tarkemmin myöhemmin säilyvyydenhallintaa käsittelevässä luvussa.

20 13 3. INFORMAATIOSISÄLLÖN SÄILYVYYDENHALLINTA Informaatiosisällön säilyvyydenhallinta mahdollistaa ohjelmistojen käsittelemien tietojen tallentamisen siten, että ne ovat myöhemmin luettavissa uudelleen sovelluksen käyttöön. Toisin sanoen sovelluksen käsittelemät tiedot tallennetaan usein järjestelmän kovalevylle ja luetaan sieltä tarvittaessa myöhemmin. Näin ollen informaatio on mahdollista varastoida myös sovelluksen eri käyttökertojen välillä. Säilyvyydenhallinta on mahdollista toteuttaa useilla eri tavoilla, joista jokaisella on myös etunsa ja haittansa. Näihin eri tapoihin perehdytään myöhemmin tässä luvussa. Yhteistä näille eri menetelmille on kuitenkin se, että jokainen niistä edellyttää, että sovelluksen tietomalli on ainakin jollakin tasolla olemassa eli verkkopalvelun tai ohjelmiston käsittelemä informaatiosisältö on mallinnettu jollakin tavalla. Luku perustuu pääasiassa lähteisiin [3; 4; 6; 9; 10]. Perinteinen säilyvyydenhallinnan toteutusmekanismi on säilöä sovelluksen käsittelemä informaatio johonkin tietyn tiedostomuodon omaavaan (formaattiseen) tiedostoon. Eräs yleisesti tunnettu tiedostoformaatti on niin sanottu CSV-tiedosto (Comma Separated Values), joka on selkokielinen tekstitiedosto, jonka jokainen yksittäinen rivi edustaa yhden säilöttävän entiteetin tietoja pilkulla toisistaan erotettuna. CSV-tiedostojen tai vastaavien formaattien käyttö sovellusten käyttämien tietojen tallentamiseen on usein hyvin yksinkertaista ja suoraviivaista. Eri ohjelmointikielet tukevat tiedostoihin kirjoitusta ja niistä lukua varsin kattavasti, joten informaation tallentaminen ei yleensä vaadi näin ollen mitään erityistoimenpiteitä tai esimerkiksi jonkin kolmannen osapuolen tuotteita. Tiedostot sopivat hyvin tietomäärällisesti pienten ja yksinkertaisten sovellusten informaation tallentamisvälineiksi. Ne menettävät yksinkertaisuuden mukanaan tuomat etunsa kuitenkin melko nopeasti sovelluksen käsittelemien tietomäärien kasvaessa suuremmiksi. Tietojen käsittely, muokkaaminen ja monimutkaisten hakujen tekeminen käyvät suurilla tietomäärillä nopeasti suhteellisen työläiksi operaatioiksi, jos sovellus käyttää tiedostoja pääasiallisena informaation tallennusmekanisminaan. Edellä mainitut selkokieliset tekstitiedostoformaatit aiheuttavat myös joitakin tietoturvallisuuteen ja informaation eheyteen kohdistuvia riskejä, koska sovelluksen käyttämän tietovaraston sisällön muokkaaminen muualta kuin sovelluksen tai verkkopalvelun itsensä toimesta on hyvin helppoa. Datan muokkaamiseen tietovarastossa riittää periaatteessa mikä tahansa tekstinkäsittelyohjelma, joten on hyvin mahdollista, että jossain vaiheessa

Tietokantojen suunnittelu, relaatiokantojen perusteita

Tietokantojen suunnittelu, relaatiokantojen perusteita Tietokantojen suunnittelu, relaatiokantojen perusteita A277, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin

Lisätiedot

Tiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas

Tiedonhallinnan perusteet. Viikko 1 Jukka Lähetkangas Tiedonhallinnan perusteet Viikko 1 Jukka Lähetkangas Kurssilla käytävät asiat Tietokantojen toimintafilosofian ja -tekniikan perusteet Tiedonsäilönnän vaihtoehdot Tietokantojen suunnitteleminen internetiä

Lisätiedot

2. Käsiteanalyysi ja relaatiomalli

2. Käsiteanalyysi ja relaatiomalli 2. Käsiteanalyysi ja relaatiomalli lehtori Pasi Ranne Metropolia ammattikorkeakoulu E-mail: pasi.ranne@metropolia.fi sivu 1 Tietokannan suunnitteluprosessin osat sivu 2 Käsiteanalyysi ER-mallinnus, tietomallinnus

Lisätiedot

3. Käsiteanalyysi ja käsitekaavio

3. Käsiteanalyysi ja käsitekaavio 3. Käsiteanalyysi ja käsitekaavio lehtori Pasi Ranne Metropolia ammattikorkeakoulu E-mail: pasi.ranne@metropolia.fi sivu 1 Käsiteanalyysi Selvitetään mitä tietokantaan pitää tallentaa Lähtökohtana käyttäjien

Lisätiedot

Relaatiomalli ja -tietokanta

Relaatiomalli ja -tietokanta Relaatiomalli ja -tietokanta > Edgar. F. (Ted) Codd, IBM, 1969 < A Relational Model of Data for Large Shared Data Banks Communications of the ACM, Vol. 13, No. 6, June 1970, pp. 377-387. > 70-luvun lopulla

Lisätiedot

Opettajana Mika Sorsa, mika.sorsa@koudata.fi, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija

Opettajana Mika Sorsa, mika.sorsa@koudata.fi, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija Opettajana Mika Sorsa, mika.sorsa@koudata.fi, HAMK:n ammatillisen opettajakoulutuksen opetusharjoittelija Opintojaksolla: keskitytään relaatiotietokantojen teoriaan ja toimintaan SQL-kieli kyselykielenä

Lisätiedot

Tietomallit. Näkökulmat tietoon. Näkökulmat tietoon. Mitä malleja olisi tarjolla? Abstraktiotasot tiedon käsittelyssä

Tietomallit. Näkökulmat tietoon. Näkökulmat tietoon. Mitä malleja olisi tarjolla? Abstraktiotasot tiedon käsittelyssä Tietomallit Tietomallilla (data model) tarkoitetaan tiedon rakenteen ja tiedolle suoritettavan käsittelyn määrittelevää kehikkoa - käsitteistöä Tietoa voidaan tarkastella eri näkökulmista - eri abstraktiotasoilla

Lisätiedot

HELIA 1 (20) Outi Virkki Tiedonhallinta 4.11.2000

HELIA 1 (20) Outi Virkki Tiedonhallinta 4.11.2000 HELIA 1 (20) Luento 3.1 7LHWRNDQWDSRKMDLVHQVRYHOOXNVHQVXXQQLWWHOXSURVHVVL Tietokannan suunnittelun tavoitteet... 3 Abstraktiotasot tietokannan suunnittelussa... 4 3-taso -malli... 4 TIHA-standardi... 5

Lisätiedot

Jouni Huotari & Ari Hovi. Käsitemallinnuksesta relaatiokantaan KÄSITEMALLI. LOOGINEN MALLI: tietomalli valittu. FYYSINEN MALLI: DBMS valittu

Jouni Huotari & Ari Hovi. Käsitemallinnuksesta relaatiokantaan KÄSITEMALLI. LOOGINEN MALLI: tietomalli valittu. FYYSINEN MALLI: DBMS valittu Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Polku luokkakaavioista taulujen toteutukseen kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003,

Lisätiedot

582104 Ohjelmistojen mallintaminen, olioja relaatiomallinnuksen suhteesta

582104 Ohjelmistojen mallintaminen, olioja relaatiomallinnuksen suhteesta 582104 Ohjelmistojen mallintaminen, olioja relaatiomallinnuksen suhteesta 1 Tietojen pysyvyys liiketoiminnan edellytys Tällä kurssilla on keskitytty oliomenetelmiä hyödyntävään ohjelmistojen mallintamiseen

Lisätiedot

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14

Arkkitehtuurikuvaus. Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy. Ryhmä 14 Arkkitehtuurikuvaus Ratkaisu ohjelmistotuotelinjan monikielisyyden hallintaan Innofactor Oy Ryhmä 14 Muutoshistoria Versio Pvm Päivittäjä Muutos 0.4 1.11.2007 Matti Eerola 0.3 18.10.2007 Matti Eerola 0.2

Lisätiedot

TIETOKANNAT JOHDANTO

TIETOKANNAT JOHDANTO TIETOKANNAT JOHDANTO JOUNI HUOTARI & ARI HOVI 2000-2011 Tieto TAUSTAA Yritykselle tiedot ovat tärkeä resurssi päätöksenteon tukena (JIT) varastointi ja käyttö vaativat investointeja vrt. energia (lähde,

Lisätiedot

Visual Case 2. Miika Kasnio (C9767) 23.4.2008

Visual Case 2. Miika Kasnio (C9767) 23.4.2008 Visual Case 2 Miika Kasnio (C9767) 23.4.2008 Työn tarkasti: Jouni Huotari 24.4.2008 1 SISÄLTÖ 1. TYÖN LÄHTÖKOHDAT... 2 2. PERUSTIEDOT... 2 3. ASENTAMINEN... 2 4. OMINAISUUDET... 3 4.1. UML-kaaviot... 4

Lisätiedot

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen

Tietojärjestelmä tuotantoympäristössä. Sovellusohjelmat Helsingin ammattikorkeakoulu Stadia / Tekniikka ja liikenne Vesa Ollikainen Tietojärjestelmä tuotantoympäristössä Tausta ja tavoitteet Tausta Kurssilla on opiskeltu suunnittelemaan ja toteuttamaan tietokanta, joka on pieni perustuu selkeisiin vaatimuksiin on (yleensä) yhden samanaikaisen

Lisätiedot

A271117 TIETOKANNAT, 3 op Syksy 2008 - TI07. Teemu Saarelainen, lehtori Tietotekniikka teemu.saarelainen@kyamk.fi

A271117 TIETOKANNAT, 3 op Syksy 2008 - TI07. Teemu Saarelainen, lehtori Tietotekniikka teemu.saarelainen@kyamk.fi A271117 TIETOKANNAT, 3 op Syksy 2008 - TI07 Teemu Saarelainen, lehtori Tietotekniikka teemu.saarelainen@kyamk.fi A271117 TIETOKANNAT Tavoitteet Oppia tietokantojen suunnitteluperiaatteet Osata käyttää

Lisätiedot

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3

Uutisjärjestelmä. Vaatimusmäärittely. Web-palvelujen kehittäminen. Versio 1.3 Uutisjärjestelmä Vaatimusmäärittely Versio 1.3 Sisällys 1 Muutoshistoria... 4 2 Viitteet... 4 3 Sanasto... 4 3.1 Lyhenteet... 4 3.2 Määritelmät... 4 4 Johdanto...5 4.1 Järjestelmän yleiskuvaus... 5 4.2

Lisätiedot

UML Luokkakaavio 14:41

UML Luokkakaavio 14:41 UML Luokkakaavio UML Olio-ohjelman luokkien pääpiirteet voidaan kätevähkösti esittää ns. UML-luokkakaaviona. Näin usein tehdäänkin esim. suunniteltaessa, millaisia luokkia ohjelmaan on tarkoitus laatia,

Lisätiedot

HELIA 1 (11) Outi Virkki Tiedonhallinta 4.11.2000

HELIA 1 (11) Outi Virkki Tiedonhallinta 4.11.2000 HELIA 1 (11) Access 1 ACCESS...2 Yleistä...2 Access-tietokanta...3 Perusobjektit...3 Taulu...5 Kysely...7 Lomake...9 Raportti...10 Makro...11 Moduli...11 HELIA 2 (11) ACCESS Yleistä Relaatiotietokantatyyppinen

Lisätiedot

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta.

Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Malli-näkym kymä-ohjain arkkitehtuurit (Model-View View-Controller, MVC) Interaktiivisten järjestelmien arkkitehtuuriratkaisu, jolla käyttöliittymä erotetaan sovelluslogiikasta. Lähtökohdat: Sovelluksen

Lisätiedot

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät

Tenttikysymykset. + UML-kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN

REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN Arkistolaitos REKISTERI- JA TIETOKANTA-AINEISTOJEN SIIRTÄMINEN VAPA-PALVELUUN Ohje v. 1.0 (16.10.2012) Kansallisarkisto Rauhankatu 17 PL 258, 00171 Helsinki Puh. Tel. (09) 228 521 arkisto@narc.fi Riksarkivet

Lisätiedot

Verkkopalveluiden saavutettavuus

Verkkopalveluiden saavutettavuus Verkkopalveluiden saavutettavuus Puhuja: Ossi Nykänen Tampereen teknillinen yliopisto, Hypermedialaboratorio, W3C Suomen toimisto Paikka: Helsinki, Tieteiden talo, 24.3.2011 Johdanto Verkkopalvelun saavutettavuus

Lisätiedot

TIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely

TIE-20200 Samuel Lahtinen. Lyhyt UML-opas. UML -pikaesittely Lyhyt UML-opas UML -pikaesittely UML, Unified Modeling Language Standardoitu, yleiskäyttöinen mallinnuskieli, jota ylläpitää/hallitsee (Object Management Group) OMG Historiaa: 90-luvulla oli paljon kilpailevia

Lisätiedot

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari

Alkuraportti. LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari LAPPEENRANNAN TEKNILLINEN YLIOPISTO TIETOJENKÄSITTELYN LAITOS CT10A4000 - Kandidaatintyö ja seminaari Alkuraportti Avoimen lähdekoodin käyttö WWW-sovelluspalvelujen toteutuksessa Lappeenranta, 30.3.2008,

Lisätiedot

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät

Tenttikysymykset. + UML- kaavioiden mallintamistehtävät Tenttikysymykset 1. Selitä mitä asioita kuuluu tietojärjestelmän käsitteeseen. 2. Selitä kapseloinnin ja tiedon suojauksen periaatteet oliolähestymistavassa ja mitä hyötyä näistä periaatteista on. 3. Selitä

Lisätiedot

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa

4.2 Yhteensopivuus roolimalleihin perustuvassa palvelussa 4. Roolimallipalvelu 4.1 Tiedot palvelusta Palvelun nimi: Palvelun versio 01.01.00 Toteuttaa palvelun yksilöllistä palvelua (kts. M14.4.42) Roolimallipalvelu (Model role service) MYJ:lle, jotka toteuttavat

Lisätiedot

Johdatus rakenteisiin dokumentteihin

Johdatus rakenteisiin dokumentteihin -RKGDWXVUDNHQWHLVLLQGRNXPHQWWHLKLQ 5DNHQWHLQHQGRNXPHQWWL= rakenteellinen dokumentti dokumentti, jossa erotetaan toisistaan dokumentin 1)VLVlOW, 2) UDNHQQHja 3) XONRDVX(tai esitystapa) jotakin systemaattista

Lisätiedot

Yhteydelle voi antaa nimen kumpaankin suuntaan Sille ei tarvise antaa lainkaan nimeä Yhteysnimen asemasta tai lisäksi voidaan käyttää roolinimiä

Yhteydelle voi antaa nimen kumpaankin suuntaan Sille ei tarvise antaa lainkaan nimeä Yhteysnimen asemasta tai lisäksi voidaan käyttää roolinimiä DO NOT PRINT THIS DOCUMENT DO NOT PRINT THIS DOCUMENT Olioiden väliset yhteydet Yhteyden nimi Nimen lukusuunta pankkitili 0..10 Omistaja-> 1..3 asiakas

Lisätiedot

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset

Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Tekninen määrittely: Editori Digi-tv vastaanottimella toteutetut interaktiiviset sovellukset Sisällysluettelo 1. Johdanto...4 1.1. Tarkoitus ja kattavuus...4 1.2. Tuote ja ympäristö...4 1.3. Määritelmät,

Lisätiedot

Harjoitustehtävät ja ratkaisut viikolle 48

Harjoitustehtävät ja ratkaisut viikolle 48 Harjoitustehtävät ja ratkaisut viikolle 48 1. Tehtävä on jatkoa aiemmalle tehtävälle viikolta 42, missä piti suunnitella älykodin arkkitehtuuri käyttäen vain ennalta annettua joukkoa ratkaisuja. Tämäkin

Lisätiedot

FYYSINEN SUUNNITTELU

FYYSINEN SUUNNITTELU IIO30120 DATABASE DESIGN / TIETOKANTOJEN SUUNNITTELU JA IIO30220 DATABASE MANAGEMENT / TIETOKANNAN HALLINTA FYYSINEN SUUNNITTELU KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI,

Lisätiedot

TIETOKANTOJEN PERUSTEET OSIO 14 MARKKU SUNI

TIETOKANTOJEN PERUSTEET OSIO 14 MARKKU SUNI TIETOKANTOJEN PERUSTEET OSIO 14 MARKKU SUNI Tavoite: Suunnitella käyttäjien tarvitsemat turvallisuusmekanismit ja säännöt. Toisin sanoen: tehdä tietokannasta turvallinen ja luotettava. Muistutus: Tietokanta

Lisätiedot

Amazon Web Services (AWS) on varmaankin maailman suosituin IaaS-tarjoaja. Lisäksi se tarjoaa erilaisia PaaS-kategoriaan kuuluvia palveluita.

Amazon Web Services (AWS) on varmaankin maailman suosituin IaaS-tarjoaja. Lisäksi se tarjoaa erilaisia PaaS-kategoriaan kuuluvia palveluita. 1 2 Amazon Web Services (AWS) on varmaankin maailman suosituin IaaS-tarjoaja. Lisäksi se tarjoaa erilaisia PaaS-kategoriaan kuuluvia palveluita. 3 4 Region vastaa palvelun fyysistä sijaintipaikkaa (AWS

Lisätiedot

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita.

Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Perusarkkitehtuurin ja vuorovaikutuksen mallintamisen perusteita. Arkkitehtuuriin vaikuttavat ympäristötekijät Jo kehittämisen alkuvaiheessa on tarpeellista hahmotella arkkitehtuurin perusratkaisu. Lähtökohdat

Lisätiedot

Written by Administrator Monday, 05 September 2011 15:14 - Last Updated Thursday, 23 February 2012 13:36

Written by Administrator Monday, 05 September 2011 15:14 - Last Updated Thursday, 23 February 2012 13:36 !!!!! Relaatiotietokannat ovat vallanneet markkinat tietokantojen osalta. Flat file on jäänyt siinä kehityksessä jalkoihin. Mutta sillä on kuitenkin tiettyjä etuja, joten ei se ole täysin kuollut. Flat

Lisätiedot

Integrointi. Ohjelmistotekniikka kevät 2003

Integrointi. Ohjelmistotekniikka kevät 2003 Integrointi Ohjelmistotekniikka kevät 2003 ERP (Toiminnanohjausjärjestelmä) Myynti Henkilöstö, palkanlaskenta Kirjanpito Myynti Myyjät Extranet Tietovarasto Laskutus, reskontrat Asiakas ERP Asiakasrekisteri

Lisätiedot

Mallintaminen; kurssipalautejärjestelmä

Mallintaminen; kurssipalautejärjestelmä Thomas Gustafsson & Saara Salminen Mallintaminen; kurssipalautejärjestelmä Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikan koulutusohjelma Mallintaminen, tehtävä 1 21.1.2012 Tiivistelmä Tekijä(t)

Lisätiedot

HELIA 1 (19) Outi Virkki Tietokantasuunnittelu 9.3.2001

HELIA 1 (19) Outi Virkki Tietokantasuunnittelu 9.3.2001 HELIA 1 (19) Luento 11 Eheyssäännöt (Integrity Constraints)... 2 Eheyden valvonta... 3 Yksilön eheyssääntö... 4 Arvojoukkoeheyssäännöt... 5 Null-arvoista... 6 Viite-eheyssäännöt... 7 Emorelaation päivitys...

Lisätiedot

Testidatan generointi

Testidatan generointi Testidatan generointi Anu Ahonen Kevät 2008 Tämä työ on tehty Creative Commons -lisenssin alla Työn tarkasti 9.4.2008 Jouni Huotari (JAMK/IT) 1 SISÄLTÖ 1 TYÖN LÄHTÖKOHDAT JA TOTEUTUS...2 2 TESTIDATAN GENEROINTI

Lisätiedot

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena

Ohjelmointikielet ja -paradigmat 5op. Markus Norrena Ohjelmointikielet ja -paradigmat 5op Markus Norrena Ko#tehtävä 4 Viimeistele "alkeellinen kuvagalleria". Käytännössä kaksi sivua Yksi jolla voi ladata kuvia palvelimelle (file upload) Toinen jolla ladattuja

Lisätiedot

Visual Basic -sovelluskehitin Juha Vitikka

Visual Basic -sovelluskehitin Juha Vitikka Visual Basic -sovelluskehitin Helsinki 30.10.2000 Seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Visual Basic sovelluskehitin Seminaari: Ohjelmistotuotantovälineet Tietojenkäsittelytieteen

Lisätiedot

Paikkatiedot ja Web-standardit

Paikkatiedot ja Web-standardit Paikkatiedot ja Web-standardit Ossi Nykänen Tampereen teknillinen yliopisto (TTY), Digitaalisen median instituutti (DMI), Hypermedialaboratorio W3C Suomen toimisto Esitelmä Hyvin lyhyt versio: World Wide

Lisätiedot

GroupDesk Toiminnallinen määrittely

GroupDesk Toiminnallinen määrittely GroupDesk Toiminnallinen määrittely Tilanne: Paikallinen oppilaitos, kuvitteellinen WAMK, tarvitsee ryhmätyöhön soveltuvan sähköisen asioiden hallintajärjestelmän ja ryhmätyöohjelmiston, jonka ajatuksena

Lisätiedot

Copyright by Haikala. Ohjelmistotuotannon osa-alueet

Copyright by Haikala. Ohjelmistotuotannon osa-alueet Copyright by Haikala Ohjelmistotuotannon osa-alueet Ohjelmiston elinkaari 1. Esitutkimus, tarvekartoitus, kokonaissuunnittelu, järjestelmäsuunnittelu (feasibility study, requirement study, preliminary

Lisätiedot

SQLite selvitysraportti. Juha Veijonen, Ari Laukkanen, Matti Eronen. Maaliskuu 2010

SQLite selvitysraportti. Juha Veijonen, Ari Laukkanen, Matti Eronen. Maaliskuu 2010 SQLite selvitysraportti Juha Veijonen, Ari Laukkanen, Matti Eronen Maaliskuu 2010 Opinnäytetyö Kuukausi Vuosi 1 SISÄLTÖ 1. YLEISTÄ SQLITE:STA... 2 2. HISTORIA... 2 3. SQLITEN KÄYTTÖ... 3 3.1 SQLiten asennus

Lisätiedot

Sisällys. 19. Unified Modeling Language (UML) Johdanto. Johdanto. Johdanto. Luokkakaavio:

Sisällys. 19. Unified Modeling Language (UML) Johdanto. Johdanto. Johdanto. Luokkakaavio: Sisällys 9. Unified Modeling Language (UML) Perustuu Kai Koskimiehen Oliokirjaan ja aikaisempaan luentomateriaaliin. Johdanto. Luokkakaavio: Luokkasymboli, attribuutit ja metodit. Suhteet: Assosiaatiot:

Lisätiedot

Tietojärjestelmän osat

Tietojärjestelmän osat Analyysi Yleistä analyysistä Mitä ohjelmiston on tehtävä? Analyysin ja suunnittelun raja on usein hämärä Ei-tekninen näkökulma asiakkaalle näkyvien pääkomponenttien tasolla Tietojärjestelmän osat Laitteisto

Lisätiedot

Olio-ohjelmointi: Luokkien toteuttaminen. Jukka Juslin

Olio-ohjelmointi: Luokkien toteuttaminen. Jukka Juslin Olio-ohjelmointi: Luokkien toteuttaminen Jukka Juslin Luokkien kirjoittaminen Tähän mennessä on käytetty valmiiksi määritettyjä luokkia. Nyt opimme kirjoittamaan omia luokkia olioiden kuvaamiseksi Seuraavaksi

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Hajautettu tietokanta. Hajautuksen hyötyjä

Järjestelmäarkkitehtuuri (TK081702) Hajautettu tietokanta. Hajautuksen hyötyjä Järjestelmäarkkitehtuuri (TK081702) Hajautettu tietokanta Hajautettu tietokanta Jokainen hajautettu tietokanta muodostaa oman kokonaisuutensa Loogisesti yhtenäinen data on hajautettu tietokantoihin (eri

Lisätiedot

SQL-perusteet, SELECT-, INSERT-, CREATE-lauseet

SQL-perusteet, SELECT-, INSERT-, CREATE-lauseet SQL-perusteet, SELECT-, INSERT-, CREATE-lauseet A271117, Tietokannat Teemu Saarelainen teemu.saarelainen@kyamk.fi Lähteet: Leon Atkinson: core MySQL Ari Hovi: SQL-opas TTY:n tietokantojen perusteet-kurssin

Lisätiedot

Toimilohkojen turvallisuus tulevaisuudessa

Toimilohkojen turvallisuus tulevaisuudessa Toimilohkojen turvallisuus tulevaisuudessa Turvallisuusseminaari ASAF 30.10-1.11.2006 Mika Strömman Teknillinen korkeakoulu 1 Sisältö Luotettavuuden lisääminen hyvillä tavoilla Toimilohkokirjastot Turvatoimilohkot

Lisätiedot

www.solita.fi solita@solita.fi

www.solita.fi solita@solita.fi www.solita.fi solita@solita.fi JAVA-SOVELLUSTEN RAKENTAMINEN INTEGROITUUN YMPÄRISTÖÖN Jarno Peltoniemi Solita Oy 10.5.2005 Aiheet Johdanto Portaalit, portletit Oracle Portal Java-sovelluksen rakentaminen

Lisätiedot

Uudelleenkäytön jako kahteen

Uudelleenkäytön jako kahteen Uudelleenkäyttö Yleistä On pyritty pääsemään vakiokomponenttien käyttöön Kuitenkin vakiokomponentit yleistyneet vain rajallisilla osa-alueilla (esim. windows-käyttöliittymä) On arvioitu, että 60-80% ohjelmistosta

Lisätiedot

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7

Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Paikkatietorajapinnat IT arkkitehtuurin näkökulmasta 21.12.200 7 Mikä on IT arkkitehtuuri? Liiketoimintamalli määrittelee IT arkkitehtuurin IT arkkitehtuuri ottaa kantaa sovelluksen laadullisiin vaatimuksiin

Lisätiedot

Tiedonhallinnan perusteet. H11 Ovien ja kulun valvontajärjestelmän tietokanta

Tiedonhallinnan perusteet. H11 Ovien ja kulun valvontajärjestelmän tietokanta Tiedonhallinnan perusteet H11 Ovien ja kulun valvontajärjestelmän tietokanta Nimi: Mikko Haapanen Opiskelijanumero: 0900568 Ryhmä: T09L Työ tehty: 15.3.2010 Mikko Haapanen 15.3.2010 1(7) 1. Asiakasvaatimukset

Lisätiedot

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000

Case TUHTI. Projektin tunnuslukuja. ! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999. ! Java luokkia n. 5000 Case TUHTI 17.12.2002 1 TietoEnator 2002 Projektin tunnuslukuja! Suuri perusjärjestelmäuudistus! Työt alkoivat kesällä 1999! Otettu tuotantokäyttöön syksyllä 2001! Proof of Concept (5 henkilöä 4 kk) ->

Lisätiedot

ecome Markkinoiden kehittynein julkaisujärjestelmä

ecome Markkinoiden kehittynein julkaisujärjestelmä ecome Ecome Finland Oy Itämerenkatu 3 p. 020 7749 580 00180 Helsinki p. 020 7749 585 Suomi - Finland ecome@ecome.fi y. 2193874-3 www.ecome.fi Ecome-järjestelmä pähkinänkuoressa Ecome on suomalaisen yhtiön

Lisätiedot

Sovellusarkkitehtuurit

Sovellusarkkitehtuurit HELIA TiKo-05 1 (9) Sovellusarkkitehtuurit ODBC (Open Database Connectivity)... 2 JDBC (Java Database Connectivity)... 5 Middleware... 6 Middleware luokittelu... 7 Tietokanta -middleware... 8 Tapahtumamonitorit

Lisätiedot

Fyysinen suunnittelu

Fyysinen suunnittelu Informaatioteknologian instituutti IIO30100 Tietokantojen suunnittelu Fyysinen suunnittelu kirjan Hovi, Huotari, Lahdenmäki: Tietokantojen suunnittelu & indeksointi, Docendo (2003, 2005) luvusta 9 Jouni

Lisätiedot

Insert lauseella on kaksi muotoa: insert into taulu [(sarakenimet)] values (arvot)

Insert lauseella on kaksi muotoa: insert into taulu [(sarakenimet)] values (arvot) SQL sisältää operaatiot tietokannan sisällön muodostamiseen ja ylläpitoon: insert - uusien rivien vienti tauluun delete - rivien poisto update - rivien muutos 1 Insert lauseella on kaksi muotoa: insert

Lisätiedot

StanForD-XML. Juha-Antti Sorsa, Tapio Räsänen, Vesa Imponen

StanForD-XML. Juha-Antti Sorsa, Tapio Räsänen, Vesa Imponen Projektiryhmä StanForD-XML Juha-Antti Sorsa, Tapio Räsänen, Vesa Imponen Rahoittajat Koskitukki Oy, Metsähallitus, Metsäliitto Osuuskunta, Pölkky Oy, Stora Enso Oyj, UPM- Kymmene Oyj, Vapo Timber Oy, Yksityismetsätalouden

Lisätiedot

Copyright Observis Oy All rights reserved. Observis Oy Ville Kanerva, CTO Heikki Isotalus, COO Datasta tietoa

Copyright Observis Oy All rights reserved. Observis Oy Ville Kanerva, CTO Heikki Isotalus, COO Datasta tietoa Observis Oy Ville Kanerva, CTO Heikki Isotalus, COO Datasta tietoa Platform Tuotekehityksen haasteita ja ratkaisuja Haaste: Massiivisten tietomäärien hallinta Ratkaisu: Pilvipalvelun skaalautuvuus Haaste:

Lisätiedot

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä

Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Oliosuunnitteluesimerkki: Yrityksen palkanlaskentajärjestelmä Matti Luukkainen 10.12.2009 Tässä esitetty esimerkki on mukaelma ja lyhennelmä Robert Martinin kirjasta Agile and Iterative Development löytyvästä

Lisätiedot

KODAK EIM & RIM VIParchive Ratkaisut

KODAK EIM & RIM VIParchive Ratkaisut ATK Päivät 2006 Mikkeli KODAK EIM & RIM VIParchive Ratkaisut 29.-30.5. 2006 Stefan Lindqvist HCIS Sales Specialist Health Care Information Systems Kodak Health Group 3/24/2013 1 Arkistoinnin haasteita

Lisätiedot

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus

Ohjelmistotuotanto vs. muut insinööritieteet. (Usein näennäinen) luotettavuus ja edullisuus Yhteenveto Ohjelmistotuotanto vs. muut insinööritieteet Monimutkaisuus Näkymättömyys (Usein näennäinen) luotettavuus ja edullisuus Muunnettavuus Epäjatkuvuus virhetilanteissa Skaalautumattomuus Copyright

Lisätiedot

VAATIMUSMÄÄRITTELY Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 4)

VAATIMUSMÄÄRITTELY Virtuaaliyhteisöjen muodostaminen Versio 1.0 (luonnos 4) VAATIMUSMÄÄRITTELY Versio 1.0 (luonnos 4) Edited by Checked by Approved by Juha Parhankangas Luonnos 4 i Sisällysluettelo DOKUMENTIN VERSIOT 1 1. JOHDANTO 2 1.1. Projektin luonne 2 1.2. Tarkoitus ja kattavuus

Lisätiedot

Kertaus: yleistys-erikoistus ja perintä

Kertaus: yleistys-erikoistus ja perintä Kertaus: yleistys-erikoistus ja perintä Nauta, Lehmä ja Kuttu ovat Kotieläimiä, Kotieläimet Eläimiä Kotieläimillä (siis myös Naudoilla, Lehmillä ja Kutuilla) on Omistaja Kuttu ja Lehmä toteuttavat rajapinnan

Lisätiedot

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT

IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT IT-OSAAJA, TIETOJENKÄSITTELYN ERIKOISTUMISOPINNOT KOULUTUKSEN KOHDERYHMÄ SISÄLTÖ Koulutuksen tavoitteena on antaa opiskelijalle valmiudet uusien tietoteknisten menetelmien ja välineiden hyödyntämiseen.

Lisätiedot

Esimerkkiprojekti. Mallivastauksen löydät Wroxin www-sivuilta. Kenttä Tyyppi Max.pituus Rajoitukset/Kommentit

Esimerkkiprojekti. Mallivastauksen löydät Wroxin www-sivuilta. Kenttä Tyyppi Max.pituus Rajoitukset/Kommentit Liite E - Esimerkkiprojekti E Esimerkkiprojekti Olet lukenut koko kirjan. Olet sulattanut kaiken tekstin, Nyt on aika soveltaa oppimiasi uusia asioita pienen, mutta täydellisesti muotoiltuun, projektiin.

Lisätiedot

Haaga-Helia HeTi-09 1 (20) Outi Virkki, Tiina Mikkola ICT05 Tiedonhallinta ja tietokannat 14.1.2010. Johdanto

Haaga-Helia HeTi-09 1 (20) Outi Virkki, Tiina Mikkola ICT05 Tiedonhallinta ja tietokannat 14.1.2010. Johdanto Haaga-Helia HeTi-09 1 (20) Johdanto Tieto yrityksessä... 2 Tietojen käsittely... 3 Tietojärjestelmä... 4 Tietovarasto... 5 Tietovarasto tietokoneella = Tiedosto... 6 Tietokanta ja tietokannan hallintajärjestelmä...

Lisätiedot

(5) Tentin maksimipistemaara on 40 pistetta. Kaikki vastaukset naihin tehtavapapereihin.

(5) Tentin maksimipistemaara on 40 pistetta. Kaikki vastaukset naihin tehtavapapereihin. (5) VAASAN YLIOPISTO (TITE,1021) Tentti 10.1.2013 Teemu Saari Nimi: Opiskelijanumero: Pisteet: + + + Yiit: /40 Arv. Tentin maksimipistemaara on 40 pistetta. Kaikki vastaukset naihin tehtavapapereihin.

Lisätiedot

ECDL Tietokannat. Copyright 2015 ECDL Foundation ECDL Tietokannat Sivu 1 / 7

ECDL Tietokannat. Copyright 2015 ECDL Foundation ECDL Tietokannat Sivu 1 / 7 ECDL Tietokannat Copyright 2015 ECDL Foundation ECDL Tietokannat Sivu 1 / 7 Tavoite Tässä esitellään tutkintovaatimukset moduulille ECDL Tietokannat, joka määrittelee tarvittavat tiedot ja taidot näyttökokeen

Lisätiedot

Navistools Standard. Navistools

Navistools Standard. Navistools Navistools Standard Navistools on Naviswork pohjainen Asset management sovellus, jota käytetään laitoksen, infrakohteen tai rakennuksen elinkaarenaikasen tiedonhallintaan, suunnittelusta työmaavaiheen

Lisätiedot

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1

Ohjelmistoarkkitehtuurit Syksy 2009 TTY Ohjelmistotekniikka 1 3. Komponentit ja rajapinnat 3.1 Komponenttien idea: ohjelmistotuotannon rationalisointi 3.2 Mikä on ohjelmistokomponentti? 3.3 Komponentit ohjelmistoyksikköinä 3.4 Rajapinnat 3.6 Komponenttien räätälöinti

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat

Järjestelmäarkkitehtuuri (TK081702) Avoimet web-rajapinnat Järjestelmäarkkitehtuuri (TK081702) SOA yleistyvät verkkopalveluissa Youtube Google... Avaavat pääsyn verkkopalvelun sisältöön. Rajapintojen tarjoamia tietolähteitä yhdistelemällä luodaan uusia palveluja,

Lisätiedot

Lomalista-sovelluksen määrittely

Lomalista-sovelluksen määrittely Thomas Gustafsson, Henrik Heikkilä Lomalista-sovelluksen määrittely Metropolia Ammattikorkeakoulu Insinööri (AMK) Tietotekniikka Dokumentti 14.10.2013 Tiivistelmä Tekijä(t) Otsikko Sivumäärä Aika Thomas

Lisätiedot

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa

Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa 1 Hyvin määritelty on puoliksi tehty kuinka vältetään turha tekeminen jo alussa Passion leads to design, design leads to performance, performance leads to SUCCESS! OLLI NIEMI Yoso Oy Mitä määrittelyltä

Lisätiedot

UML- mallinnus: Tilakaavio

UML- mallinnus: Tilakaavio UML- mallinnus: Tilakaavio Karkea kuvaus UML- kaavioiden käytöstä ohjelmistonkehityksen eri vaiheissa ja tehtävissä. Mallinnus tilakaavioilla Tilakaaviolla kuvataan yhden luokan olioiden tilan muuttumista

Lisätiedot

Luku 7 Uusien Mallien Tiedostot

Luku 7 Uusien Mallien Tiedostot Luku 7 Uusien Mallien Tiedostot Kaikki ZoomTextin asetukset voidaan tallentaa ja palauttaa käyttämällä mallitiedostoja. Mallitiedostot kontrolloivat kaikkia ZoomTextin toimintoja mukaan lukien suurennustasot,

Lisätiedot

1. Olio-ohjelmointi 1.1

1. Olio-ohjelmointi 1.1 1. Olio-ohjelmointi 1.1 Sisällys Olio-ohjelmointi on eräs ohjelmointiparadigma. Olio-ohjelmoinnin muotoja. Ohjelmiston analyysi ja suunnittelu. Olioparadigman etuja ja kritiikkiä. 1.2 Ohjelmointiparadigmoja

Lisätiedot

HARJOITUS 2. Kasvattamot ja mittaukset

HARJOITUS 2. Kasvattamot ja mittaukset HARJOITUS 2. Tehtävä 1 Alla on esitetty relaatiotietokannan taulujen rakenne. Mitä ongelmia tähän tietokantaan liittyy jos se yritettäisiin ottaa käyttöön sellaisenaan? Korjaa puutteet ja esitä toimiva

Lisätiedot

MatTaFi projektin HAKA-pilotti

MatTaFi projektin HAKA-pilotti projektin HAKA-pilotti Matti Harjula matti.harjula@hut.fi Matematiikan ja systeemianalyysin laitos Teknillinen korkeakoulu 15. tammikuuta 2008 1 2 Materiaalin tuottajat ongelmana 3 Uusien sovellusten yksinkertaisempi

Lisätiedot

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät

T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät T-76.611 Ohjelmistojen määrittely- ja suunnittelumenetelmät Software design and specification methods Kurssin henkilökunta ja sponsori Luennoitsija DI Antti Karanta, Napa Oy www.napa.fi Assistentti TkL

Lisätiedot

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services

Järjestelmäarkkitehtuuri (TK081702) Web Services. Web Services Järjestelmäarkkitehtuuri (TK081702) Standardoidutu tapa integroida sovelluksia Internetin kautta avointen protokollien ja rajapintojen avulla. tekniikka mahdollista ITjärjestelmien liittämiseen yrityskumppaneiden

Lisätiedot

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon

582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 582104 Ohjelmistojen mallintaminen, Johdatus ohjelmistotuotantoon 1 Lyhyt johdatus ohjelmistotuotantoon Ohjelmistotuotanto, ohjelmistoprojektit Miten ohjelmistojen tuottaminen eroaa teollisesta tuotannosta

Lisätiedot

582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus

582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus 582203 Tietokantasovellus (4 op) - Web-sovellukset ja niiden toteutus Sisältö Mikä on web-sovellus? Selaimen rooli web-sovelluksessa Palvelimen rooli web-sovelluksessa Aineistopyynnöt Tiedon välittäminen

Lisätiedot

Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut

Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut Tietojärjestelmä uusiksi? Toimijaverkostot, niiden haasteet ja ratkaisut Samuli Pekkola Aki Alanne Taru Salmimaa Novi Research Center Tampereen teknillinen yliopisto Sisältö tausta, motiivi ja konteksti

Lisätiedot

TIETOKANTOJEN PERUSTEET MARKKU SUNI

TIETOKANTOJEN PERUSTEET MARKKU SUNI TIETOKANTOJEN PERUSTEET MARKKU SUNI SQL - KIELI TIETOJEN MUOKKAUS MARKKU SUNI Tarkastellaan tauluissa olevien tietojen muokkausta muokkauskäskyjä: INSERT UPDATE DELETE Kysymys kuuluu: Voiko tietoja muokata

Lisätiedot

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013

Pertti Pennanen DOKUMENTTI 1 (5) EDUPOLI ICTPro1 29.10.2013 Virtualisointi Pertti Pennanen DOKUMENTTI 1 (5) SISÄLLYSLUETTELO Virtualisointi... 2 Virtualisointiohjelmia... 2 Virtualisointitapoja... 2 Verkkovirtualisointi... 2 Pertti Pennanen DOKUMENTTI 2 (5) Virtualisointi

Lisätiedot

ETAPPI ry JOOMLA 2.5 Mediapaja. Artikkeleiden hallinta ja julkaisu

ETAPPI ry JOOMLA 2.5 Mediapaja. Artikkeleiden hallinta ja julkaisu ETAPPI ry JOOMLA 2.5 Artikkeleiden hallinta ja julkaisu ETAPPI ry JOOMLA 2.5 Sivu 1(16) Sisällysluettelo 1 Joomla! sivuston sisällöntuotanto... 2 2 Artikkeleiden julkaisu sivustolla... 4 3 Artikkelin julkaisemista

Lisätiedot

Taltioni teknisen alustan arviointi

Taltioni teknisen alustan arviointi Taltioni teknisen alustan arviointi Taltioni sidosryhmätilaisuus, 10.1.2012 Jaakko Lähteenmäki, Niilo Saranummi 1/11/2012 2 Selvitystyön kohde Selvitystyö: VTT & Fujitsu Keskeiset vaatimukset Taltioni-palvelulle?

Lisätiedot

Pilvi 9.0. Arkkitehtuuri. Esimerkki arkkitehtuurit

Pilvi 9.0. Arkkitehtuuri. Esimerkki arkkitehtuurit Esimerkki arkkitehtuurit Sivu 2/8 Sisällysluettelo 1. Johdanto... 3 1.1. Termejä... 3 2. Web hosting ilman kuormantasausta... 4 3. Web hosting kuormatasaus ja bastion... 5 3.1.... 5 3.2. Kuvaus... 5 4.

Lisätiedot

KÄSITEANALYYSI PROSESSINA JA TARVEANALYYSI

KÄSITEANALYYSI PROSESSINA JA TARVEANALYYSI TIETOJEN MALLINNUS KÄSITEANALYYSI PROSESSINA JA TARVEANALYYSI HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 3 S. 68 73 JA LUKU 4 (S. 79 84) JOUNI HUOTARI

Lisätiedot

Tapahtuipa Testaajalle...

Tapahtuipa Testaajalle... Tapahtuipa Testaajalle... - eli testaus tosielämässä 09.10.2007 Juhani Snellman Qentinel Oy 2007 Agenda Minä ja mistä tulen Testauksen konteksti Tapauksia tosielämästä ja työkaluja 2 Minä Juhani Snellman

Lisätiedot

Relaatiotietokantojen perusteista. Harri Laine Helsingin yliopisto

Relaatiotietokantojen perusteista. Harri Laine Helsingin yliopisto Harri Laine Helsingin yliopisto Suosion syy? Yksinkertaisuus vähän käsitteitä helppo hahmottaa Selkeä matemaattinen perusta ei tulkintaongelmia kuten esim. UML:ssä teoria käytäntö kaavio: R(A 1 :D 1, A

Lisätiedot

HSMT J2EE & EJB & SOAP &...

HSMT J2EE & EJB & SOAP &... HSMT J2EE & EJB & SOAP &... Ville Leppänen HSMT, c Ville Leppänen, IT, Turun yliopisto, 2011 p.1/15 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista

Lisätiedot

ohjelman arkkitehtuurista.

ohjelman arkkitehtuurista. 1 Legacy-järjestelmällä tarkoitetaan (mahdollisesti) vanhaa, olemassa olevaa ja käyttökelpoista ohjelmistoa, joka on toteutettu käyttäen vanhoja menetelmiä ja/tai ohjelmointikieliä, joiden tuntemus yrityksessä

Lisätiedot

Laaja-alainen, opiskelijalähtöinen ja projektiperusteinen opetussuunnitelma, case Monitori

Laaja-alainen, opiskelijalähtöinen ja projektiperusteinen opetussuunnitelma, case Monitori Laaja-alainen, opiskelijalähtöinen ja projektiperusteinen opetussuunnitelma, case Monitori Insinöörikoulutuksen Foorumi 2012 Seminaariesitelmä Timo Turunen ja Matti Welin Monitori koulutusalarajat ylittävä

Lisätiedot