Koha konferens Tylösand 16 oktober 2015 Koha förstudie och projekt Systemmiljö Migrering Frågor/diskussion
Universitetsbiblioteket vid Luleå Tekniska Universitet 2 avdelningar: Kundtjänst och pedagogiskt stöd Informationsresurser, publicering och system Elektroniska informationsresurser står helt i fokus, och 95% av mediebudgeten används till elektroniskt material. 270 000 beståndsposter 27 000 låntagare i systemet
Förstudien om framtidens bibliotekssystem Startade november 2014 Tre förslag fanns: fortsätta med ALEPH, införa ALMA eller införa KOHA Hanteringen av de fysiska böckerna ska vara så enkel och ändamålsenlig som möjligt. Aleph och Alma var alltför stora och kraftfulla för vår minskande hantering Nytta med Koha jämfört med Aleph: Minska kostnader Undvika återkommande upphandlingar Modernare system som är framtidssäkrad Viss ökad flexibilitet att förändra systemfunktionalitet genom att verka i Kohas utvecklingscommunity.
Beslut KOHA/EBBA Styrgruppen tog beslut om KOHA juni 2015 Beslut att använda EBBA för fjärrlån Projektet startades direkt Driftsättning bestämdes till 7 januari 2016
Hur projektet är organiserat Projektgrupp med PL+Verksamhetsrepresentanter+2 systemutvecklare från LTU:s IT-avdelning Verksamheten representeras av områdesansvariga: Katalogisering Inköp Fjärrlån Cirkulation/lån Fakturering och betalning av avgifter Statistik
Hur projektet är organiserat Verksamhetsgrupperna arbetar självständigt med egna möten och rapporterar till projektgruppen. Identifierar förändringsbehov, felsöker, testar processen, ger förslag på lösningar, förankra KOHA i organisationen. Löpande frågor och problem löses internt eller med hjälp av samarbete med ex. Koha Norden på Slack forumet eller SUB.
Systemmiljö Vi gör all utveckling (framför allt i Perl + PHP + SQL) och konfiguration på en KOHA testserver. Vi använder oss av SVN för hantering av källkod. Vid driftsättning i januari så migrerar vi databasen från test till produktionsserver. Som fjärrlånesystem så valde vi att utgå från EBBA (ursprungligen från Umeå universitet) och sedan utveckla denna mot KOHA.
Migrering Datamigrering, underskattas många gånger. Oftast med motiveringen att det "kan väl inte vara så svårt att flytta data från ett ställe till ett annat". Lätt, om det finns en väl beskriven struktur där informationen ligger på förväntad plats. Svårt, om informationen ligger lite hur som helst. Ännu svårare, om informationen dessutom ligger ihop-bakat med annat data i någon slags allmän behållare. Ännu svårare än ännu svårare, om informationen som är ihop-bakat med annat data inte följer ett mönster och dessutom ligger i någon slags allmän behållare. Välkommen till min del avseende migreringen från Aleph till Koha.
Migrering Migrering av användare (Patrons), lån och reservationer. Full databasmigrering pågår just nu. Hanteras av script, ingen 3:e parts mjukvara. Pga av komplexiteten och alla undantag. Tumregel börja alltid i målsystemet och arbeta sig bakåt mot källsystemet, dvs få svar på frågan VAR skall informationen och VAD förväntas. För att lättare kunna identifiera var informationen skall spridas. Oftast mer förvirrande att gå rätt väg. Vi skall alltså gå från Koha till Aleph, ta del av erfarenheten för användare (Patrons).
Migrering I Koha har vi två tabeller: borrowers, borrower_attributes I Aleph har vi sex tabeller: Z303, Z304, Z111, Z308, Z353, Z305 (Redan här så inser man att vi inte skall gå rätt väg ) I Koha har borrowers en PK och två FK, borrower_attributes har två FK. I Aleph har de sex tabellerna inga formella relationer i form av PK och FK. (Informationen är således logiskt kopplad) I Koha representeras min användare av totalt 5 rader (1+4), räcker egentligen med en rad. I Aleph representeras min användare av totalt 30 rader (1+1+13+6+6+3), skulle kunna banta ner den till 26 rader.
Migrering I Koha kan jag tex se ett fält i tabellen borrowers som heter city. I Aleph i tabellen z304 och fältet kan jag se z304_address. M E N Där finns ju även efternamn, förnamn, gatuadress, postnummer, ort, enhet osv osv. (Underligt med de 5 andra tabellerna ) Vi har ju namn som är flera kilometer långa, vi har ju även gatuadresser med två eller flera namn, vi har avdelningar med mellanslag, konstiga tecken, vi har personnummer innehållande +, T, vi har telefonnummer innehållande bokstäver osv osv Självklart har vi även användare utan adress, utan epost och utan telefonnummer Sen så kryddar vi det hela med missmatch mellan instruktioner och vad jag faktiskt gör i Aleph
Migrering I z304 har vi gott och blandat. Lite godtyckligt. Jamen, fasta positioner, väl beskrivet i Aleph db-manual Förnamn efternamn eller efternamn, förnamn eller eller Postnummer och ort eller eller Land eller avdelning eller titel eller ingenting
Migrering "I had an AWKward walk to the promised land with PL/SQL as my brother" Unix awk, Unix SED och Oracle PL/SQL 14 tabeller. 7 procedurer. 4 funktioner. 3 vyer. 2 UNIX shell script. (Kuriosa, tabeller vs vyer ) Det skulle ta max 2 veckor, det tog längre, mycket längre Jag har sett ljuset i tunneln och det var inte tåget jag mötte
Ola Andersson Anders Gunnare Elisabeth Simu