BAB 2 LANDASAN TEORI 2.1 Sistem Basis Data Kata “basis data” bisa digunakan untuk menguraikan segala sesuatu dari sekumpulan data tunggal, seperti daftar telepon. Istilah “basis data” tidak termasuk aplikasi, yang terdiri dari form dan report dimana pengguna akan saling berhubungan. Basis data terdiri dari file-file fisik yang ditetapkan berdasarkan komputer saat menerapkan perangkat lunak basis data. Di sisi lain, suatu model basis data lebih kepada konsep dibandingkan objek fisik dan digunakan untuk menciptakan tabel di dalam basis data. Sebuah basis data adalah tempat penyimpanan file data. Sebagai file data, suatu basis data tidak menyajikan informasi secara langsung kepada pengguna. Pengguna harus menjalankan aplikasi untuk mengakses data dari basis data dan menyajikannya dalam bentuk yang bisa dimengerti. Ketika bekerja dengan file-file data, suatu aplikasi harus dikodekan agar bekerja dengan struktur masing-masing file data. Biasanya, suatu basis data berisi suatu katalog yang menggunakan aplikasi untuk menentukan cara data diorganisir. Aplikasi basis data umum bisa menggunakan katalog tersebut untuk menampilkan data dengan pengguna dari basis data yang berbeda secara dinamis, tanpa terikat pada format data tertentu. Basis data biasanya memiliki dua bagian utama. Pertama, file yang memegang basis data fisik. Kedua, perangkat lunak sistem manajemen basis data (DBMS) menggunakan aplikasi untuk mengakses data. DBMS bertanggung jawab menguatkan struktur basis data, termasuk : 1. Memelihara hubungan antar data didalam basis data 2. Memastikan bahwa data tersimpan secara tepat, dan menetapkan aturan hubungan data agar tidak dilanggar 3. Pemulihan semua data dari kegagalan system Ada beberapa alasan mengapa kita menggunakan sistem basis data : 1. Untuk mengatasi kerangkapan data (redundancy data). 2. Untuk menghindari terjadinya inkonsistensi data. 3. Untuk mengatasi kesulitan dalam mengakses data. 4. Untuk menyusun format yang standar dari sebuah data. 5. Untuk Penggunaan oleh banyak pemakai (multiple user). Sebuah database bisa dimanfaatkan sekaligus secara bersama oleh banyak pengguna (multiuser). 6. Untuk melakukan perlindungan dan pengamanan data. Setiap data hanya bisa diakses atau dimanipulasi oleh pihak yang diberi otoritas dengan memberikan login dan password terhadap masing-masing data. 7. Agar pemakai mampu menyusun suatu pandangan (view) abstraksi dari data. Hal ini bertujuan menyederhanakan interaksi antara pengguna dengan sistemnya dan database dapat mempresentasikan pandangan yang berbeda kepada para pengguna, programmer dan administratornya. Banyak memanfaat yang dapat kita peroleh dengan menggunakan basis data. Manfaat/kelebihan basis data diantaranya adalah : 1. Kecepatan dan kemudahan (speed) Dengan menggunakan basis data pengambilan informasi dapat dilakukan dengan cepat dan mudah. Basis data memiliki kemampuan dalam mengelompokan, mengurutkan bahkan perhitungan dengan metematika. Dengan perancangan yang benar, maka penyajian informasi akan dapat dilakukan dengan cepat dan mudah. 2. Kebersamaan pemakai Sebuah basis data dapat digunakan oleh banyak user san banyak aplikasi. Untuk data-data yang diperlukan oleh banyak orang/bagian. Tidak perlu dilakukan pencatatan dimasing-masing bagian, tetapi cukup dengan satu basis data untuk dipakai bersama. Misalnya data mahasiswa dalam suatu perguruan tinggi, dibutuhkan oleh banyak bagian, diantaranya: bagian akademik, bagian keuangan, bagian kemahasiswaan, dan perpustakaan. Tidak harus semua bagian ini memiliki catatan dan semua bagian bisa mengakses data tersebut sesuai dengan keperluannya. 3. Pemusatan control data Karena cukup dengan satu basis data unutk banyak keperluan, pengontrolan terhadap data juga cukup dilakuan di satu tempat saja. Jika ada perubahan data alamat mahasiswa misalnya, maka tidak perlu kita meng-update semua data dimasing-masing bagian tetapi cukup hanya disatu basis data. 4. Efesiensi ruang penyimpanan (space) Dengan pemakain bersama, kita tidak perlu menyediakan tempat penyimpanan diberbagai tempat, tetapi cukup satu saja sehingga ini akan menghemat ruang penyimpanan data yang dimilikioleh sebuah organisasi. Dengan teknik perancangan basis data yang benar, kita akan menyederhanakan penyimpanan sehingga tidak semua data harus disimpan. 5. Keakuratan (Accuracy) Penerapan secara ketat aturan tipe data, domain data, keunikan data, hubungan antara data, dan lain-lain, dapat menekan keakuratan dalam pemasukan/penyimpanan data. 6. Ketersediaan (availability) Dengan basis data kita dapat mem-backup data, memilah-milah data mana yang masih diperlukan dan data mana yang perlu kita simpan ke tempat lain. Hal ini mengingat pertumbuhan transaksi suatu organisasi dari waktu ke waktu membutuhkan media penyimpanan yang semakin besar. 7. Keamanan (Security) Kebanyakan DBMS dilengkapi dengan fasilitas manajemen pengguna diberikan hak akses yang berbedabeda sesuai dengan pengguna dan posisinya. Basis data bisa diberikan passwordnya untuk membatasi orang yang mengaksesnya. 8. Kemudahan dalam pembuatan program aplikasi baru Pengguna basis data merupakan bagian dari perkembangan teknologi. Dengan adanya basis data pembuatan aplikasi bisa memanfaatkan kemampuan dari DBMS, sehingga pembuatan aplikasi tidak perlu mengurusi penyimpanan data, tetapi cukup mengatur interface untuk pengguna. 9. Pemakaian secara langsung Basis data memiliki fasilitas untuk melihat datanya secara langsung dengan tool yang disediakan oleh DBMS. Untuk melihat data, langsung ke table ataupun menggunakan query. Biasanya yang menggunakan fasilitas ini adalah user yang sudah ahli, atau database administrator. 10. Kebebasan data (Data Independence) Jika sebuah program telah selesai dibuat, dan ternyata ada perubahan isi/struktur data. Maka dengan basis data, perubahan ini hanya perlu dilakukan pada level DBMS tanpa harus membongkar kembali program aplikasinya. 11. User view Basis data penyediaan pandangan yang berbeda-beda untuk tiap-tiap pengguna. Misalnya kita memiliki data-data dari perusahaan yang bergerak dibidang retail. Data yang ada berupa data barang, penjualan, dan pembelian. Ada beberapa jenis pengguna yang memerlukan informasi terkait dengan data perusahaan tresebut. Mereka adalah pelanggan, kasir, bagian gudang, bagian akutansi dan manajer. Tidak semua data boleh diakses oleh semua pengguna. Misalnya kasir dia hanya boleh berhak melihat informasi nama barang dan harga jualnya. Sementara itu dia berhak untuk memasukan data penjualan . berbeda dengan pelanggan yang hanya melihat data keberadaan barang dan harga jual tetapi tidak berhak memasukan atau merubah data. Sementara itu bagian akutansi berhak melihat keuntungan dari tiap-tiap barang untuk menganalisa data akutansinya.Basis data mampu memberikan layanan organisasi seperti ini. Basis Data juga memiliki kekurangan, antara lain: 1. Lebih Mahal Sistem basis data membutuhkan sumber daya yang tinggi, terlebih untuk melakukan perawatan secara berkala. 2. Proses back up cukup memakan waktu. Sistem basis data mencakup banyak file, sehingga jika dilakukan back up akan menghabiskan waktu. 3. Bila ada akses yang tidak benar, kerusakan dapat terjadi. Kesalahan dalam mengakses bisa menyebabkan berbagai masalah, terutama oleh sembarang pengguna. 4. Sistem lebih rumit, sehingga memerlukan tenaga spesial. Sistem basis data sangat kompleks, tidak sembarang orang bisa menanganinya. Terutama dengan berbagai macam resiko, sehingga hanya orang ahli yang hanya bisa menanganinya. 1.2 Database Management System 1. Sistem Sebuah tatanan (keterpaduan) yg terdiri dari sejumlah entitas dan aktivis yang saling berhubungan dan secara bersama mewujudkan sebuah tujuan utama. 2. Database Management System (DBMS) Menurut Connolly (2005, p16) Sistem Manajemen Basis data (DBMS) merupakan suatu sistem perangkat lunak (software) yang membantu pemakai dalam mendefinisikan, menciptakan, mengatur dan mengontrol akses pada suatu basis data. DBMS memberikan beberapa fasilitas, antara lain: 1. DDL (Data Definition Languange), DDL memberikan fasilitas kepada user untuk menspesifikasikan tipe data dan strukturnya serta batasan aturan mengenai data yang bisa disimpan ke dalam basis data tersebut. 2. DML (Data Manipulation Languange), DML memberikan fasilitas kepada user untuk menambah, mengedit, menghapus, serta memperoleh kembali data. 3. Query Languange, memberikan fasilitas kepada user untuk mengakses data. 4. Pengendalian akses ke dalam basis data, meliputi: - Keamanan Sistem: mencegah user untuk tidak memiliki hak akses masuk ke dalam basis data. - Integritas Sistem: menjaga konsistensi data di dalam basis data. - Pengendalian share data - Backup dan Recovery Sistem: mengembalikan data kedalam kondisi semula apabila terjadi kegagalan pada hardware atau software. 5. Mekanisme View, berfungsi untuk menampilkan data yang hanya diinginkan user. 1.2.1 Keuntungan Menggunakan DBMS Menggunakan DBMS untuk mengelola data yang memiliki banyak keuntungan: 1. Data independence Program aplikasi harus sebagai independen mungkin dari rincian representasi data dan penyimpanan. DBMS dapat memberikan abstrak pandangan dari data untuk melindungi kode aplikasi dari rincian tersebut. 2. Efficient Data Access Sebuah DBMS menggunakan berbagai teknik canggih untuk menyimpan dan mengambil data efisien. Fitur ini sangat penting jika data disimpan pada perangkat penyimpanan eksternal. 3. Data integrity and security Jika data selalu diakses melalui DBMS, maka dapat menegakkan batasan integritas data. Misalnya, sebelum memasukkan informasi gaji bagi karyawan, DBMS dapat memeriksa bahwa departemen anggaran tidak terlampaui. Juga, DBMS dapat menegakkan kontrol akses yang mengatur data apa yang terlihat kelas pengguna yang berbeda. 4. Data administration Ketika beberapa pengguna menggunakan data, mensentralisasi data dapat memberikan kemajuan signifikan. Pengguna professional yang mengerti sifat dari data yang digunakan dan bagaimana kelompok pengguna lain menggunakannya, dapat bertanggung jawab untuk mengatur representasi data untuk mengurangi redundancy dan untuk membuat proses pengambilan data menjadi lebih efisien. 5. Concurrent access and crash recovery Sebuah jadwal DBMS bersamaan akses ke data sedemikian rupa sehingga pengguna bisa memikirkan data yang sedang diakses oleh hanya satu pengguna pada satu waktu. Selanjutnya, DBMS melindungi pengguna dari efek kegagalan sistem. 6. Reduced application development time DBMS mendukung berbagai fungsi penting yang umum untuk banyak aplikasi mengakses data yang tersimpan dalam DBMS. Hal ini, dalam hubungannya dengan antarmuka tingkat tinggi untuk data, memfasilitasi pengembangan aplikasi dengan cepat. Aplikasi ini juga cenderung lebih kuat daripada aplikasi yang dikembangkan dari awal karena tugas-tugas penting yang ditangani oleh DBMS bukannya diimplementasikan oleh aplikasi. 2.2.2 Kerugian Menggunakan DBMS Kerugian penggunaan DBMS menurut Connolly (2005,p29), antara lain: 1. Kompleksitas. 2. Size/ukuran. 3. Biaya dari suatu DBMS. 4. Biaya penambahan perangkat keras. 5. Biaya konversi tinggi. 6. Mengurangi performa penggnnaan aplikasi. 2.2.3 Komponen DBMS DBMS memiliki beberapa komponen utama, antara lain: a. Hardware DBMS dan program aplikasi memerlukan perangkat keras untuk menjalankannya. Perangkat keras terdiri dari komputer pribadi, sampai ke mainframe, atau suatu jaringan komputer. b. Software Komponen Perangkat lunak terdiri dari perangkat lunak DBMS dan program aplikasi, bersama-sama dengan sistem operasi, mencakup perangkat lunak jaringan jika DBMS digunakan pada suatu jaringan. c. Data Bagi user komponen paling utama DBMS adalah adalah data. Data bertindak sebagai suatu jembatan antara komponen mesin dan komponen manusia. Database berisi kedua-duanya : data yang operasional dan meta-data. d. Prosedur Prosedur memuat aturan-aturan untuk mendisain dan penggunaan database. Para pemakai sistem database memerlukan dokumentasi prosedur yang berisi cara menggunakan atau menjalankan sistem itu. e. People Komponen terakhir adalah orang yang terlibat didalam system, yang meliputi: - Data Administrator (DA), mengatur sumber daya data yang meliputi: perancangan basis data, pengembangan dan pemeliharaan standar, kebijakan, prosedur, dan desain basis data konseptual dan logical. - Database Administrator (DBA), mengatur realisasi fisik dari aplikasi database yang meliputi desain fisik basis data, implementasi, pengaturan keamanan dan control integritas, pengawasan performa system dan pengaturan ulang basis data. - Desainer basis data logical dan fisikal - Programmer aplikasi - End user 1. Naïve: user yang tidak tahu mengenai basis data dan DBMS, hanya menggunakan aplikasinya saja. 2. Sophisticated: user yang terbiasa dengan struktur basis data dan DBMS. 2.2.4 Siklus Hidup Sistem Pengembangan Basis data 2.2.4.1 Perencanaan Basis data Mengatur atau merencanakan aktifitas-ak:ti:fitas dengan mengikuti langkah- langkah dari aplikasi basis data dan diterapkan seefektif dan seefisien mungkin. Ada tiga masalah pokok yang harus diperhatikan dalam merumuskan strategi sistem informasi (Connolly, 2005, p285). - Mengidentifikasi rencana dan tujuan perusahaan dengan menetukan sistem informasi yang diperlukan. - Mengevaluasi sistem informasi yang ada untuk melihat kelebihan dan kekurangannya. - Penilaian mengenai peluiang IT yang mungkin dapat menghasilkan keuntungan yang kompetitif. 2.2.4.2 Definisi Sistem Contohnya adalah entity mahasiswa dan orang tua. Dimana mahasiswa merupakan strong entity dan orang tua merupakan weak entity karena keberadaan entity orang tua tergantung dari entity mahasiswa. Mendeskripsikan ruang lingkup dari aplikasi basis data yang akan dibuat termasuk user tempat aplikasi basis data diterapkan (Connolly, 2005,p286). Sebelum mencoba untuk merancang suatu aplikasi basis data, sangatlah penting untuk kita mengidentifikasi batasanbatasan sistem yang ada dan bagaimana sistem tersebut berinteraksi dengan bagian sistem informasi yang lain dalam perusahaan tersebut. Penting juga untuk mengikutsertakan didalam batasan-batasan sistem yang kita buat tidak hanya untuk aplikasi dan pemakai saat ini saja tetapi bisa digunakan dimasa yang akan datang. 2.2.4.3 Pengumpulan dan Analisis Kebutuhan Proses mengumpulkan dan menganalisa kebutuhan-kebutuhan user. Langkah ini melibatkan pengumpulan dan analisa dari informasi tentang bagian dari perusahaan yang akan dibuat sebuah basis data. Ada banyak teknik untuk memperoleh informasi, dan disebut dengan fact finding techniques. Informasi yang dibutuhkan mencakup: 1. Deskripsi tentang data yang digunakan. 2. Keterangan secara lengkap bagaimana data tersebut digunakan 3. Kebutuhan tambahan lainnya untuk aplikasi data yang baru. Informasi ini kemudian akan dianalisa untuk mengidentifikasikan kebutuhan yang tercukup dalam aplikasi basis data yang baru. Kebutuhan ini diuraikan dalam dokumen secara bersama dikenal sebagai spesifikasi kebutuhan untuk aplikasi basis data yang baru. Analisa dan koleksi kebutuhan adalah suatu langkah perisapan untuk merancang suatu basis data. Jumlah data yang dikumpulkan tergantung pada sifat alami dari masalah dan Mengidentifikasi kemampuan yang diperlukan untuk suatu aplikasi kebijakan perusahaan. basis data adalah suatu aktifitas yang penting, karena sistem dengan kemampuan yang tidak sempuran atau tidak cukup akan mengganggu user, yang memunkinkan sistem tersebut tidak digunakan lagi atau ditolak. Bagaimanapun, kemampuan sistem yang berlebihan dapat juga menjadi masalah misalnya suatu sistem yang terlalu rumit dapat membuat sukar untuk penerapan, pemeliharaan, penggunaan atau belajar menggunakan sistem tersebut. 2.2.4.4 Perancangan Basis data Salah satu aplikasi yang umum dikenal dalam aplikasi basis data adalah database design (perancangan basis data). Perancangan basis data dimulai ketika analisis terhadap kebutuhan perusahaan telah dilakukan. Di dalam perancangan basis data terdapat suatu metodologi yang membantu dalam membuat suatu basis data. Yang dimaksud dengan perancangan basis data adalah sebuah pendekatan struktur yang mencakup prosedur, teknik, alat bantu dan tujuan dokumentasi untuk mendukung dan memberi sarana dalam proses perancangan itu sendiri. Metodologi perancangan basis data terdiri dari tahap-tahap yang membantu perancang dengan teknik yang tepat dalam setiap merancang basis data. Metodologi perancangan basis data juga membantu perancangan untuk merencanakan, mengatur dan mengevaluasi pengembangan dari proyek pembuatan basis data tersebut ( Connolly,2005, p439). Dalam metodologi perancangan basis data proses perancangan dibagi menjadi 3 bagian yaitu conceptual database design, logical database design, dan physical database design. 1. Conceptual Database Design Conceptual database design adalah proses membangun suatu model berdasarkan informasi yang digunakan oleh perusahaan atau organisasi, tanpa pertimbangan perencanaan fisik (Connolly,2002,p419). Langkah pertama : Membuat local conceptual data model untuk setiap pandangan yang spesifik. Local conceptual data model terdiri dari : a.Entity types Menurut Connoly (2002,p331), entity types adalah kumpulan objek yang mempunyai karakteristik yang sama, dimana telah diidentifikasi oleh perusahaan.Menurut Silberschatz (2002,p27), entity types adalah kumpulan dari entity yang memiliki tipe dan karakteristik yang sama. Entity dapat dibedakan menjadi dua yaitu : 1.Strong Entity : entity yang keberadaannya tidak tergantung kepada entity lain (Fathansyah,1999,p94). 2.Weak entity : entity yang keberadaannya tergantung dari entity lain (Fathansyah,1999,p94). b.Relationship types Menurut Connolly (2002,p334) definisi dari relationship types adalah kumpulan antar entity yang saling berhubungan dan mempunyai arti. c. Attribute dan attribute domains Attribute adalah karakteristik dari suatu entity atau relasi (Connolly,2002,p338). Setiap attribute diperbolehkan untuk memiliki nilai yang disebut dengan domain. Attribute domains adalah kumpulan dari nilai-nilai yang diperbolehkan untuk satu atau lebih attribute. Ada beberapa jenis dalam attribute: 1. Simple attribute dan Composite attribute. Simple attribute adalah attribute yang terdiri dari komponen tunggal dimana attribute tersebut tidak dapat dipisahkan lagi, sedangkan composite attribute adalah attribute yang masih dapat dipisahkan menjadi beberapa bagian. Contoh dari simple attribute adalah nama_barang sedangkan untuk composite attribute adalah alamat pada entity mahasiswa, karena dalam alamat bisa dibagi menjadi bagian entiti jalan, entiti kode_pos dan entiti kota (Silberchatz,2002,p29). 2. Single-valued attribute dan Multi-valued attribute Single-valued attribute adalah attribute yang memiliki satu nilai pada setiap entity, sedangkan multi-valued attribute adalah attribute yang mempunyai beberapa nilai pada setiap entity (Connolly,2002,p340). Contoh dari single-valued attribute adalah Nim, nama_Mhs, tanggal_lahir, dan lain-lain. Sedangkan untuk multi-valued attribute contohnya adalah jam pelajaran, hobi, dan lain-lain. 3. Derived attribute Derived attribute merupakan attribute yang nilai-nilainya diperoleh dari hasil perhitungan atau dapat diturunkan dari attribute lain yang berhubungan (Silberschatz,2002,p30). Contohnya adalah attribute umur pada entity mahasiswa dimana attribute tersebut diturunkan dari attribute tanggal_lahir dan tanggal_hari_ini. d. Primary key dan alternate keys Primary key adalah key yang telah menjadi candidate key yang dipilih secara unik untuk mengidentifikasi suatu entity types. Candidate key adalah kumpulan attribute minimal yang unik untuk mengidentifikasikan suatu entity types (Connolly,2002,p340). Alternate key adalah key yang digunakan sebagai alternatif dari key yang telah didefinisikan (Fathansyah,1999,p104). e. Integrity constraints Integrity constraints adalah batasan-batasan yang menentukan dalam rangka melindungi basis data untuk menghindari terjadinya inconsistent. (Connolly,2002,p457). Pada tahap conceptual model, langkah-langkah yang dilakukan adalah sebagai berikut : a. Mengidentifikasi entity types Bertujuan untuk menentukan entity types utama yang dibutuhkan. Menentukan entity dapat dilakukan dengan memeriksa user’s requirement specification. Setelah terdefinisi, entity diberikan nama yang tepat dan jelas seperti mahasiswa, dosen, mata_kuliah. b. Mengidentifikasikan relationship types Bertujuan untuk mengidentifikasi suatu relationship yang penting yang ada antar entity yang telah diidentifikasi. Nama dari suatu relationship menggunakan kata kerja seperti mempelajari, memiliki mempunyai dan lain-lain. c. Mengidentifikasi dan menghubungkan attribute dengan entity atau relationship types Bertujuan untuk menghubungkan attribute dengan entity atau relationship yang tepat. Attribute yang dimiliki setiap entity atau relationship memiliki identitas atau karakteristik yang sesuai dengan memperhatikan attribute berikut : simple/composite attribute, single/multi-valued attribute dan derived attribute. d. Menentukan attribute domain Bertujuan untuk menentukan attribute domain pada conceptual data model. Contohnya yaitu menentukan nilai attribute jenis_kelamin pada entity mahasiswa dangan ‘M’ atau ‘F’ atau nilai attribute sks pada entity mata_kuliah dengan ‘1’, ’2’, ‘3’ dan ‘4’ e. Menentukan candidate key dan primary key attributes Bertujuan untuk mengidentifikasi candidate key pada setiap entity dan memilih primary key jika ada lebih dari satu candidate key. Pemilihan primary key didasari pada panjang dari attribute dan keunikan key di masa datang. f. Mempertimbangkan penggunaan enhance modeling concepts (pilihan) Pada langkah ini bertujuan untuk menentukan specialization, generalization, aggregation, composition. Dimana masing-masing pendekatan dapat dilakukan sesuai dengan kebutuhan yang ada. Specialization dan generalization adalah proses dalam mengelompokan beberapa entity dan menghasilkan entity yang baru. Beda dari keduanya adalah cara prosesnya, dimana spesialisasi menggunakan proses top-down dan generalisasi menggunakan proses bottom-up. Aggregation menggambarkan sebuah entity types dengan sebuah relationship types dimana suatu relasi hanya akan ada jika telah ada relationship lainnya. g. Mengecek redundansi Bertujuan untuk memeriksa conceptual model untuk menghindari dari adanya informasi yang redundan. Yang dilakukan pada langkah ini adalah: 1. Memeriksa kembali one-to-one relationship. Setelah entity diidentifikasikan maka kemungkinan ada dua entity yang mewakili satu objek. Untuk itu dua entity tersebut harus di-merger bersama. Dan jika primary key-nya berbeda maka harus dipilih salah satu dan lainnya dijadikan alternate key. 2. Menghilangkan relasi yang redundansi. Untuk menekan jumlah model data, maka relationship data yang redundan harus dihilangkan. h. Memvalidasi conceptual model dengan transaksi. Bertujuan untuk menjamin bahwa conceptual data model mendukung kebutuhan transaksi. Dengan menggunakan model yang telah divalidasi tersebut, dapat digunakan untuk melaksanakan operasi secara manual. Ada dua pendekatan yang mungkin untuk mejamin bahwa local conceptual data model mendukung kebutuhan transaksi yaitu : 1. Mendeskripsikan transaksi Memeriksa seluruh informasi (entities, relationship, dan attribute) yang diperlukan pada setiap transaksi yang disediakan oleh model dengan mendokumentasikan penggambaran dari tiap kebutuhan transaksi. 2. Mengunakan transaksi pathways Pendekatan kedua, untuk memvalidasi data model dengan keperluan transaksi yang melibatkan diagram yang mewakili pathways diambil dari tiap transaksi secara langsung yang terdapat pada E-R diagram menggambarkan komponen-komponen dari entity dan relasi yang masing-masing dilengkapi dengan attribute-attribute yang merepresentasikan seluruh fakta dari real-world yang kita tinjau (Fathansyah,1999,p79). Sedangkan menurut Silberschartz (2002,p42), E-R diagram dapat menyatakan keseluruhan struktur logical dari basis data dengan menggunakan bagan. i. Melihat kembali conceptual data model dengan pengguna. Bertujuan untuk melihat kembali conceptual model dan memastikan bahwa data model tersebut sudah benar. 2. Logical Database Design Logical database design adalah proses pembuatan suatu model informasi yang digunakan pada perusahan berdasarkan pada model data yang spesifik, tetapi tidak tergantung dari Database Management System (DBMS) yang khusus dan pertimbangan fisik yang lain (Connolly,2002,p441). DBMS adalah software yang memungkinkan pemakai untuk mendefinisi, membuat, memelihara, dan mengontrol akses ke basis data (Connolly,2002,p16). Fasilitas-fasilitas yang disediakan oleh DBMS antara lain : 1. Memperbolehkan user untuk mendefinisikan basis data. 2. Memperbolehkan user untuk menambah , mengubah, dan menghapus serta mengambil data dari basis data. 3. Menyediakan kontrol akses ke basis data. Seperti security, integrity, concurrency control, recovery control system dan user-accessible catalog. Langkah kedua : membuat dan memvalidasi local logical data model untuk setiap pandangan. Bertujuan untuk membuat local logical data model dari local conceptual data model yang mempresentasikan pandangan khusus dari perusahaan dan memvalidasi model tersebut untuk menjamin kebenaran strukturnya (dengan menggunakan teknik normalisasi) dan menjamin bahwa model tersebut mendukung kebutuhan transaksi. Menurut Conolly (2002,p376), normalisasi merupakan suatu teknik untuk menghasilkan suatu relasi yang sangat diperlukan dimana kebutuhan datanya diberikan oleh perusahaan. Dalam proses normalisasi membutuhkan beberapa tahap untuk dapat diimplementasikan. Tahap-tahap normalisasi menurut (Conolly,2002,p387) adalah : a. Bentuk tidak normal (UNF) Merupakan bentuk normalisasi dimana terdapat tabel yang memiliki satu atau lebih data yang berulang. b. Bentuk normal pertama (1NF) Merupakan bentuk normalisasi dimana data yang dikumpulkan menjadi satu field yang sifatnya tidak akan berulang dan tiap field mempunyai satu nilai. c. Bentuk normal kedua (2NF) Merupakan bentuk normalisasi dimana field yang bukan kunci tergantung secara fungsi pada suatu primary key. d. Bentuk normal ketiga (3NF) Merupakan bentuk normalisasi dimana tidak ada field yang bukan primary key tergantung transitive kepada primary key. e. Bentuk BCNF (Boyce-Codd Normal Form) Merupakan bentuk normalisasi dimana jika dan hanya jika setiap determinant adalah candidate key. Pada perancangan model logical langkah kedua, tahapan-tahapannya adalah : a. Menghilangkan features yang tidak compatible dengan model relasional (pilihan). Bertujuan untuk menghasilkan model yang kompatibel dengan model relasional. Yaitu dengan : 1. Menghilangkan many-to-many (*:*) binary relationship types 2. Menghilangkan many-to-many (*:*) recursive relationship types 3. Menghilangkan complex relationship types 4. Menghilangkan multi-valued attributes b. Memperoleh relasi untuk local logical data model. Bertujuan untuk membuat hubungan logical model yang mewakili entity, relationship dan attribute yang telah didefinisi. Mendeskripsikan komposisi tiap hubungan memakai Database Definition Language (DDL) untuk relasi yang diikuti dengan daftar dari relasi attribute yang mudah lalu mengidentifikasikan primary key dan foreign key dari suatu relasi. Untuk memperoleh relasi untuk local data model, maka diperlukan penjelasan untuk mendeskripsikan struktur yang mungkin dalam data model saat ini. Langkah ketiga : Membuat dan memvalidasi global logical data model. Bertujuan untuk menyatukan local logical data model menjadi global logical data model. Pada perancangan model logikal langkah ketiga, tahapan-tahapannya adalah : a. Menggabungkan local logical data model menjadi global model Pada langkah ini, setiap local logical data model menghasilkan E-R diagram, skema relasional, kamus data dan dokumen pendukung yang mendeskripsikan constraints dari model. Beberapa tugas yang harus dikerjakan adalah sebagai berikut : 1. Memeriksa lembali nama dan isi dari entities dari relationships dan candidate key. 2. Memeriksa kembali nama dan isi dari relationships/ foreign keys. 3. Menggabungkan entities atau hubungan dari local data model. 4. Mengikutsertakan (tanpa menggabungkan) entities atau relationships yang unik pada tiap local data model. 5. Menggabungkan relationships atau foreingn key dari local data model. 6. Mengikutsertakan (tanpa menggabungkan) relationships atau foreign key unik pada tiap local data model. 7. Memeriksa untuk entities (hubungan) dan relationships atau foreign key. 8. Memeriksa integrity constraints. 9. Menggambarkan ER-diagram. 10. Melakukan update dokumen. b. Memvalidasi global logical data model Bertujuan untuk memvalidasi relasi yang dibuat dari global logical data model dengan teknik normalisasi dan menjamin bahwa model tersebut mendukung kebutuhan transaksi c. Mengecek pertumbuhan yang akan datang Bertujuan untuk menentukan apakah ada perubahan yang signifikan seperti keadaan yang tidak terduga dimasa mendatang dan menilai apakah model logikal tersebut dapat menampung atau menyesuaikan perubahan yang terjadi. d. Melihat kembali global logical data model dengan pengguna Bertujuan untuk menjamin model data logikal yang bersifat global telah tepat untuk perusahaan. 3. Physical Database Design Physical database design adalah suatu proses untuk menghasilkan gambaran dari implementasi basis data pada tempat penyimpanan, menjelaskan dasar dari relasi, organisasi file dan indeks yang digunakan untuk efisiensi data dan menghubungkan beberapa integrity constraints dan tindakan keamanan (Connolly,2002,p478). Langkah keempat : Menterjemahkan global logical data model untuk target DBMS. Bertujuan untuk menghasilkan skema basis data relasional dalam global logical data model yang dapat diimplemetasikan ke DBMS. Pada perancangan model physical, langkah-langkahnya adalah : a. Merancang basis relasional Dalam memulai merancang physical design, diperlukan untuk mengumpulkan dan memahami informasi tentang relasi yang dihasilkan dari logical database design. Informasi yang penting bisa didapatkan dari kamus data dan DDL. b. Merancang representasi dari data yang diperoleh Bertujuan untuk menentukan bagaimana setiap data yang diperoleh mewakili global logical data model ke dalam DBMS. c. Merancang enterprise constraints Pada langkah ini bertujuan untuk merancang batasan-batasan yang ada pada perusahaan. Langkah kelima : Merancang representasi physical. Bertujuan untuk menentukan organisasi file yang optimal untuk penyimpanan dan menentukan indeks yang dibutuhkan untuk meningkatkan performa. Terdapat tiga faktor yang memungkinkan digunakannya representasi physical : 1. Transaction throughput 2. Response time 3. Disk storage Dalam langkah kelima ini perlu untuk memahami system resources untuk meningkatkan performa basis data. a. Main memory Dengan semakin besar main memory yang ada maka akan dapat meningkatkan performa DBMS dan aplikasi basis data yang digunakan. b. CPU CPU mengontrol tugas-tugas dari system resources lain dan mengeksekusi prosesnya. c. Disk I/O Dengan menggunakan DBMS yang besar, maka disk I/O yang diperlukan sangat signifikan dalam menyimpan dan mengambil data. Untuk menghindari kemacetan transfer data, maka : a. File sistem operasi harus dipisahkan dari file basis data. b. File utama basis data harus dipisahkan dari file indeks. c. File recovery log harus dipisahkan dari basis data yang sedang tidak digunakan. d. Network Ketika jumlah data yang ditransfer telah banyak, maka dengan menggunakan network sangat dianjurkan. Selain itu juga untuk menghindari dari kemacetan dalam mentransfer data. Pada langkah kelima ini, tahapan-tahapannya adalah : a. Menganalisis transaksi Bertujuan untuk mengerti fungsi dari transaksi yang dijalankan pada basis data dan menganalisa transaksi yang penting. Kriteria kemampuan yang harus diidentifikasikan dalam menganalisa transaksi adalah : 1. Transaksi dapat berjalan secara sering dan akan mempunyai dampak yang signifikan pada performa. 2. Transaksi yang kritis pada operasi dan bisnis. 3. Waktu selama sehari atau seminggu ketika akan ada permintaan yang tinggi pada saat basis data dibuat. a. Memilih file organisasi Bertujuan untuk menyimpan data secara tepat ke tempat penyimpanan data. Ada beberapa pilihan struktur penyimpanan (Silberschatz,2002,p422), yaitu : 1. Heap 2. Hash 3. Sekuensial berindeks 4. Clusters a. Memilih indeks Bertujuan untuk meningkatkan performa dalam suatu sistem basis data. Salah satu pendekatan untuk memilih organisasi file yang cocok untuk relasi adalah untuk menyimpan tuples yang tidak disimpan dan dibuat sebanyak secondary indexes sebagaimana diperlukan. Oleh karena itu, atribut yang digunakan adalah: 1. Atribut yang sering digunakan untuk join operations untuk membuat lebih efisien. 2. Atribut yang sering dipesan untuk mengakses tuples pada suatu relasi didalam urutan yang menunjukkan atribut. Memperkirakan kebutuhan ruang penyimpanan Bertujuan untuk memperkirakan jumlah ruang penyimpanan yang akan diperlukan dalam basis data. Perkiraannya didasari pada ukuran setiap tabel dalam suatu relasi. Contohnya dalam lima tahun mendatang berapa kapasitas hard disk yang dibutuhkan untuk menampung data. Langkah keenam : Merancang pandangan pengguna. Bertujuan untuk merancang pandangan pengguna yang telah diidentifikasi selama mengumpulkan kebutuhan dan menganalisis langkah dari relasional Database Application Lifecycle. Contohnya pada branch terdiri dari direktur dan manajer pandangan. Langkah ketujuh : Merancang keamanan. Dalam sebuah sistem basis data, keamanan adalah elemen yang sangat penting mengingat isi dari basis data berupa informasi yang sangat penting. menurut Silberschatz (2002,p239) ukuran keamanan yang dapat diambil untuk melindungi basis data antara lain dari segi : 1. Sistem basis data : ada beberapa pengguna berwenang yang dizinkan untuk mengakses bagian basis data tertentu dan ada para pengguna yang lain hanya diizinkan untuk membaca data yang diinginkannya, tetapi tidak punya hak untuk mengubahnya. Kewajiban dari sistem basis data ini adalah menjaga batasan seperti di atas tetap terjaga. 2. Sistem operasi : tidak peduli betapa aman sistem basis datanya, apabila terjadi kelemahan dalam sistem operasi. Hal ini sama artinya dengan adanya akses yang tidak diinginkan dalam basis data. Jadi tingkat keamanan perangkat lunak dalam sistem operasi sangatlah penting seperti halnya keamanan yang dilakukan secara fisik. 3. Jaringan : seluruh sistem basis data memperbolehkan untuk mengakses lewat terminal atau jaringan, keamanan software-level dalam software jaringan sangat penting sebagai keamanan fisik, keduanya dibutuhkan dalam internet dan jaringan pribadi. 4. Fisik : situs yang mengandung sistem komputer harus secara fisik aman dari entri secara diamdiam dan bahaya oleh para penyelundup. 5. Manusia : otorisasi pada pengguna harus dilakukan secara hati-hati untuk mengurangi adanya kejadian dimana pengguna yang berwenang memberikan akses kepada orang lain dengan imbalan suap atau lainnya. Langkah kedelapan : Mempertimbangkan pengenalan dan redundansi kontrol. Pada langkah physical database design ini mempertimbangkan denormalisasi skema relational untuk meningkatkan performa. Hasil dari normalisasi adalah perancangan basis data logikal secara structural, konsisten, dan menekan jumlah redudansi. Faktor yang perlu dipertimbangkan adalah : 1. Denormalisasi membuat implementasi lebih kompleks 2. Denormalisasi selalu mengorbankan fleksibilitas 3. Denormalisasi akan membuat cepat dalam retrieve data tetapi lambat dalam update. Ukuran performa dari suatu perancangan basis data dapat dilihat dari sudut pandang tertentu yaitu melalui pendekatan efisiensi data (Normalisasi) atau pendekatan efisiensi proses (Denormalisasi). Efisiensi data dimaksudkan untuk meminimalkan kapasitas disk, dan efisiensi proses dimaksudkan untuk mempercepat proses saat retrieve data dari basis data. Langkah kesembilan : Memonitor dan memasang sistem operasi. Bertujuan untuk memonitor sistem operasi, meningkatkan performa dan menentukan perancangan sistem yang tepat atau menggambarkan perubahan kebutuhan. 2.2.4.5 Pemeliharaan Operasional Suatu proses untuk memonitor dan merawat sistem setelah instalasi. Dalam langkah-langkah yang sebelunmya,aplikasi basis data telah secara penuh diterapkan dan dituju. Sistem sekarang sudah berpindah ke suatu langkah pemeliharaan, yang melibatkan aktifitas berikut (Connoly,2005,p306): 1. Monitoring Performance dari system, jika performance jatuh di bawah suatu tingkatan yang bisa diterima, setting ulang atau reorganisasi basis data mungkin diperlukan. 2. Maintaning dan meningkatkan mutu aplikasi basis data (jika diperlukan), kebutuhan baru disatukan ke dalam aplikasi data dengan mengikuti langkah-langkah sebelumnya yang terdapat dalam database life cycle. Ketika aplikasi basis data sedang beroperasi, perlu dilakukan monitoring secra dekat untuk memastikan bahwa performance dalam tingkatan yang bisa diterima. Suatu DBMS secara normal menyediakan berbagai kegunaan untuk membantu administrasi basis data yang mencakup kegunaan untuk mengisi data ke dalam suatu basis data dan memonitor system tersebut. Kegunaan yang mengizinkan system melakukan monitoring secara berdampingan atau berhadapan informasi sebagai contoh, pemakaian basis data mengunci efisiensi dan query strategi pelaksanaan. Database Administrator (DBA) dapat menggunakan informasi ini untuk menyetel system dan untuk memberi performance yang lebih naik, sebagai contoh dengan menciptakan index tambahan untuk mempercepat query, dengan mengubah struktur basis data, atau dengan melakukan kombinasi terhadap table yang ada. Monitoring Process akan terus berlanjut pada sepanjang hidup suatu aplikasi basis data dan pada waktu tertentu boleh melakukan reorganisasi basis data untuk mencukupi kebutuhan dalam system. Perubahan ini menyediakan informasi pada evolusi system dan sumber daya yang ada pada masa yang akan datang mungkin diperlukan. Hal ini memungkinkan DBA untuk terlibat dalam perencanaan kapasitas dan untuk memberi tahu staff senior untuk melakukan penyesuaian rencana jika DBMS kekurangan kegunaan tertentu, DBA dapat mengebangkan kegunaan yang diperlukan atau membeli tools tambahan. 2.2.4.6 Sistem Development Life Cycle (SDLC) Sistem Development Life Cycle (SDLC) adalah keseluruhan proses dalam membangun system melalui beberapa langkah. Metode pengembangan perangkat lunak dikenal dengan istilah SDLC (Software Development Life Cycle). Metodologi ini menjadi perhatian sangat istimewa pada proses rekayasa perangkat lunak. Karena dengan metodologi SDLC yang digunakan akan sangat menentukan sukses tidaknya proyek software. Salah satu metode yang digunakan dalam SDLC adalah Waterfall Model. 1. Metode Waterfall Model Model rekayasa piranti lunak yang diuraikan oleh Roger S. Pressman (1992: 24) salah satunya adalah waterfall model. Model ini memberikan pendekatan-pendekatan sistematis dan berurutan bagi pengembangan piranti lunak. Berikut adalah gambar pengembangan system perangkat lunak dengan proses SDLC (Sistem Development Life Cycle) dengan Waterfall Model. Gambar 2.1 Waterfall Model Penjelasan dari tahap-tahap Waterfall Model adalah sebagai berikut: 1. Perancangan Sistem (System Enginering) Perancangan system sangat diperlukan, karena piranti lunak biasanya merupakan bagian dari suatu system yang lebih besar. Pembuatan sebuah piranti lunak dapat dimulai dengan melihat dan mencari apa yang dibutuhkan oleh system. Dari kebutuhan system tersebut akan diterapkan kedalam piranti lunak yang dibuat. 2. Analisa Kebutuhan Piranti Lunak (Software Requirement Analysis) Merupakan proses pengumpulan kebutuhan piranti lunak. Untuk memahami dasar dari program yang akan dibuat, seorang analisis harus mengetahui ruang lingkup informasi, fungsi-fungsi yang dibutuhkan, kemampuan kinerja yang ingin dihasilkan dan perancangan antarmuka pemakai piranti lunak tersebut. 3. Perancangan Perancangan piranti lunak merupakan proses bertahap yang memfokuskan pada empat bagian penting, yaitu: Struktur data, arsitektur piranti lunak, detail prosedur, dan karakteristik antarmuka pemakai. 4. Pengkodean (Coding) Pengkodean piranti lunak merupakan proses penulisan bahasa program agar piranti lunak tersebut dapat dijalankan oleh mesin. 5. Pengujian (Testing) Proses ini akan menguji kode program yang telah dibuat dengan memfokuskan pada bagian dalam piranti lunak. Tujuannya untuk memastikan bahwa semua pernyataan telah diuji dan memastikan juga bahwa input yang digunakan akan menghasilkan output yang sesuai. Pada tahap ini pengujian dibagi menjadi dua bagian, pengujian internal dan pengujian eksternal. Pengujian internal bertujuan menggambarkan bahwa semua statement sudah dilakukan pengujian, sedangkan eksternal bertujuan untuk menemukan kesalahan serta memastikan output yang dihasilkan sesuai dengan yang diharapkan. 6. Pemeliharaan (Maintenance) Proses ini dilakukan setelah piranti lunak telah digunakan oleh pemakai atau konsumen. Perubahan akan dilakukan jika terdapat kesalahan, oleh karena itu piranti lunak harus disesuaikan lagi untuk menampung perubahan kebutuhan yang diinginkan konsumen. 2.2.4.7 Data Flow Diagram (DFD) Data Flow Diagram adalah suatu diagram yang menggunakan notasi-notasi untuk menggambarkan arus dari data system, yang penggunaannya sangat membantu untuk memahami system secara logika, terstruktur dan jelas. DFD ini sering disebut juga dengan nama Bubble Chart, Bubble Diagram, Model Proses, Diagram Alur Kerja atau Model Fungsi. DFD didesain untuk menunjukkan sebuah system yang terbagi-bagi menjadi suatu bagian sub-sistem yang kecil untuk menandai arus data antara kedua hal diatas. Diagram ini lalu dikembangkan untuk melihat lebih rinci sehingga dapat terlihat model-model yang terdapat di dalamnya. a. Tujuan Data Flow Diagram (DFD) DFD memiliki tujuan sebagai berikut: 1. Memberikan indikasi mengenai bagaimana data ditransformasi pada saat data bergerak melalui system. 2. Menggambarkan fungsi-fungsi dan sub fungsi yang metransformasi aliran data. b. Manfaat Data Flow Diagram (DFD) DFD memiliki manfaat sebagai berikut: 1. DFD adalah alat pembuatan model yang memungkinkan professional system untuk menggambarkan system sebagai suatu jaringan proses fungsional yang dihubungkan satu sama lain dengan alur data, baik secara manual maupun komputerisasi. 2. DFD ini adalah salah satu alat pembuatan model yang sering digunakan, khususnya bila fungsifungsi system merupakan bagian yang lebih penting dan kompleks daripada data yang dimanipulasi oleh system. Dengan kata lain, DFD adalah alat pembuatan model yang memberikan penekanan hanya pada fungsi system. 3. DFD ini merupakan alat perancangan system yang berorientasi pada alur data dengan konsep dekomposisi dapat digunakan untuk penggambaran analisa maupun rancangan system yang mudah dikomunikasikan oleh professional system kepada pemakai maupun pembuat program. c. Simbol DFD Simbol-simbol yang terdapat dalam DFD diuraikan sebagai berikut: 1. Terminator/Kesatuan Luar (External Entity) Setiap system pasti mempunyai batas system (boundary) yang memisahkan suatu system dengan lingkungan luarnya. Kesatuan luar (external entity) merupakan kesatuan di lingkungan luar system yang berupa orang, oraganisasi atau system lainnya yang berada di lingkungan luarnya yang akan memberikan input atau menerima output dari system (Jogiyanto, 1989). Suatu kesatuan luar dapat disimbolkan dengan suatu notasi kotak. Notasi Terminator/Kesatuan Luar DFD Terminator dapat berupa orang, sekelompok orang, organisasi, departemen di dalam organisasi, atau perusahaan yang sama tetapi diluar kendali system yang sedang dibuat modelnya. Atau juga dapat berupa departemen, divisi atau system di luar system yang berkomunikasi dengan system yang sedang dikembangkan. 2. Arus Data (Data Flow) Arus Data (Data Flow) di DFD diberi symbol suatu panah. Arus data ini mengalir diantara proses (Process), simpanan data (Data Store) dan kesatuan luar (External Entity). Arus data ini menunjukkan arus data yang dapat berupa masukkan untuk sistem atau hasil dari proses system. Notasi Arus Data di DFD Arus Data dapat berbentuk sebagai: a. Formulir atau dokumen yang digunakan perusahaan. b. Laporan tercetak yang dihasilkan system. c. Output dilayar computer d. Masukkan untuk computer e. Komunikasi ucapan f. Surat atau memo g. Data yang dibaca atau direkam di file h. Suatu isian yang dicatat pada buku agenda i. Transmisi data dari suatu computer ke computer lain. 3. Proses (Process) Suatu proses adalah kegiatan atau kerja yang dilakukan oleh orang, mesin atau computer dan hasil suatu arus data yang masuk ke dalam proses untuk dilakukan arus data yang akan keluar dari proses. Suatu proses dapat ditunjukkan dengan symbol lingkungan atau dengan symbol empat persegi panjang tegak dengan sudut-sudut tumpul. Notasi Proses di DFD Ada beberapa hal yang perlu diperhatikan tentang proses: a. Proses harus memiliki input dan output b. Proses dapat dihubungkan dengan komponen terminator, data store atau proses melalui alur data. c. Sistem/bagian/divisi/departemen yang sedang dianalisis oleh professional system digambarkan dengan komponen proses. 4. Simpanan Data (Data Store) Simpanan data (Data Store) merupakan simpanan dari data yang dapat berupa file atau database di system computer, arsip atau catatan manual, kotak tempat data di meja seseorang, table acuan manual, agenda atau buku. Simpanan data di DFD dapat disimbolkan dengan sepasang garis horizontal parallel yang tertutup di salah satu ujungnya. Gambar 2.4.1 Notasi dari Simpanan Data di DFD 2.2.4.8 State Transition Diagram (STD) State Transition Diagram menggambarkan bermacam–macam keadaan sebuah komponen system yang terdapat dalam relasi pada kejadian–kejadian atau kondisi–kondisi yang menyebabkan sebuah perubahan dari sebuah keadaan ke keadaan lainnya. State Transition menurut Hawryszkiewycz (1998, p243) adalah perubahan dari satu keadaan ke keadaan lainnya dalam suatu alur program aplikasi. Jadi State Transition Diagram adalah diagram yang menggambarkan perubahan dari satu keadaan ke keadaan lainnya. State Transition Diagram merupakan suatu modeling tool yang menggambarkan sifat ketergantungan pada waktu dari suatu sistem. Maksudnya ialah sistem (mesin atau komputer) menunggu masukkan dari luar sistem, misalnya menunggu nada panggil untuk mesin penjawab telepon, menunggu masuknya password untuk mesin ATM dan sebagainya. a. Notasi State Transition Diagram Notasi yang digunakan dalam State Transition Diagram ada dua, yaitu State yang disimbolkan dengan segi empat. Notasi State Ada dua jenis state yaitu State Awal (Initial State) dan State Akhir (Final State). Initial State hanya diperbolehkan satu saja, sedangkan Final State dapat lebih dari satu. Dikatakan Final State jika tidak ada perubahan keadaan dari keadaan tersebut ke keadaan lainnya. Jika ternyata masih ada dan Final State-nya hanya satu, maka akan terjadi looping terus menerus tanpa pernah berhenti. Notasi lainnya adalah Transisi State/Perubahan State yang disimbolkan dengan anak panah. Notasi Transisi State Setiap panah diberikan label yang menunjukkan kejadian (event) yang akan menyebabkan perubahan dari satu state ke state lainnya. Label tersebut adalah Kondisi dan Aksi. Kondisi adalah suatu event pada lingkungan eksternal yang dapat dideteksi oleh sistem yang menyebabkan perubahan terhadap state dari state menunggu ke state menunggu lainnya atau dari suatu aktivitas ke aktivitas lainnya, misalnya interupt. Aksi adalah reaksi terhadap kondisi yang menghasilkan output, misalnya pesan di layar. Ada dua cara pendekatan dalam membuat State Transition Diagram, yaitu: 1. Identifikasi setiap kemungkinan dari system dan gambarkan masing-masing pada sebuah kotak, lalu buatlah hubungan antara state tersebut. 2. Mulai dengan state pertama dan dilanjutkan dengan state berikutnya sesuai dengan aliran yang diinginkan. 2.3 Teori Khusus 2.3.1 Bahasa Jepang Bahasa Jepang ( 日本語; romaji: Nihongo) merupakan bahasa resmi di Jepang dan jumlah penutur 127 juta jiwa. Bahasa Jepang juga digunakan oleh sejumlah penduduk negara yang pernah ditaklukkannya seperti Korea dan Republik Cina. Ia juga dapat didengarkan di Amerika Serikat (California dan Hawaii) dan Brasil akibat emigrasi orang Jepang ke sana. Namun keturunan mereka yang disebut 二世, generasi kedua), tidak lagi fasih dalam bahasa tersebut. nisei ( Bahasa Jepang terbagi kepada dua bentuk yaitu Hyoujungo ( Kyoutsugo ( 標準語), pertuturan standar, dan 共通語), pertuturan umum. Hyoujungo adalah bentuk yang diajarkan di sekolah dan digunakan di televisi dan segala perhubungan resmi. LAFAL VOKAL Bahasa Jepang mempunyai 5 huruf vokal yaitu /a/, /i/, /u/, /e/, dan /o/. Lafal vokal bahasa Jepang mirip bahasa Melayu. Contohnya: 1. /a/ seperti "bapa" 2. /i/ seperti "ibu" 3. /u/ seperti "urut" 4. /e/ seperti "esok" 5. /o/ seperti "obor" 漢字 Tulisan bahasa Jepang berasal dari tulisan bahasa China ( /kanji) yang diperkenalkan pada abad keempat Masehi. Sebelum ini, orang Jepang tidak mempunyai sistem penulisan sendiri. Tulisan Jepang terbagi kepada tiga: 漢字) yang berasal dari China 2. aksara Hiragana (ひらがな) dan 3. aksara Katakana (カタカナ); keduanya berunsur daripada tulisan kanji dan dikembangkan 1. aksara Kanji ( pada abad kedelapan Masehi oleh rohaniawan Buddha untuk membantu melafazkan karakterkarakter China. TULISAN BAHASA JEPANG Kedua aksara terakhir ini biasa disebut kana dan keduanya terpengaruhi fonetik Bahasa Sanskerta. Hal ini masih bis a dilihat dalam urutan aksara Kana. Selain itu, ada pula sistem alihaksara yang disebut romaji. Bahasa Jepang yang kita kenal sekarang ini, ditulis dengan menggunakan kombinasi aksara Kanji, Hiragana, dan Katakana. Kanji dipakai untuk menyatakan arti dasar dari kata (baik berupa kata benda, kata kerja, kata sifat, atau kata sandang). Hiragana ditulis sesudah kanji untuk mengubah arti dasar dari kata tersebut, dan menyesuaikannya dengan peraturan tata bahasa Jepang. KANA Aksara Hiragana dan Katakana (kana) memiliki urutan seperti dibawah ini, memiliki 46 set huruf masing-masing. Keduanya (Hiragana dan Katakana) tidak memiliki arti apapun, seperti abjad dalam Bahasa Indonesia, hanya melambangkan suatu bunyi tertentu, meskipun ada juga kata-kata dalam bahasa Jepang yang terdiri dari satu 'suku kata', seperti me (mata), ki (pohon), ni (dua), dsb. Abjad ini diajarkan pada tingkat pra-sekolah (TK) di Jepang. ひらがな、平仮名 ) adalah suatu cara penulisan bahasa Jepang dan mewakili sebutan sukukata. Pada masa silam, ia juga dikenali sebagai onna de (女手) atau 'tulisan wanita' Hiragana ( karena biasa digunakan oleh kaum wanita. Kaum lelaki pada masa itu menulis menggunakan tulisan Kanji dan Katakana. Hiragana mula digunakan secara luas pada abad ke-10 Masehi. Kegunaan Hiragana 1. menulis akhiran kata (okurigana, Yang bercetak tebal itulah okurigana. 送り仮名 ). Contoh: okuru (mengirim) ditulis: 送 る . 2. menulis kata keterangan (adverb), beberapa kata benda (noun) dan kata sifat (adjektif). 3. perkataan-perkataan yang penulisan Kanji-nya tidak diketahui atau sudah lama tidak digunakan. 4. menulis bahan bacaan anak-anak seperti buku teks, animasi dan komik (manga). 5. menulis furigana, dikenal juga dengan rubi, yaitu teks kecil di atas kanji, yang menandakan bagaimana suatu kata dibaca. Misalnya: べんきょう 勉強 Okurigana ( する 送り仮名 , secara harfiah "huruf yang menyertai") adalah akhiran kana di belakang akar kanji pada bahasa Jepang. Okurigana digunakan untuk menunjukkan bacaan kanji yang diinginkan. Okurigana juga dipakai untuk menuliskan infleksi (misal infleksi bentuk negatif). Pada penggunaan modern, okurigana hampir selalu ditulis dengan hiragana. Katakana dulunya juga umum digunakan untuk okurigana. Disambiguasi kanji, Okurigana digunakan untuk menunjukkan cara membaca kanji yang memiliki banyak bacaan. Karena suatu kanji, terutama yang paling umum, bisa digunakan untuk banyak kata, okurigana yang ditulis setelah kanji membantu pembaca untuk mengetahui kata yang dimaksud. Contoh pada kanji 上がる (agaru) 上 (atas): "memanjat/menyelesaikan", 上る (noboru) 上 dibaca "a" 上 dibaca "nobo" Contoh pada kanji 下 (bawah): 下さる (kudasaru) "memberi", 下 dibaca "kuda" 下りる (oriru) "turun", 下 dibaca "o" "memanjat/naik", Huruf-huruf Hiragana Alih aksara Hepburn Alih aksara Hepburn ( ヘボン式ローマ字 Hebon-shiki Rōmaji?) dinamakan untuk memperingati Pendeta James Curtis Hepburn, pencipta alih aksara bahasa Jepang ke dalam abjad Latin yang pertama kali digunakan Hepburn sewaktu menyusun kamus bahasa Jepang-Inggris edisi ke-3 terbitan tahun 1887. Perkumpulan Romanisasi Aksara Jepang atau Rōmajikai[1] merupakan organisasi yang pertama kali mengusulkan sistem Hepburn pada tahun 1885. Alih aksara Hepburn sudah mengalami revisi beberapa kali dan secara resmi disebut Shūsei 修正ヘボン式ローマ字 , Romaji sistem Hepburn yang Disempurnakan). Sebelumnya juga pernah dikenal sebagai Hyōjun-shiki Rōmaji ( 標準式ローマ字 , Romaji Hebon-shiki Rōmaji ( ? ? standar). Alih aksara Hepburn tradisional dan Hepburn yang Disempurnakan merupakan sistem romaji yang paling banyak dipakai. Sistem Hepburn didasarkan pada bunyi fonem bahasa Inggris. Penutur bahasa Inggris yang tidak familiar dengan bahasa Jepang umumnya bisa mengucapkan kata-kata dalam bahasa Jepang secara lebih akurat bila ditulis dengan sistem Hepburn dibandingkan sistem Kunrei-shiki Rōmaji. Alih aksara Hepburn lebih sering digunakan dalam buku pelajaran bahasa Jepang untuk orang asing. Sebaliknya, murid-murid sekolah di Jepang justru lebih akrab dengan sistem Kunrei-shiki Rōmaji. Variasi alih aksara Hepburn Alih aksara Hepburn terdiri dari 3 variasi: Hepburn Tradisional yang menuliskan vokal panjang dan suku kata yang berakhiran dengan "n" dengan berbagai cara. Hepburn Disempurnakan (Revised Hepburn) yang merupakan revisi dari Hepburn Tradisional. Sistem ini tidak lagi mengharuskan huruf "n" diganti menjadi "m" bila diikuti konsonan tertentu. Perpustakaan Kongres menggunakan sistem Hepburn Disempurnakan (revised Hepburn) dengan sebutan modified Hepburn. Hepburn Modifikasi (modified Hepburn) yang didasarkan pada Hepburn Disempurnakan dan perbaikan Hepburn Tradisional. Sistem ini menggunakan tanda diakritik (macron) di atas vokal panjang dan di atas huruf "n". Walaupun Hepburn Modifikasi sudah digunakan pada sebagian kamus bahasa Jepang-Inggris (misalnya Pocket Kenkyusha Japanese Dictionary terbitan Oxford University Press), penggunaannya terbatas di kalangan ahli linguistik. Dalam bahasa Inggris, istilah modified Hepburn kadangkadang digunakan untuk menyebut revised Hepburn. Standar Jepang untuk alih aksara Hepburn: Alih aksara Hepburn untuk papan nama stasiun, Huruf "n" yang digunakan untuk menulis suku kata yang berakhiran dengan "n" diganti dengan huruf "m" bila diikuti konsonan "b," "m," dan "p." Sistem ini diatur dalam lampiran peraturan Kementerian Transportasi Jepang No.398 tanggal 26 Juli 1947. Alih aksara Hepburn Kementerian Luar Negeri, Huruf "n" yang digunakan untuk menulis suku kata yang berakhiran dengan "n" diganti dengan huruf "m" bila diikuti konsonan "b," "m," dan "p. Alih aksara Hepburn Kementerian Transportasi Huruf "n" yang digunakan untuk menulis suku kata yang berakhiran dengan "n" tidak diganti dengan huruf "m" walaupun diikuti huruf "b," "m," dan "p." Sistem ini dipakai untuk menulis papan nama jalan atau papan petunjuk. Ciri khas Keistimewaan alih aksara Hepburn adalah pada ejaan yang didasarkan pada fonologi bahasa Inggris. Sebagai hasilnya, penutur bahasa Inggris lebih mudah mengucapkan suku kata untuk し yang ditulis sebagai "shi" dan bukan "si." Partikel へ ditulis sebagai "e". Partikel ha は ditulis sebagai "wa". Partikel wo を ditulis sebagai "o". Partikel he Vokal panjang Peraturan Hepburn yang Disempurnakan dan Hepburn Tradisional: Vokal panjang o and u ditulis dengan tanda diakritik macron sebagai ō dan ū. Vokal panjang e pada kata-kata asli bahasa Jepang atau bahasa Tionghoa ditulis sebagai ei Vokal panjang i pada kata-kata asli bahasa Jepang atau bahasa Tionghoa ditulis sebagai ii Semua vokal panjang pada kata-kata pinjaman dari bahasa asing ditulis dengan tanda diakritik macron. Peraturan Hepburn Modifikasi: Semua vokal panjang ditulis dengan huruf ganda, misalnya vokal panjang o ditulis sebagai oo. Suku kata berakhiran dengan "n" Peraturan Hepburn tradisional: Suku kata yang berakhiran dengan "n" ditulis dengan huruf "n" bila diikuti konsonan, tapi ditulis sebagai n' (dengan apostrof) bila diikuti huruf vokal dan y. Kalau n diikuti dengan konsonan labial seperti b, m, dan p harus ditulis sebagai m. Peraturan Hepburn yang Disempurnakan: Konsonan labial seperti b, m, dan p tidak memengaruhi penulisan n. Suku kata yang berakhiran dengan "n" dan diikuti huruf vokal atau y, "n" tetap ditulis sebagai n. Peraturan Hepburn modifikasi: Suku kata yang berakhiran dengan "n" selalu ditulis sebagai n dengan tanda diakritik macron (n ) seperti waktu menulis vokal panjang. Penggunaan apostrof pada huruf "n" menjadi tidak perlu lagi. Konsonan ganda っ Konsonan ganda yang dihasilkan sokuon " " seperti "sh" ditulis menjadi "ssh," "ch" menjadi "tch", dan "ts" menjadi "tts." Variasi penulisan Penulisan kata yang sama dengan berbagai variasi alih aksara Hepburn: Tōkyō: Penulisan yang dianggap standar, ditulis dengan tanda diakritik macron mengikuti sistem Hepburn tradisional dan Hepburn yang Disempurnakan. Tokyo: Kata-kata bahasa Jepang yang sudah dipungut ke dalam bahasa Inggris ditulis tanpa menggunakan tanda diakritik macron. Secara de facto merupakan sistem yang dipakai untuk papan petunjuk dan informasi dalam bahasa Inggris yang ada di Jepang. Tôkyô: Penulisan dengan menggunakan aksen sirkumfleks seperti diatur dalam sistem alih aksara Nihon-shiki dan Kunrei-shiki. Aksen sirkumfleks hanya dipakai jika program pengolah kata tidak memungkinkan penulisan macron. Tersedianya huruf Unicode membuat penulisan bahasa Jepang dengan aksen sirkumfleks semakin jarang ditemui. Toukyou: Kana untuk "ō" ditulis sebagai "ou" atau "oo," dan "ū" sebagai "uu." Penulisan seperti ini tidak lazim dan hanya digunakan para pemula. Berasal dari cara mengetikkan bahasa Jepang dengan papan ketik huruf Latin pada mesin ketik pengolah kata di Jepang yang disebut wāpuro. Tookyoo: Penulisan dengan menggandakan huruf untuk vokal panjang sesuai sistem Hepburn modifikasi. Sistem yang sama digunakan pada alih aksara JSL. Tanda baca Dalam kalimat bahasa Jepang tidak ada spasi yang memisahkan antara kata dan tidak ada spasi yang memisahkan antara kalimat. Walaupun bukan merupakan tanda baca yang baku, kadangkadang juga dijumpai penggunaan tanda tanya dan tanda seru di akhir kalimat. Tanda baca yang dikenal dalam bahasa Jepang: 句点/kuten) Fungsinya serupa dengan tanda baca titik yakni untuk mengakhiri kalimat. ( 読点 /toten) Fungsinya hampir serupa dengan tanda baca koma yakni untuk memisahkan ( bagian-bagian yang penting dalam kalimat agar lebih mudah dibaca Angka dan Sistem Penghitungan Bangsa Jepang pada zaman dahulu (dan dalam jumlah yang cukup terbatas pada zaman sekarang) menggunakan angka-angka Tionghoa, yang lalu dibawa ke Korea dan sampai ke Jepang. Berikut ini adalah daftar angka-angka Jepang. 一 S a t u 三 二 D u a 四 T i g a E m p at 五 L i m a 七 六 E n a m T u j u h 八 De lap an 九 Se mbi lan 十 Se pul uh Setelah Kekaisaran Jepang mulai dipengaruhi oleh Eropa, angka-angka Arab mulai digunakan secara besar-besaran, dan hampir mengganti sepenuhnya kegunaan angka Tionghoa ini. Dalam penggunaannya di Bahasa Jepang, dan untungnya juga agak mirip di bahasa Indonesia, angka-angka ini tidak bisa digunakan seperti itu saja untuk menyatakan sebuah jumlah dari sebuah barang, waktu dan sebagainya. Pertama-tama jenis barangnya harus dipertimbangkan, lalu ukurannya, dan akhirnya jumlahnya. Cara berhitung untuk waktu dan tanggal pun berbeda-beda, maka satu hal yang harus dilakukan adalah menghafalkan cara angka-angka ini bergabung dengan satuannya. Bilangan dalam bahasa Jepang dengan bahasa Melayu/Indonesia Bilangan Bahasa Jepang Bahasa Indonesia 0 rei nol 1 ichi satu 2 ni dua 3 san tiga 4 shi/yon empat 5 go lima 6 roku enam 7 shichi/nana tujuh 8 hachi delapan 9 kyū sembilan 10 jū sepuluh 20 ni-jū dua puluh 30 san-jū tiga puluh 40 shi-jū empat puluh 50 go-jū lima puluh 60 roku-jū enam puluh 70 shichi-jū tujuh puluh 80 hachi-jū delapan puluh 90 kyū-jū sembilan puluh 100 hyaku seratus 1000 sen seribu 10000 man sepuluh ribu 100000 jū-man seratus ribu 1000000 hyaku-man satu juta 100000000 oku seratus juta chō satu triliun 1000000000 000 Romaji Romaji ( ローマ字 rōmaji , aksara Romawi) adalah cara menulis (alihaksara) bahasa Jepang ? dengan menggunakan abjad Latin. Ada beberapa sistem alihaksara bahasa Jepang. Alihaksara yang paling dikenal adalah alihaksara Hepburn, Kunrei-shiki Rōmaji, dan Nihon-shiki Rōmaji. Ahli bahasa Jepang di zaman Meiji pernah mengusulkan aksara yang digunakan agar dikurangi agar bahasa Jepang menjadi lebih mudah dipelajari. Usulan yang serupa juga diajukan komite pendidikan Amerika Serikat yang datang ke Jepang atas undangan Panglima Tertinggi Sekutu dan menerbitkan hasil penelitiannya pada tanggal 31 Maret 1946. Tapi usulan menggunakan abjad Latin untuk bahasa Jepang mendapat kritikan keras dan langsung ditolak. Alih aksara Kunrei-shiki Kunrei-shiki Rōmaji ( 訓令式ローマ字 , Romaji Sistem Instruksi Kabinet) adalah salah satu ? cara menulis (alih aksara) bahasa Jepang dengan menggunakan abjad Latin. Sering cuma disebut Kunrei-shiki dan ditulis sebagai "Kunreisiki" menurut cara penulisan Kunrei-shiki. Kunrei-shiki hanya digunakan penutur asli bahasa Jepang di Jepang dan ahli linguistik yang meneliti bahasa Jepang. Kunrei-shiki sering disebut sistem Monbushō karena merupakan alih aksara yang diajarkan di sekolah-sekolah dasar yang diakui kementerian pendidikan Jepang. Kunrei-shiki telah ditetapkan Organisasi Internasional untuk Standardisasi sebagai ISO 3602. American National Standards Institute (ANSI) memberi rekomendasi pemakaian Kunrei-shiki setelah standar ANSI Z39.11-1972 American National Standard System for the Romanization of Japanese dibatalkan tahun 1994. Kunrei-shiki merupakan perbaikan dari alih aksara lama yang disebut Nihon-shiki (Nipponsiki). Sebagai contoh, kata かなづかい ditulis sebagai kanadukai menurut alih aksara Nihon-shiki, sedangkan menurut Kunrei-shiki ditulis sebagai kanazukai. Sejarah Buku tertua yang memuat penulisan bahasa Jepang dengan abjad Latin adalah Kisah Para Rasul yang diterbitkan tahun 1591. Judul ditulis dengan abjad Latin ejaan bahasa Portugis sebagai Santos no Gosagveo no uchi Nuqigaqi ( サントスの御作業の内抜書 ) atau "santosu no gosagyō no uchi ? nukikaki" menurut alihaksara Hepburn. Pada masa itu belum dikenal tabel yang menunjukkan daftar suku kata (kana) dalam bahasa Jepang dan padanannya dalam abjad Latin bahasa Portugis dan Belanda. Akibatnya romaji hanya digunakan terbatas di kalangan misionaris dan ilmuwan. Pada tahun 1867, tabel aksara kana dan padanannya dalam abjad Latin disusun pertama kali oleh James Curtis Hepburn. Alihaksara yang kemudian dikenal sebagai alihaksara Hepburn digunakan dalam edisi pertama kamus Jepang-Inggris Wa-eigo rinshūsei karya Hepburn. Alihaksara Hepburn berdasarkan abjad Latin yang digunakan dalam pengucapan bahasa Inggris. Ahli bahasa banyak mengkritik kegagalan alihaksara Hepburn dalam menuliskan bahasa Jepang sesuai pengucapan asli orang Jepang. Sebagai tandingan alihaksara Hepburn, Tanakadate Aikitsu mengusulkan Nihon-shiki Rōmaji yang didasarkan teori fonologi. Nihon-shiki Rōmaji cukup mendapat dukungan ahli bahasa Jepang di dalam dan luar negeri. Tapi sistem ini justru tidak disukai penutur bahasa Inggris karena pengucapan tidak berdasarkan lafal bahasa Inggris. Sebagai kompromi antara alihaksara Hepburn dan Nihon-shiki Rōmaji, pemerintah Jepang mengeluarkan Instruksi Kabinet No.3 tertanggal 21 September 1937 tentang alihaksara yang dikenal sebagai Kunrei-shiki Rōmaji. Di bawah pendudukan Sekutu, sistem Hepburn ditetapkan sebagai alihaksara resmi di Jepang oleh Panglima Tertinggi Sekutu untuk menggantikan sistem Kunrei-shiki. Pemerintah Jepang terus berusaha menghidupkan kembali alihaksara Kunrei-shiki hingga akhirnya berhasil menetapkannya kembali dengan Instruksi Kabinet No.1 tertanggal 29 Desember 1954. Penggunaan alihaksara Kunrei-shiki diwajibkan untuk "semua penulisan bahasa Jepang pada umumnya," dengan tambahan peraturan yang membatasi penggunaan alihaksara Hepburn dalam hubungan internasional dan sebagainya demi meneruskan tradisi yang sudah lazim. Alihaksara Kunrei-shiki (termasuk di dalamnya alihaksara Nihon-shiki) telah diakui Organisasi Internasional untuk Standardisasi dalam standar ISO 3602 Documentation -- Romanization of Japanese (kana script). Standar dalam negeri Sesuai Pengumuman Pemerintah No.1 Tahun 1954, standar alihaksara di dalam negeri Jepang adalah alihaksara Kunrei-shiki seperti tertera pada tabel 1. Alihaksara seperti tertera pada tabel 2 dimaksudkan untuk digunakan dalam hubungan internasional dan meneruskan tradisi yang sudah lazim. Alihaksara yang ditulis mengikuti tabel 2 harus dinyatakan dalam catatan kaki. Standar internasional Organisasi Internasional untuk Standardisasi menetapkan ISO3602 di tahun 1989 dengan alihaksara Kunrei-shiki. Sedangkan penulisan romaji menurut alihaksara Nihon-shiki digunakan secara terbatas. Standar Inggris-Amerika Standar alihaksara yang ditetapkan British Standards Institution dan American National Standards Institute keduanya memiliki isi yang sama. Standar ANSI telah dihapus tahun 1994 dan Amerika Serikat tidak lagi memiliki standar alihaksara romaji. Standar alihaksara kalangan terbatas Alihaksara Hepburn Kementerian Luar Negeri Kementerian Luar Negeri Jepang menggunakan sistem yang didasarkan alihaksara Hepburn untuk menulis nama orang di dalam paspor. Pada prinsipnya, vokal panjang tidak ditulis, dengan beberapa perkecualian seperti aksara vokal panjang yang ditulis sebagai "OH." オ Alihaksara Hepburn untuk papan petunjuk Seperti alihaksara Hepburn yang digunakan pada paspor, vokal panjang tidak ditulis pada papan nama jalan atau papan petunjuk. Menurut Instruksi Kabinet No.1 tahun 1954, huruf "n" ditetapkan sebagai bunyi yang memisahkan suku kata, dan tanda hubung digunakan sebagai pemisah antar suku kata, misalnya: Shin-Osaka. Sesuai standar Inggris-Amerika, huruf "c" yang diikuti huruf "ch" diganti dengan huruf "t," misalnya: (Butchiin?). 仏地院 Alihaksara Hepburn papan nama stasiun Penulisan dengan aksara Latin pada papan petunjuk kereta api di Jepang diatur dalam lampiran peraturan Kementerian Transportasi Jepang No.398 tanggal 26 Juli 1947. Alihaksara Hepburn yang Disempurnakan merupakan standar penulisan papan nama di stasiun kereta api. Di atas vokal panjang diberi tanda diakritik berupa garis (macron) di atas huruf vokal panjang. Huruf "n" yang diikuti huruf "b", "m", dan "p" berubah menjadi huruf "m." Tanda hubung dipakai sebagai pemisah antar suku kata. Huruf "c" yang diikuti huruf "ch" berubah menjadi huruf "t." 2.1 Tabel alihaksara Kunrei-shiki あ か a さ a あ い う え お a i u e o k k i s k u s i k e s u (Kombinasi kana) k o s e ん K ya s o k yu S ya k yo s yu s yo た a な a は a ま a t t n n a ら a わ a が a ざ a m r g z ば a ぱ a g z z i) b z g z p p i p u ( b ya b い う え お b yo p yu 2.2 Tabel alihaksara Hepburn あ ( zy o) yu p o z yo zy u) ya p e z ( o g yo yu zy a) b e g z o b u r yo yu ya d e r yu ya o d b i p g o e z u ) m yo n ( ( b ya o g u m yu r o e z i d r e u m h yo y e i h yu ya n yo o r u i g a r i w ( n H m t yo yu ya o e ) u N h m t yu ya o e y i) n h m ya o e u ( r n h T o e u i y だ n h t e u i m t u i h や t i (Kombinasi kana) p yo あ a か a さ a た a な a は a ま a や a ら a わ k s t n h h m f m i y m u ( i) r m y r ( e) r u m h yo m yu m yo y r ( h yu ya n yo o e r o ( wi ) n h m c ho yu ya o c n h s ho hu ya o e u i h s c n k yo hu ha o e s t n k yu ha o e u s t n k ya o e u i s t n k o e su i a s c o k e u hi e k u hi w u k i s ん we ) r ya r yu r yo o (wo) n が a ざ a だ i g g i z j i d a g u ji) z u ( g e z e ( zu ) g o z o d e g ya j a d o g yu j u ( ja) g yo j o ( ju) ( jo) ば a ぱ a b b i p b u p i b e p u b o P e b ya p o b yu p ya b yo p yu p yo