BAB 2 LANDASAN TEORI

advertisement
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
Download