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

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys

Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Ohjelmistojen mallintamisen ja tietokantojen perusteiden yhteys Tällä kurssilla on tutustuttu ohjelmistojen mallintamiseen oliomenetelmiä ja UML:ää käyttäen Samaan aikaan järjestetyllä kurssilla on käsitelty

Lisätiedot

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

Helsingin yliopisto/tktl DO Tietokantojen perusteet, s 2000 Johdanto & yleistä Harri Laine 1. Tietokanta. Tiedosto

Helsingin yliopisto/tktl DO Tietokantojen perusteet, s 2000 Johdanto & yleistä Harri Laine 1. Tietokanta. Tiedosto Tietokanta Tiedosto Tietokanta (database) jotakin käyttötarkoitusta varten laadittu kokoelma toisiinsa liittyviä säilytettäviä tietoja Ohjelmointikielissä apumuistiin tallennettuja tietoja käsitellään

Lisätiedot

TIEDONHALLINTA - SYKSY Luento 7. Pasi Ranne /10/17 Helsinki Metropolia University of Applied Sciences

TIEDONHALLINTA - SYKSY Luento 7. Pasi Ranne /10/17 Helsinki Metropolia University of Applied Sciences TIEDONHALLINTA - SYKSY 2017 Kurssikoodi: Saapumisryhmä: Luento 7 TX00CN57-3001 TXQ16ICT, TXQ16S1 ja TXQ16PROS Pasi Ranne 02.10.2017 1/10/17 Helsinki Metropolia University of Applied Sciences 1 Tietokannan

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

Ohjelmistojen mallintaminen, mallintaminen ja UML

Ohjelmistojen mallintaminen, mallintaminen ja UML 582104 Ohjelmistojen mallintaminen, mallintaminen ja UML 1 Mallintaminen ja UML Ohjelmistojen mallintamisesta ja kuvaamisesta Oliomallinnus ja UML Käyttötapauskaaviot Luokkakaaviot Sekvenssikaaviot 2 Yleisesti

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

Ohjelmistojen suunnittelu

Ohjelmistojen suunnittelu Ohjelmistojen suunnittelu 581259 Ohjelmistotuotanto 154 Ohjelmistojen suunnittelu Software design is a creative activity in which you identify software components and their relationships, based on a customer

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

Luento 3 Tietokannan tietosisällön suunnittelu

Luento 3 Tietokannan tietosisällön suunnittelu HAAGA-HELIA / Heti-09 1 (17) Luento 3 Tietokannan tietosisällön suunnittelu Tietojärjestelmän suunnitteluprosessi... 2 Tietokannan suunnittelun tavoitteet... 3 Tietokannan suunnitteluprosessi... 4 Käsitteellinen

Lisätiedot

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu

HELIA 1 (8) Outi Virkki Tietokantasuunnittelu HELIA 1 (8) Luento 1 Johdatusta tietokannan suunnitteluun... 2 Tietokantasuunnittelu?... 2 Tietokanta?... 2 Tieto?... 2 Tietokantasuunnittelun tavoite, v.1... 2 Luotettavuus?... 3 Tietokantasuunnittelun

Lisätiedot

TIEDONHALLINNAN PERUSTEET - SYKSY 2013

TIEDONHALLINNAN PERUSTEET - SYKSY 2013 TIEDONHALLINNAN PERUSTEET - SYKSY 2013 Kurssikoodi: Saapumisryhmä: Luento 4 XX00AA79-3013 TU12S2 Pasi Ranne 11.9.2013 11/9/13 Helsinki Metropolia University of Applied Sciences 1 Relaatiotietokannan suunnitteluprosessin

Lisätiedot

HELIA 1 (17) Outi Virkki Tiedonhallinta

HELIA 1 (17) Outi Virkki Tiedonhallinta HELIA 1 (17) Luento 4.1 Looginen suunnittelu... 2 Relaatiomalli... 3 Peruskäsitteet... 4 Relaatio... 6 Relaatiokaava (Relation schema)... 6 Attribuutti ja arvojoukko... 7 Monikko... 8 Avaimet... 10 Avain

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

Johdanto. Kiinteistöhuoltoyhtiö tarvitsee järjestelmän huoltopyyntöjen hallinnointiin

Johdanto. Kiinteistöhuoltoyhtiö tarvitsee järjestelmän huoltopyyntöjen hallinnointiin 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?

Lisätiedot

Tietokannan suunnittelu

Tietokannan suunnittelu HELIA TIKO-05 1 (12) ICT03D Tieto ja tiedon varastointi Tietokannan suunnittelu Tietokannan suunnitteluprosessi... 2 Tavoitteet...2 Tietojärjestelmän suunnitteluprosessi...3 Abstraktiotasot tietokannan

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

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

Tietokannan hallinta. Kevät 2004 Jan Lindström R&G Chapter 1

Tietokannan hallinta. Kevät 2004 Jan Lindström R&G Chapter 1 Tietokannan hallinta Kevät 2004 Jan Lindström R&G Chapter 1 Tietokannan hallinta 1. Johdanto (käsitteitä) 2. Tietokannan talletusrakenteet 3. Tietokannan hakemistorakenteet 4. Kyselyiden käsittely ja optimointi

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

HOJ Haja-aiheita. Ville Leppänen. HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/10

HOJ Haja-aiheita. Ville Leppänen. HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/10 HOJ Haja-aiheita Ville Leppänen HOJ, c Ville Leppänen, IT, Turun yliopisto, 2012 p.1/10 Missä mennään... 1. Johdanto (1h) 2. Säikeet (2h) 3. Samanaikaisuudesta (2h) 4. Hajautetuista sovelluksista (1h)

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

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

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

Tietokantakurssit / TKTL

Tietokantakurssit / TKTL Tietokantakurssit / TKTL Tietokantojen perusteet - tietokannan käyttö: SQL, sovellukset Tietokannan hallinta - tietokannanhallintajärjestelmän ominaisuuksia: tallennusrakenteet kyselyjen toteutus tapahtumien

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

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

Tietomallit. Näkökulmat tietoon. Näkökulmat tietoon. Näkökulmat tietoon. Abstraktiotasot tiedon käsittelyssä

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

Lisätiedot

2. Olio-ohjelmoinnin perusteita 2.1

2. Olio-ohjelmoinnin perusteita 2.1 2. Olio-ohjelmoinnin perusteita 2.1 Sisällys Esitellään peruskäsitteitä yleisellä tasolla: Luokat ja oliot. Käsitteet, luokat ja oliot. Attribuutit, olion tila ja identiteetti. Metodit ja viestit. Olioperustainen

Lisätiedot

Ohjelmistotekniikan menetelmät, UML

Ohjelmistotekniikan menetelmät, UML 582101 - Ohjelmistotekniikan menetelmät, UML 1 Sisältö DFD- ja sidosryhmäkaavioiden kertaus Oliomallinnus UML:än kaaviotyypit 2 Tietovuokaaviot Data flow diagrams, DFD Historiallisesti käytetyin kuvaustekniikka

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

Tietokantasuunnittelun pääperiaatteena on tiedon toiston välttäminen. Tiedon toistumiseen liittyy monenlaisia ongelmia.

Tietokantasuunnittelun pääperiaatteena on tiedon toiston välttäminen. Tiedon toistumiseen liittyy monenlaisia ongelmia. Tietokantasuunnittelusta Tietokantasuunnittelun pääperiaatteena on tiedon toiston välttäminen. Tiedon toistumiseen liittyy monenlaisia ongelmia toistuva tieto vie tilaa ylläpito muodostuu hankalaksi ylläpito-operaatioilla

Lisätiedot

On autoja, henkilöitä, Henkilöllä on nimi Autolla on omistaja, joka on henkilö. Taulu AUTO(rekno, malli) Taulu HENKILO(nimi, )

On autoja, henkilöitä, Henkilöllä on nimi Autolla on omistaja, joka on henkilö. Taulu AUTO(rekno, malli) Taulu HENKILO(nimi, ) 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

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

TIEDONHALLINTA - SYKSY Luento 2. Pasi Ranne /8/17 Helsinki Metropolia University of Applied Sciences

TIEDONHALLINTA - SYKSY Luento 2. Pasi Ranne /8/17 Helsinki Metropolia University of Applied Sciences TIEDONHALLINTA - SYKSY 2017 Kurssikoodi: Saapumisryhmä: Luento 2 TX00CN57-3001 TXQ16ICT, TXQ16S1 ja TXQ16PROS Pasi Ranne 28.8.2017 27/8/17 Helsinki Metropolia University of Applied Sciences 1 Oppitunnin

Lisätiedot

POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN

POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN POLKU LUOKKAKAAVIOISTA TAULUJEN TOTEUTUKSEEN KIRJAN HOVI, HUOTARI, LAHDENMÄKI: TIETOKANTOJEN SUUNNITTELU & INDEKSOINTI DOCENDO (2003, 2005) LUKU 7 JOUNI HUOTARI & ARI HOVI IIO30100 TIETOKANTOJEN SUUNNITTELU

Lisätiedot

Ohjelmistojen mallintaminen kertausta Harri Laine 1

Ohjelmistojen mallintaminen kertausta Harri Laine 1 kertausta 5.12.2008 Harri Laine 1 Ohjelmiston elinkaari, elinkaarimallit Yleinen puitemalli (reference model) - abstrakti kokonaiskuva ei etenemiskontrollia, ei yksityiskohtia Ohjelmistoprosessimallit

Lisätiedot

Action Request System

Action Request System Action Request System Manu Karjalainen Ohjelmistotuotantovälineet seminaari HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos 25.10.2000 Action Request System (ARS) Manu Karjalainen Ohjelmistotuotantovälineet

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

Projektinhallintaa paikkatiedon avulla

Projektinhallintaa paikkatiedon avulla Projektinhallintaa paikkatiedon avulla Tampereen Teknillinen Yliopisto / Porin laitos Teemu Kumpumäki teemu.kumpumaki@tut.fi 25.6.2015 1 Paikkatieto ja projektinhallinta Paikkatiedon käyttäminen projektinhallinnassa

Lisätiedot

UML:n yleiskatsaus. UML:n osat:

UML:n yleiskatsaus. UML:n osat: UML:n yleiskatsaus - voidaan hyödyntää hyvin laajasti. - sopii liiketoimintamallinnukseen, ohjelmistomallinnukseen sen jokaiseen vaiheeseen tai minkä tahansa pysyviä ja muuttuvia ominaisuuksia sisältävän

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

Tietokanta (database)

Tietokanta (database) Tietokanta Tietokanta (database) jotakin käyttötarkoitusta varten laadittu kokoelma toisiinsa liittyviä säilytettäviä tietoja 1 Tiedosto Ohjelmointikielissä apumuistiin tallennettuja tietoja käsitellään

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

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

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

Helsingin yliopisto/tktl Tietokantojen perusteet, k 2003 Relaatiomallin peruskäsitteet Harri Laine 1. Tietomallit. Näkökulmat tietoon

Helsingin yliopisto/tktl Tietokantojen perusteet, k 2003 Relaatiomallin peruskäsitteet Harri Laine 1. Tietomallit. Näkökulmat tietoon Tietomallit Tietomallilla (data model) tarkoitetaan tiedon rakenteen ja tiedolle suoritettavan käsittelyn määrittelevää käsitteistöä Tietoa voidaan tarkastella eri näkökulmista - eri abstraktiotasoilla

Lisätiedot

Ohjelmistojen mallintaminen Tietovuokaaviot Harri Laine 1

Ohjelmistojen mallintaminen Tietovuokaaviot Harri Laine 1 Ohjelmistojen mallintaminen Tietovuokaaviot 3.11.2008 Harri Laine 1 t Data flow diagrams Pohjana systeemiteoreettinen järjestelmämalli Input system output Järjestelmän tehtävä on muokata lähtötiedoista

Lisätiedot

millainen on se kohde, jota tiedoilla pitäisi kuvata asiat, joita pitäisi esittää Mitä tietoelementtien arvot tarkoittavat

millainen on se kohde, jota tiedoilla pitäisi kuvata asiat, joita pitäisi esittää Mitä tietoelementtien arvot tarkoittavat Tietomallit Tietomallilla (data model) tarkoitetaan tiedon rakenteen ja tiedolle suoritettavan käsittelyn määrittelevää käsitteistöä Tietoa voidaan tarkastella eri näkökulmista - eri abstraktiotasoilla

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

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

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

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

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki

Malliperustainen ohjelmistokehitys - MDE Pasi Lehtimäki Malliperustainen ohjelmistokehitys - MDE 25.9.2007 Pasi Lehtimäki MDE Miksi MDE? Mitä on MDE? MDA, mallit, mallimuunnokset Ohjelmistoja Eclipse, MetaCase Mitä jatkossa? Akronyymiviidakko MDE, MDA, MDD,

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

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

Ohjelmistojen mallintaminen, kesä 2010

Ohjelmistojen mallintaminen, kesä 2010 582104 Ohjelmistojen mallintaminen, kesä 2010 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

Helsingin yliopisto/tktl DO Tietokantojen perusteet, s 2000 Relaatiomallin peruskäsitteet Harri Laine 1. Relaatiotietokannat DONOTP

Helsingin yliopisto/tktl DO Tietokantojen perusteet, s 2000 Relaatiomallin peruskäsitteet Harri Laine 1. Relaatiotietokannat DONOTP RINT THIS DOCUM ENT Relaatiotietokannat DONOTP Relaatiomalli Perustana rakennetason tietomalli relaatiomalli (the relational model of data) perusteoria: Codd 1970 ensimmäiset kaupalliset toteutukset 70-luvun

Lisätiedot

Oliotietokannat. Nääsvillen Oliopäivät Pekka Kähkipuro Kehitysjohtaja, FT

Oliotietokannat. Nääsvillen Oliopäivät Pekka Kähkipuro Kehitysjohtaja, FT Oliotietokannat Nääsvillen Oliopäivät 2004 15.12.2004 Pekka Kähkipuro Kehitysjohtaja, FT pekka.kahkipuro@sysopen.fi Oliotietokanta Idea: pysyvän tiedon tallentaminen suoraan oliomuodossa Tietosisältö ja

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

TIETOKANNAT: MYSQL & POSTGRESQL Seminaarityö

TIETOKANNAT: MYSQL & POSTGRESQL Seminaarityö TIETOKANNAT: MYSQL & POSTGRESQL Seminaarityö Tekijät: Eemeli Honkonen Joni Metsälä Työ palautettu: SISÄLLYSLUETTELO: 1 SEMINAARITYÖN KUVAUS... 3 2 TIETOKANTA... 3 2.1 MITÄ TIETOKANNAT SITTEN OVAT?... 3

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

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

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

HELIA 1 (21) Outi Virkki Tietokantasuunnittelu

HELIA 1 (21) Outi Virkki Tietokantasuunnittelu HELIA 1 (21) Luento 4.1 Oliot ja Relaatiot... 2 Relaatiomalli... 2 Oliomalli... 2 Termejä... 4 Yhteensovituksen 3 tapaa... 5 1) Oliot relaatioina / tauluina ja RDBMS... 6 Olioluokka... 7 Olion identiteetti...

Lisätiedot

UML-kielen formalisointi Object-Z:lla

UML-kielen formalisointi Object-Z:lla UML-kielen formalisointi Object-Z:lla Kalvot ja seminaarityö WWW:ssä: http://users.jyu.fi/~minurmin/opiskelu/form/ UML UML == Unified Modelling Language. OMG:n standardoima kieli ohjelmistojärjestelmien,

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

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

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

Tietokantojen perusteet k2004helsingin yliopisto/tktl Tietokantojen perusteet, s 2007 ER-mallin peruskäsitteet.

Tietokantojen perusteet k2004helsingin yliopisto/tktl Tietokantojen perusteet, s 2007 ER-mallin peruskäsitteet. Tietosisällön kuvaaminen Toteutusvälineistä riippumaton tietosisällön kuvaus Entity-Relationship malliperhe Lähtökohta: Chenin malli vuodelta 1976 Useita muunnelmia, pieniä eroja peruskäsitteissä ja erityisesti

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

Tietokantojen perusteet

Tietokantojen perusteet Tietokantojen perusteet Johdanto Jouni Huotari & Ari Hovi 2008 TAUSTAA Yritykselle tiedot ovat tärkeä resurssi päätöksenteon tukena (JIT) varastointi ja käyttö vaativat investointeja vrt. energia (lähde,

Lisätiedot

Ohjelmistojen mallintaminen, kesä 2009

Ohjelmistojen mallintaminen, kesä 2009 582104 Ohjelmistojen mallintaminen, kesä 2009 1 Ohjelmistojen mallintaminen Software Modeling Perusopintojen pakollinen opintojakso, 4 op Esitietoina edellytetään oliokäsitteistön tuntemus Ohjelmoinnin

Lisätiedot

jotakin käyttötarkoitusta varten laadittu kokoelma toisiinsa liittyviä säilytettäviä tietoja

jotakin käyttötarkoitusta varten laadittu kokoelma toisiinsa liittyviä säilytettäviä tietoja Tietokanta Tietokanta (database) jotakin käyttötarkoitusta varten laadittu kokoelma toisiinsa liittyviä säilytettäviä tietoja mikä tahansa tietokokoelma? --> erityispiirteitä Tietokanta vs. tiedosto 1

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

HELIA 1 (14) Outi Virkki Käyttöliittymät ja ohjlmiston suunnittelu

HELIA 1 (14) Outi Virkki Käyttöliittymät ja ohjlmiston suunnittelu HELIA 1 (14) Luento 7 Käyttöliittymäolio... 2 Olioajattelun perusteet... 3 Tavoitteet... 3 Peruskäsitteet... 4 Olio / Olioinstanssi / Olion esiintymä... 4 Ominaisuudet... 4 Toiminnot... 4 Olioluokka /

Lisätiedot

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio

Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi, staattinen mallintaminen, kohdealueen malli ja luokkakaavio Analyysi Tarkentaa ja jäsentää vaatimusmäärittelyä, vastaa kysymykseen MITÄ järjestelmän tulisi tehdä. Suoritetaan seuraavia tehtäviä:

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

TIEDONHALLINNAN PERUSTEET - SYKSY 2013

TIEDONHALLINNAN PERUSTEET - SYKSY 2013 TIEDONHALLINNAN PERUSTEET - SYKSY 2013 Kurssikoodi: Saapumisryhmä: Luento 5 XX00AA79-3013 TU12S2 Pasi Ranne 11.9.2013 11/9/13 Helsinki Metropolia University of Applied Sciences 1 Tietokannan normalisoinnin

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

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus:

Tämän lisäksi listataan ranskalaisin viivoin järjestelmän tarjoama toiminnallisuus: Dokumentaatio, osa 1 Tehtävämäärittely Kirjoitetaan lyhyt kuvaus toteutettavasta ohjelmasta. Kuvaus tarkentuu myöhemmin, aluksi dokumentoidaan vain ideat, joiden pohjalta työtä lähdetään tekemään. Kuvaus

Lisätiedot

Ohjelmistojen mallintaminen

Ohjelmistojen mallintaminen Ohjelmistojen mallintaminen - Mallit - Ohjelmiston kuvaaminen malleilla 31.10.2008 Harri Laine 1 Malli: abstraktio jostain kohteesta Abstrahointi: asian ilmaiseminen tavalla, joka tuo esiin tietystä näkökulmasta

Lisätiedot

Hieman lisää malleista ja niiden hyödyntämisestä

Hieman lisää malleista ja niiden hyödyntämisestä Hieman lisää malleista ja niiden hyödyntämisestä Ohjelmistojen mallintaminen Kesä 2012 (Avoin yliopisto) Toni Ruokolainen, 23.8.2012 Mallit Mallit ovat todellisuuden abstraktioita, jotka on muodostettu

Lisätiedot

Tietokannan eheysrajoitteet ja niiden määrittäminen SQL-kielellä

Tietokannan eheysrajoitteet ja niiden määrittäminen SQL-kielellä hyväksymispäivä arvosana arvostelija Tietokannan eheysrajoitteet ja niiden määrittäminen SQL-kielellä Tuomas Husu Helsinki 20.2.2010 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Sisältö i 1 Johdanto

Lisätiedot

Paikkatietotuotteen määrittely

Paikkatietotuotteen määrittely Paikkatietotuotteen määrittely Työpaja tietotuotteista 24.11.2010 Panu Muhli Maanmittauslaitos Inspire-sihteeristö etunimi.sukunimi@maanmittauslaitos.fi Sisällys Mikä on paikkatietotuote? Mitä paikkatietotuotteen

Lisätiedot

Tietokannan hallintajärjestelmän (DBMS) palvelut ja rakenne

Tietokannan hallintajärjestelmän (DBMS) palvelut ja rakenne HAAGA-HELIA Heti-09 1 (6) Tietokannan hallintajärjestelmän (DBMS) palvelut ja rakenne Tietovarastotekniikan kehittyminen... 2 Tiedostopohjaiset ratkaisut... 2 Tiedoston palvelut... 3 Tiedostopohjaisten

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

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

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

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä

Käyttäjien tunnistaminen ja käyttöoikeuksien hallinta hajautetussa ympäristössä www.niksula.cs.hut.fi/~jjkankaa// Demosovelluksen tekninen määrittely v. 0.6 Päivitetty 11.12.2000 klo 20:26 Mickey Shroff 2 (12) Dokumentin versiohistoria Versio Päivämäärä Tekijä / muutoksen tekijä Selite

Lisätiedot

Luokka- ja oliokaaviot

Luokka- ja oliokaaviot Luokka- ja oliokaaviot - tärkeimmät mallinnuselementit : luokat, oliot ja niiden väliset suhteet - luokat ja oliot mallintavat kuvattavan järjestelmän sisältöä ja niiden väliset suhteet näyttävät, kuinka

Lisätiedot

TIEDONHALLINTA - SYKSY Luento 11. Hannu Markkanen /10/12 Helsinki Metropolia University of Applied Sciences

TIEDONHALLINTA - SYKSY Luento 11. Hannu Markkanen /10/12 Helsinki Metropolia University of Applied Sciences TIEDONHALLINTA - SYKSY 2011 Kurssikoodi: Saapumisryhmä: Luento 11 TU00AA48-2002 TU10S1E Hannu Markkanen 22.11.2011 9/10/12 Helsinki Metropolia University of Applied Sciences 1 Indeksit Indeksit Taulun

Lisätiedot

Kari Aalto Saariston IT

Kari Aalto Saariston IT Saariston IT perustettu helmikuussa 2005 pitkä kokemus koulutuspalveluiden toimittamisesta Suomessa, Euroopassa ja Lähi-Idässä Arvot keskinäinen luottamus ja aito kumppanuus pitkäjänteinen yhteistoiminta,

Lisätiedot

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen

Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 582101 - Ohjelmistotekniikan menetelmät, luokkamallin laatiminen 1 Lähestymistapoja Kokonaisvaltainen lähestymistapa (top-down) etsitään kerralla koko kohdealuetta kuvaavaa mallia hankalaa, jos kohdealue

Lisätiedot

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

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

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

HELIA 1 (14) Outi Virkki Tiedonhallinta

HELIA 1 (14) Outi Virkki Tiedonhallinta HELIA 1 (14) Luento Näkymät... 2 Relaatiotyypit... 2 Taulu - Tallennettu relaatio... 3 Näkymä - Virtuaalirelaatio... 3 Tulosrelaatio - Kyselyn tulos... 3 Otetaulut - Tauluun tallennettu kyselyn tulos...

Lisätiedot