Bagaimana cara menyelam ke dalam database yang jelek?

Saya yakin banyak dari Anda yang berurusan dengan database yang jelek. Anda tahu, basis data yang tidak dinormalisasi sama sekali, basis data di mana Anda harus melakukan kueri besar untuk mendapatkan data yang paling sepele, basis data yang sedang dalam produksi dan Anda tidak dapat mengubah sedikit pun ... Anda tahu , "yang itu".

Pertanyaan saya adalah, bagaimana Anda menghadapinya?

• Apakah Anda mencoba membuat database baru?
• Anda menyerah dan membiarkannya sendiri?
• Apa saran yang bisa Anda berikan?

• Hal pertama yang saya lakukan adalah membuat Entity-Relationship Diagram (ERD). Kadang-kadang Anda dapat dengan mudah menggambarkan metadata dengan alat baris perintah tetapi untuk menghemat waktu ada beberapa alat yang dapat menghasilkan diagram secara otomatis.

• Kedua, periksa setiap tabel dan kolom untuk memastikan saya mempelajari arti dari apa yang disimpannya.

• Ketiga, periksa setiap hubungan dan pastikan saya mengerti bagaimana tabel-tabel itu saling berhubungan.

• Keempat, baca setiap tampilan atau pemicu untuk memahami penegakan integritas data kustom atau operasi kaskade.

• Kelima, baca prosedur yang tersimpan. Baca juga hak akses SQL jika ada.

• Keenam, bacalah bagian-bagian kode aplikasi yang menggunakan database. Di situlah beberapa aturan bisnis tambahan dan aturan integritas data diberlakukan.

pembaruan: Saya baru saja membaca artikel yang menarik " 9 Hal yang Harus Dilakukan Ketika Anda Mewarisi Basis Data " dengan daftar periksa yang bagus.

Ringkasan:

1. Cadangan
2. Penelitian (langkah-langkah dokumentasi skema yang saya sebutkan di atas)
3. Bicaralah dengan mantan pengembang
4. Database bug
5. Kontrol kode sumber
6. Bicaralah dengan pengguna dan / atau pemilik bisnis
7. Membangun kredibilitas dengan pengguna dengan memperbaiki beberapa hal atau membuat beberapa peningkatan
8. Buat lingkungan pengembangan
9. Jatuhkan benda yang sudah usang

Ini tidak selalu mungkin, tetapi satu hal yang berhasil bagi saya dalam situasi tertentu adalah mengganti beberapa tabel dengan tampilan. Anda kemudian dapat merapikan tabel di bawahnya dan dalam beberapa kasus akhirnya membuang pandangan. Seperti yang saya katakan, hanya berfungsi dalam beberapa kasus.

Kamus data adalah teman Anda. Juga, coba rekayasa balik database dengan alat rekayasa balik pada Visio dan buat set diagram Anda sendiri. Karena reverse engineering bersifat interaktif - Anda membuat diagram - itu jauh lebih menarik daripada membaca kamus data. Keaktifan proses adalah keuntungannya dan saya merasa cukup santai untuk melakukan ini.

Sebagian besar pekerjaan yang saya lakukan adalah dalam pergudangan data, di mana mengaduk-aduk skema basis data sistem sumber merupakan kegiatan inti. Saya telah melakukan hal semacam ini pada beberapa kesempatan dan menemukan itu bekerja dengan sangat baik.

Visio pro tidak semahal itu dan mesin pemodelan Visio memungkinkan Anda berbagi model di antara banyak diagram. Sebagai bonus, Anda dapat menambahkan kunci asing yang hilang dalam diagram dan Anda mendapatkan satu set dokumentasi yang berguna untuk sistem pada akhirnya.

Selain ide-ide Bill Karwin, saya sarankan berbicara dengan pengguna - kadang-kadang pengguna tahu sedikit tentang apa yang digunakan untuk database mereka, terutama jika mereka melakukan pelaporan dari itu.

Saya berurusan dengan yang sangat jelek untuk perangkat lunak vendor, yang selain membuat saran, saya tidak bisa berbuat banyak untuk mengubahnya. Saya selalu berusaha untuk mengubah keadaan, tetapi karena itu di luar kendali saya, saya terjebak dengan sampah.

Salah satu hal yang saya mulai gunakan dengan cepat, karena basis data sama sekali tidak memiliki hubungan, adalah permintaan Nama umum untuk skema:

--Find Column named like 'blah' in a specific table
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V') AND O.Name like '%TableName%'
ORDER by O.Name

atau

--Find all Columns in DB with name like 'blah'    
SELECT O.NAME, O.ID, C.NAME, O.XTYPE
FROM SYSOBJECTS O LEFT JOIN SYSCOLUMNS C ON O.ID=C.ID
WHERE C.NAME LIKE '%SearchFor%' AND O.XTYPE IN ('U','V')
ORDER by O.Name

Karena beberapa tabel memiliki terlalu banyak kolom dengan nama buruk, dan terlalu banyak kolom untuk ditelusuri untuk menemukan apa yang bisa saya gunakan untuk membentuk hubungan antar tabel.

Saya tahu ini tidak banyak membantu dalam mendesain ulang bagian dari pertanyaan, tetapi sangat membantu dalam memahami dan menguraikan skema yang buruk.

SchemaCrawler adalah alat penemuan basis data saya yang memiliki beberapa fitur yang membuatnya mudah untuk menjelajahi basis data yang jelek. SchemaCrawler memiliki fungsionalitas seperti "grep", yang memungkinkan Anda untuk mencari tabel dan kolom menggunakan ekspresi reguler. Misalnya, Anda bisa mencari tabel dan kolom dengan "ACCOUNT" sebagai bagian dari nama mereka, dan mereka mungkin terkait dalam beberapa cara.

SchemaCrawler juga menyimpulkan hubungan kunci asing, bahkan di mana tidak ada kunci asing. Itu melakukan ini dengan menemukan "asosiasi lemah" menggunakan konvensi penamaan umum, seperti tabel adalah nama biasanya jamak, tetapi nama kolom tidak, dan nama kolom mungkin memiliki awalan _ID. Anda dapat menemukan tabel terkait menggunakan hubungan yang disimpulkan ini.

Bergantung pada seberapa jeleknya itu, dan seberapa besar kendali yang Anda miliki atas desain dan apa yang berinteraksi dengannya. Saya harus berinteraksi dengan sejumlah database jelek selama bertahun-tahun di pekerjaan saya saat ini, dan inilah cara saya mengatasinya:

Data karyawan

Ada database yang menyimpan data karyawan. Ini basis data vendor, jadi saya tidak punya kendali atasnya. (Un?) Untungnya, saya tidak punya akses langsung ke sana. Saya mendapatkan dump DTS setiap pagi.

Yang terbaik yang bisa saya kelola adalah menulis skrip yang menggosok input dari dump pagi (ya pilihan kata disengaja) dan memigrasikannya ke dalam format yang lebih bermanfaat, dan bekerja dari data yang digosok.

Bahkan jika saya bisa mengubahnya, saya mungkin tidak akan - hanya karena ada sejumlah besar program lain yang mengandalkannya diatur seperti itu, dan saya tidak bisa memaksakan perubahan di dalamnya.

Data Pelatihan Online

Ini adalah kekacauan desain saya sendiri. Saya membangunnya baru keluar dari perguruan tinggi tanpa mentor untuk membantu saya ... Sejak itu saya telah memperbaikinya sedikit demi sedikit. Karena saya mengendalikan satu-satunya program yang mengakses data, ketika saya memutakhirkan bagian situs saya akan "memutakhirkan" konfigurasi database. Saya akan menulis skrip transformasi dan mengujinya dengan penuh semangat pada salinannya sehingga saya dapat memastikan bahwa semua perubahan yang perlu dilakukan dibuat.

Ini merupakan proses yang panjang, tetapi prosesnya berjalan dengan baik.

Data Pelatihan Kelas

Proyek percontohan saya telah mengintegrasikan data dari 3 basis data yang berbeda, semua dirancang sedikit berbeda oleh pendahulu saya ... yang adalah seorang pendidik perawat yang mengambil satu atau dua kelas pemrograman.

Itu proses lambat lainnya. Karena saya memiliki kendali penuh atas program yang mengakses data, saya telah mengubahnya sedikit demi sedikit seperti data pelatihan online.

Dalam retrospeksi, ini akan menjadi kandidat utama untuk memulai bersih ... pemandangan belakang selalu 20/20.

Pada akhirnya...

Saya tidak tahu seberapa membantu hal ini, dan saya bisa menguraikan lebih lanjut (sampai titik tertentu, hukum perusahaan yada yada dan semuanya). Jawaban terakhir adalah "Tergantung".

Jadi setelah membaca semua jawaban Anda, saya berikan kepada Anda:

Pertama saya mencari "Master Table", kemudian, dengan pena dan kertas, saya mulai memetakan hubungan dengan tabel lainnya, setelah itu, jika ada beberapa kode aplikasi untuk dilihat, saya mulai membuat beberapa sketsa mentah tentang bagaimana data mengalir.

Setelah saya mendapatkan gambar yang bagus tentang bagaimana db bekerja, saya baru mulai memeriksa tempat-tempat untuk mengubah sesuatu. Itu dia.

Saya tidak tahu mengapa, tetapi saya lebih suka kertas daripada perangkat lunak pemodelan basis data.

Karena menggunakannya oleh aplikasi eksternal, Anda tidak dapat mengubah "antarmuka" basis data. Saya tidak tahu jenis database apa yang Anda gunakan (oracle, mysql, mssql), tetapi saya melihat ini sebagai salah satu cara:

• membangun antarmuka basis data dengan menggunakan jenis objek sebagai tampilan dan prosedur tersimpan.
• langkah demi langkah refactoring (normalisasi, penggantian nama bidang ...)
• mengubah aplikasi klien (jika diperlukan)

Tampilan, prosedur tersimpan akan menyembunyikan modifikasi basis data internal (perubahan).

Selain menemukan struktur basis data, saya menemukan bahwa juga penting untuk melihat kualitas data . Setelah Anda memahami arti dari setiap kolom, Anda dapat mencari tempat di mana ada banyak nilai yang hilang. Ketika Anda menjadi lebih akrab dengan data, Anda juga dapat memeriksa di mana ada ketidakkonsistenan antara nilai-nilai di kolom yang berbeda.

Itu tergantung pada bagaimana Anda harus berinteraksi. Untuk skenario penggunaan di mana batching dapat diterima, saya cukup sering merasa ini paling hemat biaya (dalam hal waktu pengembangan dan biaya untuk klien) untuk batch data ke struktur yang lebih ramah dan bekerja melawan itu.

Jika Anda dapat mengelompokkan masalah menjadi masalah yang bisa Anda gunakan, Anda dapat menyerang mereka satu per satu. Terkadang, hanya dengan mengetahui bahwa ada satu meja yang tidak semuanya dapat membuat Anda menjadi tempat berpijak. Dengan cara ini, Anda memperluas "tempat bersih" untuk mencakup lebih banyak basis data dalam potongan.

Jika Anda memiliki Visio (bagian dari Microsoft Office), Anda dapat mencoba fungsi reverse engineer . Ini tidak cantik, tetapi setidaknya akan memberi Anda awal (di sebagian kecil dari biaya alat "nyata" seperti Rational Rose).

Schema Spy adalah alat yang sangat bagus untuk menghasilkan ERD.

Bill memberikan jawaban yang sangat bagus. Saya akan menambahkan bahwa saya akan masuk ke antarmuka pengguna sebagai pengguna uji dan mencoba memahami apa yang dilakukan pengguna dengan data. Ini akan membantu Anda memahami alasan di balik beberapa procs atau desain yang tersimpan. Memahami apa arti data dan digunakan untuk sangat penting untuk memahami suatu database.

Jika basis data ada pada fungsi bisnis atau subjek yang secara umum tidak Anda kenal (katakan itu perencanaan penerbangan dan sebelumnya Anda hanya mengerjakan aplikasi keuangan), maka minta kepada pengguna beberapa bahan bacaan tentang materi pelajaran atau pergi ke perpustakaan diri Anda sendiri atau cari di Internet tentang masalah tersebut. Tanyakan kepada pengguna apakah ada masalah hukum atau peraturan yang perlu Anda ketahui. Lagi-lagi beberapa latar belakang materi ini dapat menjelaskan apa yang tampaknya menjadi pilihan desain yang aneh.

Jika itu adalah database vendor (dan saya telah melihat beberapa yang sangat buruk) yang dapat Anda lakukan adalah mengeluh kepada vendor tentang hal itu.

Untuk aplikasi yang dibangun di rumah biasanya hanya membutuhkan beberapa pendidikan untuk pengembang dan Anda dapat mulai mengubah skema sehingga kinerja meningkat. Butuh waktu, dan biasanya prosesnya lambat.

Dalam pengalaman saya membangun basis data baru sebenarnya bukan pilihan, karena memindahkan ratusan GB atau TB data tidak semuanya layak.

Membiarkannya sendirian juga biasanya bukan pilihan. Sebagai jumlah data dalam database tumbuh kinerja akan semakin buruk (diberikan pada saat saya melihat masalah mereka biasanya sangat buruk). Akhirnya pengguna tidak akan dapat menggunakan aplikasi karena kinerjanya sangat buruk.

Ah ... database Jelek, Semakin besar perusahaan, semakin banyak basis data warisan yang akan kita temukan.

• Menyetel untuk orang kinerja tidak mengeluh tentang database seperti itu sampai mereka menemukan masalah kinerja. Jadi di organisasi kami, kami mengidentifikasi permintaan individual dan menyempurnakannya sebagai tambalan.
• Membatasi data sekarang kita tahu di mana sampah bau jadi coba hindari aliran data melalui database seperti itu. Buat basis data pementasan dan arahkan ulang data Anda ke tabel tersebut untuk memulai dan gunakan yang lama sebagai data dump.
• Hindari Penimbunan data Arsip / potong data lama yang tidak diperlukan lagi. Harus ada tim yang memutuskan berapa lama data diperlukan dalam database. Setelah itu Anda dapat memindahkannya ke file datar atau bahkan ke drive tape.
• Hapus fase begitu Anda dapat mencapai redirection dan pemotongan data. Meyakinkan tim lain untuk mulai menggunakan database baru.

Itu tidak selalu berhasil, tetapi jika kita tidak berusaha, itu hanya akan menjadi lebih buruk. Saya mencoba mendesain ulang database bersama dengan aplikasi, mungkin menambah lebih banyak pekerjaan untuk saya dengan migrasi data tetapi kinerja adalah trik sulap yang selalu saya tarik keluar dari topi saya.

Semoga beruntung dengan teman cewek jelekmu;)

Lihat apakah opsi sesi Transfer Pengetahuan tersedia untuk Anda, dan jika demikian, manfaatkan sepenuhnya.

Juga, banyak DBMS dilengkapi dengan alat-alat yang memungkinkan Anda untuk menggambar / mencetak skema basis data dengan beberapa informasi bermanfaat (yaitu kunci asing).

Selain itu, (dicuri dari NXC), Anda dapat merekayasa balik basis data melalui alat seperti Visio.

Saya suka menjalankan profiler permintaan dan menonton apa yang terjadi pada sistem produksi. Memberi saya ide tentang tabel apa yang 'panas' dan jenis pertanyaan yang ada di sana.

Letakkan salinan cadangan di server kotak pasir dan kemudian mulai menulis dan menjalankan kueri pengujian. Saya selalu menemukan sistem yang kompleks lebih mudah untuk dipahami jika saya bisa mendapatkannya dan tidak khawatir tentang kerusakan itu.

Saya juga ingin The Daily WTF terbuka di jendela browser. Mengambil alih desain orang lain biasanya melibatkan banyak momen "Aku tidak percaya mereka melakukan {WTF}", dan membantu memiliki tempat untuk pergi ke tempat orang memahami rasa sakitmu.