Jedna od posljednjih stvari koja me drži povremeno vezanog za MS Windows je MS Access. Najmanje poznat i najrjeđe korišten dio MS Office paketa na Windowsima, ali nezaobilazan mnogima koji su nakon mukotrpnog dugogodišnjeg spoticanja o Excel u funkciji adresara, cjenika, ili bilo kakve podatkovne evidencije, shvatili da upravo tome služi Access. Excel je odličan analitički alat, ali i vrlo loš za manipulaciju velike količine podataka. Access je, zato, alat koji omogućava izradu relacijske baze podataka, pa čak i aplikacije oko takve baze, svakom onom tko uloži nešto vremena da se nauči njime služiti. Nije namijenjen profesionalnim rješenjima, dosta loše se ponaša u višekorisničkom okruženju (iako čak i to donekle funkcionira) i raspada se ako podataka imamo *stvarno* puno. S druge strane, prekompliciran je za naučiti tako da nikad nije postigao popularnost Excela ili Worda kod individualnih korisnika (iako je neusporedivo efikasniji alat od Excela koji se često koristi za tipične poslovne funkcije jedne male firme - kombinacija adresar-cjenik-ponuda-račun). Međutim, u nekoj "srednjoj" klasi primjena, prejednostavnih da se isplati ulagati u skupo komercijalno rješenje ili pak prespecifičnih da bi kvalitetno komercijalno rješenje uopće postojalo, a opet dovoljno složenih da ulog vremena u učenje može biti isplaćen kroz uštedu vremena u svakodnevnom radu - Access ima svoje vjerne korisnike koji na Windows platformi u njemu vide "zlatnu sredinu" za svoje ne prevelike potrebe. A kakva je situacija na Macu?

Kroz godine svoje inženjerske prakse razvio sam niz alata utemeljenih na relacijskim bazama podataka, koji su mi služili u svakodnevnom radu i štedjeli mi, na godišnjoj razini, stotine i tisuće čovjek-sati. Profesionalni database developeri su mi se uvijek podsmjehivali i isticali brojne nedostatke, ograničenja, boljke i mušice Accessa (koje sam znao bolje od njih), ali pravu alternativu mi nisu nikad znali dati. Ili se, s jedne strane, radilo o skandalozno preskupim ultraprofesionalnim alatima za ogromne baze od desetaka milijuna zapisa i tisuća relacija (što bi za moje potrebe bilo isto kao da idem kupiti kombajn za pokositi travu u svom voćnjaku), ili o opciji da razvijam "from scratch" vlastitu aplikaciju (i potrošim tisuće sati na programiranje GUI funkcionalnosti) temeljenu na opensource rješenjima kao što je MySQL.

Nažalost, s istim sam se problemom suočio i prilikom prijelaza na Mac. Zapravo, problem je bio gori. Jer - na Windowsima sam imao Access (s manama koje sam naučio zaobilaziti, ne prevelikom cijenom, i osrednje teškim za programiranje), a na Macu nisam imao - ništa. To jest, tek sam trebao pronaći nešto. Dijelom zbog nedostatka vremena, dijelom zbog pomanjkanja volje da učim nešto novo, nastavio sam se koristiti Accessom u virtualnim Windowsima, povremeno istražujući moguće opcije na Macu i to je potrajalo, evo, gotovo 4 godine... Svjetlo na kraju tunela se zove FileMaker Pro 12.

No, nije ni taj put bez prepreka. FileMakerPro je bitno skuplji alat. Ali recimo da se u apsolutnim brojevima ipak ne radi o iznosu koji bi bio prevelik, pogotovo s obzirom na bolje mogućnosti koje FMP ima po pitanju veličine baze, broja korisnika i jednostavnosti prebacivanja na web rješenje. Sve to pišem na temelju onog što deklarira proizvođač, s obzirom da još nisam došao toliko daleko da to mogu probati (ali nadam se da hoću). No, i to na stranu, prijelaz je sve samo ne lak. Ne samo da nema nikakvog automatiziranog niti poluautomatiziranog prebacivanja postojećih baza (tome se nisam ni nadao!), nego nema gotovo niti najmanje analogije u načinu razmišljanja, čak se niti terminologija gotovo uopće ne poklapa (osim u onom najnajnajtemeljnijem dijelu koji se uči iz svake fakultetske knjige o relacijskim bazama podataka). Praktički, treba potpuno promijeniti način razmišljanja. Početak je bio vrlo, vrlo težak. Puno teži nego da nisam imao nikad nikakvog iskustva s bazama podataka. Zato sam i odlučio napisati ovaj članak u nastavcima, za one koji odluče krenuti istim putem.

Pogled iz aviona

FMP objavljuje službenu usporednu tablicu Access-FMP. Nažalost, u nju je previše prstiju upleo marketing, a premalo database eksperti i/ili programeri. Razmišljao sam da li da je prenesem kao takvu, ali odustao sam od toga jer je u njoj previše mjesta gdje je istina nategnuta ili se čak ni to ne može reći. Onda bih se osjećao dužan dati objektivan osvrt na tu tablicu, a to bi sve onda otišlo u nekom krivom smjeru, koji nije konstruktivan. Zato sam se radije odlučio osloniti se isključivo na vlastitu usporedbu.

Ono što je svakako ogromna prednost na strani FMP je znatno brža krivulja učenja za potpune početnike koji nemaju pojma o bazama podataka. Korištenjem postojećih predložaka, potpuni database noob može već u nekoliko sati doći do kakve-takve funkcionalne prve verzije svoje baze podataka. U Accessu treba potrošiti najmanje toliko (pod pretpostavkom da korisnik već ima napredno informatičko iskustvo i znanje) na proučavanje koncepta i implementacije relacijskih baza i SQL jezika, a gdje smo još od korištenja gotove aplikacije...

Tvrtka FileMaker (i ne samo oni sami!) ističe kako FMP može "progutati" znatno veće količine podataka od Accessa, a da ne "zaškripi", kako je bitno bolji u mrežnom i višekorisničkom radu te kako je vrlo jednostavno prebacivanje aplikacije u web-aplikaciju. To još nisam imao prilike isprobati, ali nema razloga da im ne vjerujemo. A upravo to su stvari na kojima je Access zaista "tanak". Svaki pokušaj mrežnog korištenja je avantura koja može završiti krahom i gubitkom podataka, a baza s više od 100.000 zapisa postaje čisti ruski rulet...

Međutim, dok je očito "ispod haube" FMP znatno jači, trud da totalnom početniku ponude brze rezultate doveo je do toga da je "u sredini" tipično appleovski osakaćen: "Da, to se ne može. Ne, nema drugog načina. Kako da to napravite? Pa - nikako! Ali to je super, jer vam to ni ne treba! Ne treba vam! To vam ne treba. Ponavljajte za mnom. Ne treba. Ne treba. To vam ne treba...". :-)

SQL? Fuj SQL. U FMP svijetu nitko ne koristi SQL. Zašto, zaboga? Brz je, jednostavan, najmoćniji alat za filtriranje i manipuliranje podacima. Pa, eto, FMP tek od najsvježije verzije 12, od prije nekoliko mjeseci, izravno podržava SQL. Ali ta podrška je još uvijek vrlo rudimentarna, a, još gore, nitko iz FM zajednice ne zna gotovo ništa o SQL-u pa onda niti o tome kako bi ga trebalo koristiti unutar FMP. Dobio sam na jednom od FMP foruma neke maglovite naznake koji su me nakon par dana istraživanja doveli trnovitim putem do uspjeha. I desetke uvjeravanja kako mi to ne treba. :-) Detalji kasnije.

OK, što sa stvarima koje nisu podržane "out of the box"? Što ako nešto treba programirati? Access ima Visual Basic for Applications. Nije neka sreća od jezika, ali je normalni programski jezik. FMP ima mogućnost skriptiranja, koja zapravo više nalikuje izradi makronaredbi, u smislu da je sve povezano sa standardnim elementima korisničkog sučelja i posve je onemogućen izravan pristup podacima. Ali najviše frustrira što skriptu nije moguće napisati, nego isključivo naklikati kroz sporo i kilavo sučelje. Jasno, netko tko nije nikad programirao smatrat će ovo puno boljim, a to je iz aviona jasno da je FMP jako orijentiran na takve korisnike...

Zaključak prvog avionskog pogleda je - FMP je po mnogočemu bolji, po nečem pak neshvatljivo lošiji. Srećom, to nije toliko bitno da ne bi bio itekako upotrebljiv alat. Zato, idemo dalje...

Think different...

O, da. Definitivno. Ako igdje treba ovu maksimu doslovno primijeniti, to je ovaj slučaj. :-) Koncepcija, pristup, temeljne paradigme, sve je posve različito, a neke stvari čak i posve suprotne. Ali, za uvod, počnimo s onim što je isto.

Pregled tablica u Accessu

Pregled tablica u FileMakeru

Tablice (eng. table) i njihove međusobne relacije (eng. relationship) definiraju se na takav način da se niti jedan podatak ne ponavlja. Odnosno, ako se neki podatak ponavlja, on treba biti izvučen u drugu tablicu i relacijski povezan s onom prvom. To se onda zove "baza podataka". Puno sam puta sretao ljude koji se svakodnevno bore s monstruoznom Excel tablicom od 30-40 stupaca i 10.000+ redaka i zovu je "naša baza podataka" - i svaki sam se put susprezao da im ne krenem objašnjavati da to *nije* "baza podataka". A zašto nije? Pa evo školskog primjera. Imamo tablicu zaposlenika u firmi koja se zove vrlo neočekivano - "Zaposlenici" :-). Svaki redak u toj tablici (u database terminologiji kaže se zapis, odnosno record na engleskom) odnosi se na jednog zaposlenika. Svaki stupac u toj tablici (zove se polje, odnosno field na engleskom) predstavlja jedan podatak o tom zaposleniku. Neki od tih podataka (polja) su bitniji, jer se po njima pretražuje zaposlenike. To su ključevi (eng. key). Ključevi mogu biti npr. OIB, prezime, stručna sprema, itd. Barem jedan od ključeva bi trebao biti jedinstven (takav da je sigurno različit za svakog zaposlenika) - to bi npr. mogao biti OIB - pa se taj onda zove primarni ključ (eng. primary key). E, sad, jedno od polja u tablici zaposlenika je npr. Ulica, u kojem se čuva ime ulice - što predstavlja dio adrese prebivališta zaposlenika. Naravno, moguće je da više zaposlenika živi u istoj ulici. Na primjer ovako:

Svašta se može sad s tom ulicom dogoditi. U Excel tzv. "bazama podataka" je najčešći problem što jednom piše "Cvjetna", drugi put "Cvjetna ul.", treći put "Cvjetna ulica", četvrti "Cvijetna ul.", a nađe se i makar jedna "Cvjenta". :-) Pa ti nađi koliko imaš zaposlenika koji žive u toj Cvjetnoj ulici. Ali lako za to. Što ako lokalna samouprava odluči promijeniti ime Cvjetne ulice u "Ulica tratinčica"? Ili, još gore, ako odluči *dio* Cvjetne ulice, od kućnog broja 15 na dalje, odnosno 8 na dalje s lijeve strane, preimenovati u "Ulicu tratinčica"?

E, upravo zato se formira nova tablica, koju možemo nazvati "Ulice". Koja može izgledati ovako:

(Usput, da, pogađate - idući korak je da napravimo tablicu "Gradovi" koja... :-) )

Definicija tablice u Accessu

Definicija tablice u Filemakeru

E, sad, što s tim. Pa jednostavno, u tablici zaposlenici, u polje "Ulica", umjesto imena ulice upisujemo primarni ključ one ulice u kojoj čovjek živi. Primarni ključ tablice "Ulice" je, naravno, "ID". Dakle, to će izgledati ovako:

I onda će, naravno, računalo svaki put kad je potrebno pročitati adresu zaposlenika uzeti primarni ključ, otvoriti tablicu "Ulice", pronaći odgovarajući zapis i pročitati podatke odande.

E, upravo taj oblik stvaranja veze među tablicama naziva se relacija.

Dijagram relacija u Accessu

Dijagram relacija u FileMakeru

I to je otprilike - to što je koncepcijski, paradigmatski i terminološki isto i kod MSA, i kod FMP. Sve drugo je drugačije. :-)

MS Access

Access ima jasno odijeljene vrste objekata:

• tablice, koje sadrže isključivo unesene podatke (od čega su neki podaci - ključevi)
• upite (eng. query), generirane ili napisane SQL jezikom, koji služe pretraživanju, filtriranju, grupiranju i kombiniranju podataka iz tablica, izračunavanju određenih stvari na razini pojedinih zapisa, ali i agregirano po grupama, pa onda izmjeni podataka u tablicama, kreiranju novih zapisa, novih tablica... dakle, svemu onom što SQL jezik omogućava
• obrasce (eng. form), koji služe kao korisničko sučelje za interaktivno pregledavanje, pretraživanje i unos podataka
• izvještaje (eng. report), koji služe za generiranje izlaznih dokumenata, bilo da se radi o popisima, proračunima, analitičkim izvještajima...
• ne pretjerano korisne makroprograme (eng. macro) i solidno upotrebljive VBA aplikacijske module (eng. module) koji služe prilagođavanju i automatiziranju zadaća, pa čak i izradi kompletnih aplikacija koje mogu potpuno sakriti temeljni alat (MS Access)

Grafičko generiranje SQL upita u MS Accessu

Jedan prilično složen :-) SQL upit u MS Accessu

Same relacije su, kao u svakom SQL baziranom alatu, prije svega misaoni koncept. Dakle, korisnik ih, prilikom dizajniranja baze zamišlja. Postoji i alat za grafičko prikazivanje relacija među tablicama, ali on je više kao podsjetnik ili pomoć jer se u SQL-u relacije ionako definiraju u svakom upitu posve slobodno i ništa nas ne obavezuje da bilo koju relaciju korištenu u SQL-u moramo prethodno definirati u spomenutom alatu.

Obrasci i izvještaji se opet oslanjaju bilo na neku određenu tablicu, bilo na neki određeni upit koji je ranije definiran, ili na specifični SQL upit definiran unutar samog obrasca (ili izvještaja). Obrazac može sadržavati podobrazac (eng. subform), a izvještaj može sadržavati podizvještaj (eng. subreport). Svrha podobrasca i podizvještaja je prikaz većeg broja zapisa koji su povezani s jednim nadređenim podatkom. Na primjer, možemo imati obrazac za pregled i unos podataka o zaposlenicima i onda na njemu, za svakog zaposlenika podobrazac s listom radnih mjesta na kojima je radio.

Uglavnom, SQL je temelj svega, čak i onda kad se korisnik ne služi izravno SQL-om, nego upite generira korištenjem klik-po-klik pomagača (wizarda). Kako je sam SQL prilično moćan jezik za manipulaciju podacima, onaj tko se potrudi shvatiti njegovu paradigmu i naučiti razmišljati na taj način, može relativno lako postići prilično visoku razinu manipulacije podacima u relacijskoj bazi, i to uz ništa ili nešto malo programiranja. Ključna stvar je u tome da su podaci dohvaćeni SQL-om "beztjelesni", oni su samo jedna dinamički formirana tablica za čiji se prikaz brine aplikacijska nadgradnja - korisničko sučelje MS Accessa, tako da možemo vrlo jednostavno isti SQL upit koristiti za prikaz podataka, unos podataka, ispis izvještaja, a da svaki od njih izgleda posve drugačije.

FileMaker Pro

FMP je izgrađen oko posve drugačije paradigme. Narav i svrha pojedinih objekata je prilično pomiješana i maglovita. Ili se barem tako čini nekom naviklom na Access. :-) Ključna paradigma u FileMakeru je - kontekst. Praktički je nemoguće (tj. vrlo je teško) čak i dohvaćati podatke, a kamoli manipulirati njima na posve apstraktnoj razini (kako to inače radi SQL). Prvo pitanje u svakoj zadaći koju treba provesti je - u kojem kontekstu promatramo podatke.

Zbog toga u FMP ne postoje upiti. Isto tako ne postoje obrasci i izvještaji. Postoje prikazi (eng. layout), a svaki od njih može biti i obrazac, i izvještaj, jer ima mod pregledavanja (eng. browse mode) i mod predispisa (eng. preview mode). Pri tom se prikaz za oba moda dizajnira kao jedinstven, iako, hm, ne izgleda baš sasvim isto kod pregledavanja kao i za ispis. Meni osobno je ovo dosta loš pristup jer gotovo nikad dizajn primjeren za pregled i unos podataka na ekranu ne funkcionira dobro kao izvještaj na papiru pa je ionako potrebno definirati po dva prikaza za isti skup podataka - jedan za pregledavanje i unos, a drugi za ispis u obliku izvještaja.

Izrada prikaza u FileMakeru

Prikaz također ima mod pretraživanja (eng. find mode), koji nalikuje onom što se u Accessu zove filter - dakle alatu za brzo i jednostavno (i donekle ograničeno) *privremeno* pretraživanje i izvlačenje određenog dijela zapisa određene tablice ili upita. Međutim, kako u FMP nema upita, mod pretraživanja prikaza je zapravo nadomjestak upita (i za pretraživanje, i za izmjene). Dakle, ono što bismo u Accessu riješili upitom (smještenim eventualno u obrazac ili izvještaj), u FMP traži da definiramo prikaz koji kombinira potrebna polja iz potrebnih tablica, a onda definirane zapise pročešljamo u modu pretraživanja da bismo slaganjem takozvanih pretražnih zahtjeva (eng. find request) odsimulirali ono što inače stoji u WHERE dijelu SQL upita. To je, što se pretraživanja tiče, solidna zamjena koja je bez sumnje početniku neusporedivo jasnija i intuitivnija od standardnog SQL pristupa koji je vrlo apstraktan i za puno razumijevanje traži matematičko razmišljanje. Međutim, takav alat je užasno loša zamjena za SQL upite UPDATE tipa, dakle one koji mijenjaju podatke. Naravno, osnovni mehanizam traženja i zamjene postoji, kao i u Accessu, ali to je neusporedivo manje nego što omogućava SQL UPDATE upit. Za složenije izmjene podataka treba se prihvatiti pisanja (odnosno klikanja) skripte.

Korisniku neupućenom u FMP postavlja se pitanje kako postići ono što se u Accesu postiže upitom - dobiti izračunata i sumarna polja - npr. u tablici imamo polje "Cijena", a polje "PDV" izračunamo u upitu, kao ROUND(Cijena*0.25,2). Ili polje "Iznos" izračunamo kao Cijena*Kolicina. A onda u agregiranom upitu zapise grupiramo po polju "Cjelina" da bi u sumarnom polju "Ukupno" dobili ukupni iznos svih stavki koje pripadaju toj grupi (SQL jezikom, to je:

Naravno, to je moguće i u FileMakeru! Ali, kako ne postoje upiti, sve izračunate i sumarne vrijednosti dodaju se kao kalkulacijska i sumarna polja (eng. calculation, summary) u samu tablicu! Opet - intuitivno za početnike, malo čudno za one navikle na SQL koncept.

Definiranje kalkulacijskog polja tablice u FileMakeru

Definiranje sumarnog polja u tablici, u FileMakeru

U nekoj iole složenijoj bazi, tablice na kraju završe zatrpane raznoraznim kalkulacijskim i sumarnim poljima koje svako služi nekom drugom prikazu, a neka polja služe samo kao priprema za sumarna polja - konkretno za izvesti gornji primjer treba najprije načiniti kalkulacijsko polje "Iznos" kao Cijena*Kolicina, a zatim sumarno polje "Ukupno" kao Sum(Iznos). Ali funkcionira, čak jako dobro. Najviše me zbunjivalo to što sumarna polja prikazuju istu vrijednost u svakom zapisu (to je zapravo OK i posljedica je samo te čudne logike da se sumarna polja definira skupa s normalnima i kalkulacijskima), ali se ta vrijednost automatski mijenja ovisno o kontekstu. Ako sumarno polje prikažemo u subtotalu prikaza vezanom za određenu grupu, dobit ćemo sumu stavki te grupe, a ako ga prikažemo konačnom totalu cijelog izvještaja, dobit ćemo sumu svih stavki. Baš do srži appleovski napravljeno - za nooba koji nema pojma kako, ali to jednostavno radi baš onako kako je njemu palo na pamet. Sjajno! I vrlo zbunjujuće za starog SQL-aša. :-)

Jasno, kao i u Accessu, tako i u FMP postoji alat za grafičko prikazivanje relacija među tablicama, čak vrlo sličan Accessovom. Međutim, dok je on u Accessu, tek informativne prirode i neobavezan (više služi kao skica i podsjetnik korisniku kako je zamišljena struktura baze), u FMP je kritično važan, jer se program na njega cijelo vrijeme oslanja dok korisnik definira prikaze. Korisnik opet, appleovski jednostavno, samo mišem povlači polja iz raznih tablica, a program u pozadini "pokopčava" relacijske odnose na temelju onog što je nacrtano u relacijskom dijagramu i odlučuje kako se koje polje prikazuje. Još jednom - kao rođeno za početnika - ne znam kako, ali sve radi baš kako treba! :-)

Kraj 1. dijela