Mengapa Memilih Neo4J untuk Database Engine Robot Lumen

Robot Lumen adalah:

1. Robot berbasis Nao yang diproduksi oleh Aldebaran Perancis dengan segala perangkat hardware dan software sebagai bawaan dasar, dimana bahasa Inggris adalah bahasa dasar.
2. Robot yang dikembangkan oleh tim robotik Lumen, dari grup LSKK, program studi Elektro, Fakultas STEI, Institut Teknologi Bandung
3. Robot yang memiliki AI (Artificial Intelligence) atau kecerdasan buatan. AI pada robot dapat dirancang dengan sangat cermat sehingga robot menguasai hal-hal yang sudah didata, dan bisa belajar hal-hal baru, agar kesalahan yang dilakukan oleh robot dapat diminimalkan.
4. Robot yang bisa mengenali wajah dan suara Pemilik dan orang-orang yang dikehendaki Pemilik, termasuk para personil pendukung riset dan para pengunjung pameran.
5. Robot yang tidak memiliki perasaan. Dari satu sudut pandang, hal ini bisa dianggap sebagai kekurangan. Namun, bila dilihat dari sudut pandang lain, hal ini bisa dianggap merupakan kelebihan. Ketiadaan perasaan pada robot menyebabkan masalah-masalah yang timbul akibat emosi tidak ada terpengaruhnya terhadap kinerja yang dihasilkan.
6. Robot yang tidak memiliki rasa bosan sehingga dapat melakukan pekerjaan yang berulang-ulang tanpa mengurangi performa dan kinerja yang dihasilkan, sejauh dikehendaki oleh sang Pemilik.
7. Robot yang tidak memiliki rasa lelah sejauh baterai tetap di-charge, dan motor dalam temperatur yang masih diijinkan. Hal ini menyebabkan jam kerja robot bisa diatur dengan lebih tepat dan terjadwal. Selain itu, robot bisa dikonfigurasikan agar siap sedia kapan saja diperlukan.

Data yang Dikelola:

1. Text untuk berbahasa dan berkomunikasi. Sebagai referensi, Robot akan memiliki sejumlah perbendaharaan kata yang sudah baku dan benar, yang tersimpan sebagai text. Selanjutnya sejalan dengan pergaulan sosial dalam lingkungan riset dan pameran, Robot akan menambahkan kata-kata baru yang akan disimpan dan dikelola sebagai text.
2. Wajah untuk dikenali untuk kebutuhan komunikasi. Sebagai referensi, Robot akan memiliki sejumlah data wajah Pemilik dan Periset yang sudah dikenali dari beberapa sisi pandangan. Data wajah ini sudah dilengkapi dengan berbagai atribut yang dibutuhkan. Selanjutnya Robot akan bertemu dan berkenalan dengan sejumlah wajah-wajah baru dalam pameran yang kemudian bisa diidentifikasi untuk mengisi atribut dengan tanya jawab kepada pemilik wajah baru tersebut. Data wajah disimpan sebagai image, sedangkan atribut terkait disimpan dalam bentuk text.
3. Suara untuk dikenali untuk kebutuhan komunikasi. Sebagai referensi, Robot akan memiliki sejumlah data suara Pemilik dan Periset yang sudah dikenali dalam beberapa intonasi dan logat. Data suara ini sudah dilengkapi dengan berbagai atribut yang dibutuhkan. Selanjutnya Robot akan bertemu dan berkenalan dengan sejumlah suara-suara baru dalam pameran yang harus bisa diidentifikasi dengan tanya jawab kepada pemilik suara baru tersebut. Data suara disimpan sebagai audio, sedangkan atribut terkait disimpan dalam bentuk text.

Kemampuan Database Engine:

1. Database engine dipasang pada Server yang dapat berkomunikasi dengan Robot lewat Wi-Fi
2. Mencari kata kunci dari pertanyaan dan query yang masuk dari Pemilik, periset Robotika, dan pengunjung pameran
3. Mengambil data yang tersimpan dengan tingkatan relevansi terhadap query
4. Membandingkan data dan query yang masuk dengan data tersimpan
5. Menambahkan data baru secara otomatis bila belum ada dalam data tersimpan
6. Meminta atribut dari data baru kepada orang yang baru dikenali
7. Mencari atribut tambahan yang sesuai dari internet

Kebutuhan akan Database Grafik:

1. Untuk melayani kebutuhan sebagai teman bicara, Robot harus adaptif terhadap bahasa sehari-hari, dan untuk natural language processing dibutuhkan sistem database yang berbasis semantic queries, yaitu yang memungkinkan adanya pertanyaan di luar konteks atau di luar bahasa baku.
2. Untuk menjamin kualitas transaksi database, dibutuhkan sistem database yang berkarakteristik ACID (atomik, konsisten, terisolasi, dan menjamin daya tahan data/transaksi)
3. Untuk melayani kebutuhan sebagai teman belajar, maka Robot harus juga bertindak sebagai recommendation engine, yang  membutuhkan sistem database yang bisa bersikap "fuzzy" yang sulit dilayani oleh database relasional.
4. Untuk melayani kebutuhan sebagai teman main Pemilik, maka Robot harus bisa multi tasking, artinya bisa bicara sambi bermain. Untuk itu dibutuhkan sistem database yang tidak memberatkan CPU dan RAM.
5. Berdasarkan artikel pada link berikut (silahkan link disalin bila tak bisa di-klik)
   http://budhiym.blogspot.com/2014/12/perbandingan-database-grafik-dengan.html
   maka penggunaan Database Grafik merupakan kebutuhan untuk Robot Lumen

Mengapa Dipilih Neo4J

1. Database grafik open source yang sangat scalable yang mendukung ACID
2. Neo4j adalah database yang menggunakan struktur grafik untuk query semantik dengan node, edge, dan properti untuk mewakili dan menyimpan data
3. Memiliki sistem clustering dengan ketersediaan tinggi untuk kebutuhan enterprise
4. Dilengkapi dengan alat berbasis administrasi web yang meliputi dukungan transaksi penuh dan visual dengan grafik explorer node-link 
5. Neo4j dapat diakses dari kebanyakan bahasa pemrograman menggunakan built-in antarmuka REST dengan web API
6. Neo4j adalah database grafik yang paling populer digunakan saat ini

Perbandingan Database Grafik dengan Database Relasional

Database Relasional

Database relasional telah menjadi mesin utama aplikasi perangkat lunak sejak tahun 80-an, dan terus begitu sampai hari ini. Mereka menyimpan data yang sangat terstruktur dalam tabel dengan kolom dan baris yang telah ditentukan sebelumnya, dengan jenis informasi yang serupa, dan untuk mengikuti format baku organisasi, pengembang harus membuat aplikasi yang secara ketat mengikuti struktur data yang digunakan dalam aplikasi organisasi tersebut.

Dalam database relasional, referensi baris dan tabel lain ditunjukkan dengan mengacu pada atribut utama (=primer) mereka, yang dilaksanakan dengan ketentuan bahwa koneksi tidak pernah opsional. Relasi dihitung pada saat permintaan (=query) dengan cara mencocokkan kunci primer dan banyak kunci asing(= foreign keys) yang berpotensi diindeks, dari baris tabel yang akan JOIN. Operasi ini sangat memakan tenaga CPU dan RAM dengan biaya / energi yang eksponensial.

Jika Anda menggunakan relasi banyak-ke-banyak (=many-to-many relationship), Anda harus menggunakan JOIN tabel yang berisi daftar kunci asing dari kedua tabel yang berpartisipasi yang mana akan meningkatkan biaya operasi. Proses operasi JOIN tabel ini mahal, sehingga biasanya ditangani dengan denormalisasi data untuk mengurangi jumlah JOIN tabel sebatas yang diperlukan saja.

Meskipun tidak semua use-case cocok untuk jenis model data yang ketat, kurangnya alternatif yang layak dan dukungan pada database relasional telah membuatnya menjadi sulit bagi model-model alternatif untuk masuk ke format utama (=mainstream).

Dari Database Relasional ke Database Grafik 

Relasi adalah komponen utama dari model data grafik, tidak seperti sistem manajemen database lain, yang mengharuskan kita untuk menyimpulkan hubungan antara entitas dengan menggunakan properti seperti kunci asing, atau pengolahan sampingan seperti pengurangan peta. Dengan merakit abstraksi sederhana node dan relasi ke dalam struktur terhubung, database grafik memungkinkan kita untuk membangun model canggih yang memetakan model yang erat dengan domain masalah kita.

Dalam beberapa hal, database grafik seperti generasi lanjutan dari database relasional, tetapi dengan dukungan utama untuk "relasi", yaitu koneksi implisit seperti yang ditunjukkan melalui-kunci asing dalam database relasional.

Setiap node (entitas atau atribut) dalam model database grafik langsung berisi daftar catatan relasi yang mewakili hubungan ke node lain, yang diatur oleh jenis dan arah dan pemegang atribut tambahan. Setiap kali Anda menjalankan proses setara dengan operasi JOIN tabel, database memanfaatkan daftar ini dan memiliki akses langsung ke node yang terhubung, sehingga menghilangkan kebutuhan untuk proses perhitungan pencarian yang mahal.

Model yang dihasilkan lebih sederhana dan pada saat yang sama lebih ekspresif daripada yang diproduksi menggunakan database relasional dan database NoSQL lainnya.

Tidak seperti database NoSQL lainnya, database grafik mendukung model data yang sangat fleksibel dan halus yang memungkinkan Anda untuk membuat model dan mengelola domain dengan cara yang mudah dan intuitif.

Anda lebih kurang menyimpan data seperti di dunia nyata: kecil, normal, namun sangat terkait dengan entitas. Hal ini memungkinkan Anda untuk meminta (=query) dan melihat data Anda dari sudut pandang yang mudah dibayangkan, serta mendukung banyak use-case yang berbeda.

Model halus juga berarti bahwa tidak ada batasan natural sekitar agregat, sehingga ruang lingkup operasi update bisa dilaksanakan oleh aplikasi. Konsep kelompok transaksi yang terkenal dan teruji untuk update satu set node dan relasi menjadi operasi ACID (= atomik, konsisten, terisolasi dan tahan lama). Database grafik seperti Neo4j sepenuhnya mendukung konsep transaksional termasuk tulis-dulu log, dan pemulihan data dalam kasus terminasi abnormal.

Jika Anda terbiasa pemodelan dengan database relasional, cobalah untuk mengingat kemudahan dan keindahan dari normalisasi diagram relasi entitas: cara yang sederhana dan mudah untuk menggambarkan dan memahami model Anda dapat dengan cepat bersama rekan-rekan Anda dan para ahli domain. 

Mari kita buat model yang realistis dari domain organisasi dan menunjukkan bagaimana hal itu akan dimodelkan dalam database relasional vs database grafik, sebagai berikut:

Query pada Database Grafik Menggunakan Cypher

Query database relasional dengan mudah dilakukan menggunakan bahasa query deklaratif pada SQL yang memungkinkan query ad-hoc pada database, serta menentukan query terkait use-case dalam kode Anda. Bahkan pemeta objek-relasional menggunakan SQL untuk langsung berbicara dengan database.

Apakah database grafik memiliki sesuatu yang mirip? Cypher, bahasa query grafik deklaratif Neo4j, dibangun di atas konsep-konsep dasar dan klausa SQL tetapi memiliki banyak tambahan fungsi-grafik khusus untuk membuatnya mudah untuk bekerja dengan model grafik yang kaya tanpa terlalu bertele-tele.

Jika Anda pernah mencoba untuk menulis pengkodean SQL dengan banyak JOIN tabel, Anda tahu bahwa Anda dengan cepat bisa kehilangan arah sebenarnya karena semua kesibukan teknis yang tidak perlu.

Dalam domain organisasi pada gambar di atas, bagaimana pengkodean SQL yang berisi daftar karyawan di "Departemen IT" terlihat, dan bagaimana pengkodean SQL bila dibandingkan dengan pengkodean Cypher?

SQL Statement
SELECT * FROM Person
LEFT JOIN Person_Department
  ON Person.Id = Person_Department.PersonId
LEFT JOIN Department
  ON Department.Id = Person_Department.DepartmentId
WHERE Department.name = "IT Department"

Cypher Statement
MATCH (p:Person)<- d:department="" font="">
WHERE d.name = "IT Department"
RETURN p.name

Mengimpor Data dari Database Relational

Jika Anda memiliki pemahaman yang baik tentang apa model grafik Anda akan terlihat, yaitu data apa yang akan direpresentasikan sebagai node atau relasi, dan bagaimana label, relasi-jenis, dan atribut yang akan diberi nama, Anda siap untuk memulai.

Cara termudah untuk mengimpor data dari database relasional Anda adalah untuk membuat file CSV baik tabel individu dan tabel gabungan, atau dari gabungan lainnya. Maka , denormalisasi representasi.

Kemudian Anda dapat mengambil file CSV dan menggunakan perangkat CSV LOAD Cypher untuk:

• Menelan data, mengakses kolom dengan nama header atau offset 
• Mengkonversi nilai dari string ke format lain dan struktur yang berbeda (toFloat, split, ...) 
• Loncat baris untuk mengabaikan 
• MATCH Node berdasarkan pencarian atribut 
• CREATE atau MERGE node dan hubungan dengan label dan atribut dari data baris

Misalnya:

persons.csv
name;email;dept
"Lars Higgs";"lars@higgs.com";"IT-Department"
"Maura Wilson";"maura@wilson.com";"Procurement"

LOAD CSV FROM 'file:///data/persons.csv' WITH HEADERS AS line
FIELDTERMINATOR ";"
MERGE (person:Person {email: line.email}) ON CREATE SET p.name = line.name
MATCH (dep:Department {name:line.dept})
CREATE (person)-[:EMPLOYEE]->(dept)


Anda dapat mengimpor beberapa file CSV dari satu atau lebih sumber data untuk memperkaya model domain inti Anda dengan informasi lain yang mungkin menambah wawasan dan kemampuan yang menarik.

Catatan: informasi ini disarikan dari laman http://neo4j.com/developer/graph-db-vs-rdbms/