DATABASE ADMINISTRATION Pertemuan ke-2: Memilih dan menginstall DBMS

Memilih dan Menginstal DBMS Memilih dan Menginstall DBMS  salah satu tugas DBA Asumsi : DBMS sudah terinstall  pekerjaan terselesaikan Memilih dan Menginstall DBMS  membutuhkan keahlian, pengetahuan, dan pertimbangan. Salah satu tugas utama yang terkait dengan tugas DBA adalah proses memilih dan menginstal sebuah DBMS. Banyak eksekutif bisnis dan TI profesional tanpa latar belakang manajemen database berasumsi bahwa sekali DBMS terinstal, sebagian besar pekerjaan sudah dikerjakan Memilih dan menginstal DBMS adalah bagian paling sulit dari pekerjaan DBA karena membutuhkan banyak keahlian, pengetahuan, dan pertimbangan.

Mendefinisikan strategi dari Organisasi DBMS Proses memilih DBMS yang cocok tidak sesulit dulu. Banyak organisasi besar dan menengah yang menginstall lebih dari satu DBMS. Siapa yang memilih dan menginstal semua DBMS itu ? dan mengapa?

Banyak perusahaan membeli DBMS tanpa memiliki planning. Mendefinisikan strategi dari Organisasi DBMS Banyak perusahaan membeli DBMS tanpa memiliki planning. Perusahaan membeli DBMS  kebutuhan bisnis atau aplikasi baru. Perusahaan membeli DBMS baru  keinginan untuk mendukung teknologi terbaru dan terbesar. Perusahaan membeli DBMS  tanpa evaluasi aplikasi kompatible dengan DBMS yang ada Banyak perusahaan membeli DBMS tanpa memiliki planning. Perusahaan membeli DBMS karena didorong oleh kebutuhan bisnis atau aplikasi baru. perusahaan membeli dari Software paket aplikasi yang tidak berjalan di salah satu platform DBMS keputusan untuk membeli DBMS baru didorong oleh keinginan untuk mendukung teknologi terbaru dan terbesar. Perusahaan membeli sebuah DBMS tanpa evaluasi apakah aplikasi yang dibuat dapat berjalan dengan DBMS yang ada DBA tidak memiliki kekuatan untuk menolak proposal DBMS baru.

Masalah : Apliasi yang ada  apakah kompatible dengan DBMS yang baru Perlu perubahan kode aplikasi DBMS yang lama  di maintenance, double job Tanpa terlebih dahulu memeriksa apakah aplikasi ini bisa berhasil dengan menggunakan DBMS yang ada. tidak kompatibel antara DBMS dan perlunya mengubah kode aplikasi. DBMS tua tetap dan harus terus didukung. Ini menyulitkan pekerjaan DBA.

Mendefinisikan strategi dari Organisasi DBMS Solusi DBA  menjadi pertimbangan utama pemilihan DBMS Unit usaha Membeli DBMS  approval dari DBA Fakta Grup DBA = teknis  kalah suara dari bisnis eksekutif lain Jadi apa yang harus dilakukan? DBA harus diberdayakan untuk membuat keputusan DBMS bagi organisasi. Seharusnya tidak ada unit usaha diizinkan untuk membeli sebuah DBMS tanpa izin dari DBA. Kenyataannya Sulit untuk diterapkan Grup DBA seringkali hanya memiliki hak suara yang lebih rendah daripada business executive yang lain

Grup DBA  aturan DBMS perusahaan Memilih DBMS Grup DBA  aturan DBMS perusahaan Aturan DBMS  mengurangi jumlah DBMS perusahaan Multiple DBMS di perusahaan  tentukan DBMS default Grup DBA harus memiliki aturan terkait DBMS yang digunakan perusahaan Aturan tsb harus dapat mengurangi jumlah DBMS yang digunakan Untuk sebuah perusahaan dengan multiple OS dan multiple type of hardware, harus ditentukan satu DBMS default Beberapa DBMS memilki fitur yang mirip Terkadang fitur yang tidak ada sekarang, bisa jadi ada dalam 18-24 bulan lagi

Jenis organisasi ( Konservatif atau Liberal ? ) Memilih DBMS Sistem operasi Jenis organisasi ( Konservatif atau Liberal ? ) Tingkatan yang dicapai (Benchmarks) Skalabilitas. Ketersediaan perangkat lunak pendukung. Teknisi. Biaya Kepemilikan. Jadwal Release Referensi pelanggan.

Sistem operasi Apakah DBMS yang dipilih support OS yang digunakan di perusahaan Atau OS menyesuaikan DBMS yang akan digunakan

Type of organization Organsiasi konservatif vs liberal Org konservatif  kekuasaan yang ketat Org konservatif  lingkungan mainframe tradisional Org konservatif  pemerintahan, keuangan, asuransi, kesehatan dll Org liberal  mempertimbangkan alternatif  manufaktur, universitas, dll Contoh beberapa org liberal  windows bukan OS utama  menggunakan DBMS multi OS Beberapa organisasi yang sangat konservatif dan ingin mempertahankan kekuasaan yang ketat di lingkungan mereka; organisasi-organisasi ini cenderung tertarik ke arah lingkungan mainframe tradisional. Perusahaan operasi pemerintah, lembaga keuangan, dan asuransi dan kesehatan biasanya cenderung konservatif. Organisasi yang lebih liberal-sering bersedia untuk mempertimbangkan arsitektur alternatif. Hal ini tidak biasa bagi perusahaan manufaktur, dotcom, dan universitas menjadi kurang konservatif. Akhirnya, beberapa perusahaan hanya tidak percaya Windows sebagai lingkungan mission-critical, dan lebih memilih untuk menggunakan UNIX-aturan ini di luar beberapa vendor database (Microsoft SQL Server, khususnya).

Benchmarks Benchmarks  oleh vendor dan pengguna DBMS The Transaction Processing Performance Council (TPC)  mengeluarkan benchmark untuk pedoman dasar penglahan DB Benchmark  untuk indikator kinerja DB  bukan penentu utama pemilihan DBMS Benchmark  tidak mewakili implementasi DBMS pada semua database produksi Benchmark  harus terus diperbaharui, mengingat setiap DBMS terus berkembang Tolok ukur kinerja apa yang tersedia dari vendor DBMS dan pengguna lain dari DBMS? The Transaction Processing Performance Council (TPC) menerbitkan tolok ukur kinerja database resmi yang dapat digunakan sebagai pedoman untuk kinerja keseluruhan dasar berbagai jenis pengolahan database. Secara umum, tolok ukur kinerja dapat berguna sebagai indikator luas kinerja database, tetapi tidak harus menjadi satu-satunya penentu ketika memilih DBMS. Banyak dari benchmark TPC dijalankan terhadap implementasi database yang tidak mewakili sebagian besar sistem database produksi, dan oleh karena itu bukan merupakan indikasi kinerja yang sebenarnya dari sebuah DBMS tertentu. Selain itu, benchmark terus diperbarui untuk menunjukkan pengukuran kinerja baru dan lebih baik untuk masing-masing produk DBMS utama, rendering patokan "pemenang" cepat menjadi kadaluarsa

Scalability DBMS  harus mendukung jumlah pengguna dan ukuran DB DBMS  apakah ada konfirmasi dari pengguna independen

Availability of supporting software tools DBMS harus support tools data, antara lain : Query dan tools analisa Tools pendukung data warehouse Tolls pendukung DB Tools backup dan recovery Tools monitoring kinerja Tool planing kapasitas DB utilitas Dukungan berbagai Bahasa pemrograman

Technicians Ada profesional DB di perusahaan Pertimbangan kebutuhan DBA, bantuan teknis (sistem prog, administrator, dll) Adanya Programmer aplikasi Ada kecukupan pasokan profesional database yang terampil untuk DBMS Pertimbangkan kebutuhan Anda dalam hal DBA, personil bantuan teknis (sistem programmer dan administrator, analis operasi, dll), dan programer aplikasi.

Cost of Ownership Total biaya DBMS Tiap vendor  variasi harga Total biaya kepemilikan : Biaya lisensi Biaya lisensi software pendukung Biaya profesional DB untuk support dan pengelolaan DBMS baru Biaya resource untuk pengoperasioan DBMS baru Berapa total biaya kepemilikan DBMS Para vendor DBMS mematok harga yang bervariasi untuk teknologi mereka. Total biaya kepemilikan harus dihitung sebagai kombinasi dari biaya lisensi dari DBMS, biaya lisensi perangkat lunak pendukung yang diperlukan, biaya profesional database untuk program, dukungan, dan mengelola DBMS, dan biaya sumber daya komputasi yang dibutuhkan untuk mengoperasikan DBMS.

Release schedule Release vendor beragam Org liberal  butuh fitur terkini  rilis cepat lebih baik Org konservatif  perubahan cepat = bencana Perubahan cepat  org konservatif  upgrade > yang dibutuhkan vs menggunakan DBMS usang Beberapa vendor memiliki siklus rilis cepat, dengan rilis baru keluar setiap 12 sampai 18 bulan. Ini bisa baik atau buruk. Organisi Liberal membutuhkan fitur-fitur terkini, siklus rilis cepat yang baik. organisi lebih konservatif, sebuah DBMS yang sering berubah bisa sulit untuk mendukung. Sebuah siklus rilis cepat akan menyebabkan organisasi konservatif meng-upgrade lebih sering daripada mereka butuhkan atau hidup dengan software DBMS usang yang tidak mungkin untuk memiliki tingkat dukungan yang sama sebagai rilis terbaru

Reference customers DBMS vendor  referensi pengguna Vendor  respon baik ? Temukan forum / user lain  jawaban lebih objektif Kualitas rilis baru  maksimal ? DBMS penjual menyediakan referensi pengguna saat ini menemukan pengguna lain pada, yang mungkin memberikan jawaban yang lebih berimbang Vendor merespon dengan baik untuk masalah DBMS Apakah ada banyak perbaikan bug yang harus diterapkan terus-menerus? kualitas rilis baru

Memilih DBMS baru  hitung komplektifitas produk adanya fungsi  didukung vendor dan third party Programmer dan pengembang  menggunakan yang disediakan DBA Rencana dan persiapan lebih baik daripada implementasi semua fitur secara membabibuta Ketika memilih DBMS pastikan untuk memperhitungkan kompleksitas produk. Software DBMS sangat kompleks dan semakin kompleks dengan setiap rilis baru. Fungsi yang digunakan harus didukung dengan add-on perangkat lunak atau program independen semakin banyak ditambahkan sebagai fitur dari DBMS perlu merencanakan dan mendukung semua fitur dari DBMS. Bahkan jika tidak ada kebutuhan saat ini untuk fitur tertentu, setelah DBA menerapkan DBMS programmer dan pengembang akan menemukan alasan untuk menggunakan apa saja vendor masukkan ke dalam DBMS. Lebih baik untuk merencanakan dan bersiaplah daripada membiarkan fitur yang akan digunakan tanpa rencana untuk mendukung mereka.

Memilih DBMS

Arsitektur DBMS DBMS  dirancang untuk pengguna yang unik DBMS  DBMS enterprise, DBMS department, DBMS personal, DBMS mobile  pilih yang sesuai Proyek yang kompleks  beberapa tipe DBMS Kebutuhan dukungan DBMS  pilih di tingkat yang sama Contoh : untuk pengguna ORACLE, gunakan ORACLE personal untuk client tunggal Sebuah DBMS dirancang untuk satu jenis pengolahan mungkin tidak cocok untuk keperluan lainnya. Misalnya, DBMS pribadi tidak dirancang untuk beberapa pengguna, dan suatu perusahaan DBMS umumnya akan terlalu rumit untuk pengguna tunggal. Pastikan untuk memahami perbedaan antara DBMS enterprise, departemen, personal, dan DBMS mobile, dan memilih DBMS yang sesuai untuk kebutuhan pengolahan data tertentu. kadang-kadang memilih beberapa jenis DBMS-yaitu, sebuah DBMS untuk setiap tingkat-dengan penggunaan ditentukan oleh kebutuhan dari setiap proyek pembangunan. Jika organisasi membutuhkan solusi DBMS pada tingkat yang berbeda, mendukung pemilihan sekelompok solusi DBMS dari vendor yang sama bila memungkinkan. Melakukan hal ini akan meminimalkan perbedaan dalam akses, pengembangan, dan administrasi. Misalnya, mendukung Personal Oracle untuk single-user DBMS kebutuhan Anda jika organisasi Anda menggunakan Oracle sebagai DBMS perusahaan pilihan.

Arsitektur DBMS Enterprise DBMS  skalabilitas dan kinerja tinggi. Depertemental DBMS  kelompok kerja kecil-menengah dalam sebuah organisasi;. Personal DBMS  pengguna tunggal, Contoh. Microsoft Access dan Visual dBase. Mobile DBMS  versi khusus dari DBMS departemenal atau Enterprise. DBMS mobile  database lokal  akses dan modifikasi pada laptop atau perangkat genggam. Enterprise DBMS dirancang untuk skalabilitas dan kinerja tinggi. Depertemental DBMS, untuk mendukung kelompok kerja kecil-menengah dalam sebuah organisasi;. Personal DBMS dirancang untuk pengguna tunggal, Contoh. Microsoft Access dan Visual dBase. Mobile DBMS merupakan versi khusus dari DBMS departemenal atau Enterprise. DBMS mobile memungkinkan database lokal akses dan modifikasi pada laptop atau perangkat genggam.

Enterprise DBMS Enterprise DBMS  skalabilitas dan kinerja tinggi Enterprise DBMS  mendukung DB yang besar, user banyak, multi aplikasi Enterprise DBMS  mesin skala besar (mainframe, server) Dukungan multiprosesor untuk multiprocessing, paralel query, dll Sebuah DBMS enterprise dirancang untuk skalabilitas dan kinerja tinggi. Sebuah DBMS enterprise harus mampu mendukung database yang sangat besar, sejumlah besar pengguna bersamaan, dan beberapa jenis aplikasi. DBMS enterprise berjalan pada mesin skala besar, biasanya mainframe atau server high-end menjalankan UNIX, Linux, atau Windows NT/2000. Selanjutnya, DBMS enterprise menawarkan semua "bells and whistles" tersedia dari vendor DBMS. Dukungan multiprosesor, dukungan untuk query paralel, dan fitur canggih lainnya DBMS akan komponen inti dari suatu perusahaan DBMS.

Departmental DBMS departmental DBMS  DBMS workgroup  jalan tengah Mendukung kelompok kecil dan menengah Berjalan di UNIX, LINUX, Windows server Susah dibedakan dengan DBMS enterprise  hardware dan software hampir mirip Dengan harga hardware dan software yang terus menurun  pengguna department DBMS beralih ke DBMS enterprise Sebuah DBMS departemen, kadang-kadang disebut sebagai DBMS workgroup, melayani jalan tengah.  DBMS departemen mendukung kelompok kerja kecil-dan menengah dalam sebuah organisasi; biasanya, itu berjalan pada UNIX, Linux, atau Windows NT Server. Garis pemisah antara database server departemen dan server database perusahaan cukup abu-abu. Hardware dan software upgrade dapat memungkinkan DBMS departemen untuk menangani tugas-tugas yang sebelumnya hanya bisa dilakukan oleh suatu DBMS enterprise. Biaya terus jatuh hardware departemen dan komponen perangkat lunak lebih lanjut memberikan kontribusi untuk menurunkan total biaya operasi dan memungkinkan lingkungan workgroup untuk meningkatkan untuk melayani perusahaan.

Personal DBMS Dirancang untuk pengguna tunggal Contoh ms Access, dBase Vendor membuat versi personal dari DBMS enterprise Biaya murah  adanya penggunaan DBMS personal untuk solusi department dan perusahaan (failed) Personal DBMS  hanya untuk skala kecil, tidak untuk multiuser Sebuah DBMS personal dirancang untuk pengguna tunggal, biasanya pada platform menengah bertenaga PC low-to. Microsoft Access dan Visual dBase adalah contoh dari perangkat lunak database pribadi. Tentu saja, para vendor DBMS utama juga memasarkan versi personal solusi bertenaga tinggi lebih mereka, seperti Oracle dan DB2 Everyplace Pribadi. Kadang-kadang biaya rendah DBMS personal menyebabkan upaya yang salah untuk memilih DBMS pribadi untuk solusi departemen atau perusahaan. Namun, jangan terpikat oleh biaya rendah. Sebuah produk DBMS personal cocok hanya untuk proyek-proyek skala yang sangat kecil dan tidak boleh digunakan untuk aplikasi multiuser.

Mobile DBMS Versi khusus dari DBMS department dan enterprise Digunakan untuk remote, dan tidak terhubung jaringan Dapat digunakan pada laptop dan telepon genggam Ada sinkronisasi dengan DBMS enterprise / department di server utama DBMS mobile adalah versi khusus dari DBMS departemen atau perusahaan. Hal ini dirancang untuk pengguna remote yang biasanya tidak terhubung ke jaringan. DBMS mobile memungkinkan akses database lokal dan modifikasi pada laptop atau perangkat genggam. Selain itu, DBMS mobile memberikan mekanisme untuk sinkronisasi perubahan basis data jauh untuk sebuah perusahaan terpusat atau database server departemen.

DBMS Clustering Clustering  beberapa sistem komputansi  kerjasama dalam satu sistem Meningkatkan skalabilitas dan availabilitas Arsitektur clustering : Shared disk Shared nothing Clustering adalah penggunaan beberapa "independen" sistem komputasi, yang bekerja bersama sebagai sebuah sistem Sebuah DBMS modern clustering menawarkan dukungan untuk meningkatkan ketersediaan dan skalabilitas. Dua dominan arsitektur untuk clustering : Shared Disk dan Shared Nothing

Tiap sistem  sumber daya sendiri (storage sendiri) Share nothing Tiap sistem  sumber daya sendiri (storage sendiri) Komunikasi antar sistem  jaringan interkoneksi antar komputer Permintaan dari klient  diarahkan ke sistem yang available Keuntungan skalabilitas setiap sistem memiliki sumber daya sendiri swasta (memori, disk, dll). Antar prosesor berkomunikasi dengan melewatkan pesan melalui jaringan yang interkoneksi komputer. Permintaan dari klien akan secara otomatis diarahkan ke sistem yang memiliki sumber daya. Hanya salah satu sistem cluster dapat "sendiri" dan mengakses sumber daya tertentu pada suatu waktu. Dalam hal kegagalan terjadi, kepemilikan sumber daya secara dinamis dapat ditransfer ke sistem di cluster. Keuntungan utama dari shared-apa clustering adalah skalabilitas.

Share disc Semua sistem  terhubung perangkat disk yang sama Setiap sistem  memiliki CPU dan memori masing-masing, tapi mengakses semua disk Cocok untuk pengolahan di perusahaan besar atau mainframe Tidak cocok untuk small system semua sistem terhubung berbagi perangkat disk yang sama, Setiap prosesor masih memiliki memori pribadi, tetapi semua prosesor secara langsung dapat mengatasi semua disk. Shared-disk clustering adalah lebih cocok untuk pengolahan besar-perusahaan dalam lingkungan mainframe. Tidak cocok untuk small system

DBMS Installation DBMS dipilih  diinstall DBMS  bagian kompleks dari software  ada syarat dan lingkungan pendukung Yang harus dipahami di awal adalah syarat instalasi Setelah DBMS telah dipilih, perlu menginstalnya. Sebuah DBMS adalah bagian kompleks dari perangkat lunak yang membutuhkan perencanaan di muka untuk instalasi agar sukses. Maka harus memahami persyaratan DBMS dan menyiapkan lingkungan DBMS baru. Hal pertama yang harus dilakukan bila menginstal DBMS untuk pertama kalinya adalah memahami prasyarat.

Kebutuhan hardware Tiap DBMS  kebutuhan dasar CPU Tiap DBMS  menyertakan kebutuhan hardware dan lingungan pendukung Tiap DBMS  ada ciri khas untuk masing-masing kebutuhan Hardware org menyesuaikan DBMS vs DBMS menyesuaikan harware Setiap DBMS memiliki kebutuhan dasar CPU,. Beberapa DBMS menentukan model perangkat keras yang diperlukan atau tidak didukung. Masing-masing DBMS menawarkan berbagai "rasa" dari software mereka untuk kebutuhan tertentu. Pastikan untuk memilih DBMS yang tepat untuk kebutuhan dan untuk menyesuaikan perangkat keras dengan persyaratan dari DBMS. Pastikan untuk memilih DBMS yang tepat untuk kebutuhan org dan untuk mencocokkan hardware org dengan persyaratan dari DBMS.

Kebutuhan penyimpanan Setiap DBMS membutuhkan disk storage untuk berjalan Setiap disk storage akan digunakan untuk indexes kebutuhan dari DBMS dan database Index yang dimaksud antara lain :

Kebutuhan penyimpanan Sistem katalog atau data Dictionary. Setiap sistem database lainnya yang dibutuhkan oleh DBMS Log file yang mencatat semua perubahan Startup atau kontrol file. Works file yang digunakan oleh DBMS untuk mengurutkan data dll Default database yang digunakan oleh DBMS untuk struktur sistem Temporary database structures System dump dan error processing files. Database yang digunakan untuk administrasi, pemantauan, dan tuning

logs

Kebutuhan memory Sebuah DBMS memerlukan memori untuk fungsionalitas dasar dan akan menggunakannya untuk proses yang paling internal seperti memelihara sistem area global dan banyak melakukan tugas.

beberapa pertimbangan lain

Versi atau Release ? Vendor biasanya membuat perbedaan antara versi dan rilis dari produk perangkat lunak. Sebuah versi baru dari perangkat lunak merupakan masalah besar, dengan banyak perubahan dan fitur baru. rilis adalah versi dalam skala kecil kecil, dengan perubahan sedikit dan tidak banyak fitur baru. Ada keuntungan dan resiko penerapan Keuntungan : Adanya fungsi fitur baru dan hanya disampaikan dalam rilis baru. Untuk aplikasi yang dibeli, vendor aplikasi mungkin membutuhkan versi atau rilis tertentu untuk mengaktifkan fungsi tertentu di dalam aplikasi. Memberikan kinerja yang lebih ditingkatkan dan ketersediaan fitur yang dapat mengoptimalkan aplikasi yang sudah ada. DBMS vendor sering akan memberikan dukungan yang lebih baik dan merespon masalah lebih cepat untuk rilis baru software mereka. Resiko : Upgrade DBMS biasanya mengakibatkan beberapa tingkat gangguan untuk operasi bisnis. gangguan lainnya dapat terjadi, seperti harus mengubah struktur database atau menemukan bahwa fitur yang didukung sebelumnya telah dihapus dari rilis baru Biaya upgrade dapat menjadi hambatan besar untuk migrasi DBMS Ketika teknik optimasi SQL ada perubahan, ada kemungkinan bahwa rilis DBMS baru akan menghasilkan jalur akses SQL yang lebih buruk daripada sebelumnya. Produk perangkat lunak pendukung kurang memberi dukungan langsung untuk rilis DBMS baru.

Fitur dan Kompleksitas fitur kompleks  perubahan jalur akan mempengaruhi kinerja client/server dan jaringan  menambah komplektifitas DBMS Integrasi dengan software dan infrastruktur lani  mempersulit migrasi bahasa pemrograman, cara embed query, perubahan API dll  mempengaruhi komplektifitas DBMS Penggunaan store prosedure dan function user-defined. Semakin kompleks fitur SQL, menjadi semakin sulit untuk memastikan bahwa akses perubahan jalur tidak mempengaruhi kinerja. Pemrosesan Client / Server-penggunaan jaringan dan penggunaan Multiple Tier merumitkan DBMS. Integrasi dengan perangkat lunak dan infrastruktur lain dapat mempersulit migrasi Bahasa yang digunakan oleh program mungkin juga berdampak pada migrasi DBMS karena dukungan yang berbeda untuk versi compiler, perubahan API, atau cara-cara baru embedding SQL dalam program aplikasi.

Hal lain yang perlu dipertimbangkan Reputasi dari Vendor DBMS Dukungan Kebijakan dari DBMS Gaya Organisasi Skill Staf DBA Platform Support Perangkat Lunak Pendukung Fallback Planning

Database Standards and Procedures

Konvensi Penamaan Database Perlu penamaan yang standar Dikembangkan bersama administrasi data Publikasi penamaan  ke seluruh lingkungan organisasi Mencakup : tabel, kolom, view, indeks, program, tipe user-defined data, fungsi user-defined, trigger, dan store prosedure Harus dikembangkan bersama dengan semua standar penamaan TI lainnya dalam organisasi Penamaan standar harus dikembangkan dan bekerja sama dengan bagian administrasi data (jika ada) Pastikan untuk membuat dan mempublikasikan penamaan standar untuk semua objek database yang dapat dibuat dalam masing-masing DBMS yang digunakan oleh organisasi Daftar objek database dasar yang distandarkan paling tidak mencakup database, tabel, kolom, view, indeks, program, tipe user-defined data, fungsi user-defined, trigger, dan store prosedure

Standar Data Administration Kebijkan organiasi terkait data Pedoman kepemilikan data Metadata kebijakan manajemen Pedoman konseptual dan logical pemodelan data Tanggung jawab menciptakan dan memelihara data Pedoman penggunaan tools Kebijakan terkait sharing data Pedoman perubahan data Aturan yang jelas tentang kebijakan organisasi berkaitan dengan data. Pedoman untuk menetapkan kepemilikan data dan penata layanan Aturan untuk pembuatan , kepemilikan data, dan pelayanan data Metadata kebijakan manajemen Pedoman konseptual dan logika pemodelan data Tanggung jawab untuk menciptakan dan memelihara model data Pedoman untuk penggunaan alat dan petunjuk tentang bagaimana model data yang harus dibuat, disimpan, dan dipelihara Kebijakan Organisasi untuk sharing data Petunjuk tentang cara untuk mendokumentasikan ketika database fisik menyimpang dari model data logic

Standar Database Administration instalasi dan prosedur pengujian Upgrade kebijakan dan prosedur Bug memperbaiki bug dan praktek-praktek pemeliharaan Membuat Sebuah daftar untuk memberitahukan perubahan yang akan datang Pertimbangan disain Antarmuka penyimpanan, penggunaan, dan pemantauan prosedur

System Administration Standards Jika ada fungsi SA dalam organisasi Standard SA sama dibutuhkan seperti standar DA dan DBA, mencakup DBMS installation and testing procedures Upgrade policies and procedures Bug fix and maintenance practices A checklist of departments to notify for impending changes Interface considerations DBMS storage, usage, and monitoring procedures

Standar Pengembangan Aplikasi Penjelasan tentang bagaimana mengakses database yang berbeda Standar Coding dengan SQL Tips dan triks kinerja SQL Penyusunan prosedur dan bimbingan tentang bagaimana menanamkan SQL dalam program aplikasi Interpretasi dari SQL STATE dan kode kesalahan Referensi materi pemrograman lainnya

Standart Keamanan Database Menentukan siapa yang berwenang Daftar pemberian otorisasi database. Informasi pada setiap interface yang digunakan. Kebijakan penggunaan klausa WITH GRANT OPTION dan CASCADING. Prosedur pemberitahuan kepada User. Prosedur menghapus user

Unit testing— for developing and testing individual programs Application Migration and Turnover Procedures Unit testing— for developing and testing individual programs Integration testing— for testing how individual programs interoperate User acceptance testing— for end user testing prior to production status Quality assurance— for shaking out program bugs Education— for training end users how to work the application system Unit testing-untuk mengembangkan dan menguji program individu Integrasi pengujian untuk menguji bagaimana program individu beroperasi Penerimaan pengguna pengujian-pengujian untuk akhir pengguna sebelum status produksi Jaminan kualitas-untuk gemetar keluar bug program Pendidikan-bagi pengguna akhir pelatihan bagaimana bekerja sistem aplikasi

Yang harus dilakukan Organisasi Harus berkomitmen untuk terus-menerus memberikan pendidikan teknis untuk DBA, programer, dan administrator sistem. Menyediakan katalog program yang tersedia mencakup semua aspek penggunaan DBMS. Minimal, kursus berikut harus disediakan: dasar-dasar DBMS Pemodelan Data dan Desain Database Database Administrasi Pengantar SQL Advanced SQL Pemrograman Database

Kesimpulan Perencanaan komprehensif diperlukan untuk menciptakan lingkungan database yang efektif. Langkah langkah yang harus diambil untuk memilih teknologi DBMS yang benar, menerapkan strategi yang tepat, upgrade dan mengembangkan standar database yang berguna menjamin ketersediaan pendidikan berkelanjutan bagi pengguna database.

Terima kasih