Apakah Berkembangnya Informasi Kontak Berarti Mengubah Basis Data Anda?

Ada beberapa cara untuk menghubungi seseorang akhir-akhir ini, bukan?

Kami memiliki berbagai telepon:ponsel dan telepon rumah, pribadi dan kantor. Kami memiliki alamat yang berbeda – tempat tinggal, surat, penagihan, bisnis, dll. – dan kemungkinan beberapa alamat email juga. Jangan lupa Skype dan berbagai aplikasi perpesanan. Sekarang tambahkan LinkedIn dan Facebook – yang keduanya memiliki elemen perpesanan sendiri.

Belum lama ini, banyak dari ini tidak ada. Jadi, Anda dapat menjamin bahwa dalam beberapa tahun, kami akan memiliki cara baru untuk menghubungi orang dan organisasi.

Bisakah kita memodelkan semua info kontak ini sedemikian rupa sehingga kita tidak perlu mengubah desain database kita ketika 'hal terbaru' datang? Baca terus untuk mengetahuinya…

Model Titik Kontak Pesta

Dalam satu kata, ya. Basis data dapat dirancang untuk mengakomodasi informasi yang bahkan belum kita miliki.

Saya akan langsung masuk dan menunjukkan solusinya, lalu saya akan menjelaskan bagaimana potongan-potongan itu bekerja bersama. Saya akan menghubungi berbagai cara untuk menghubungi pihak titik kontak , meskipun saya telah melihat metode kontak dan bahkan menghubungi lokasi digunakan.

Secara fisik, semua titik kontak ini akan disimpan dalam satu kolom tabel, contact_point.contact_value . Pikirkan nomor telepon, alamat email, atau alamat web (URL) dan Anda akan mengerti mengapa kami dapat menyimpan semuanya di sini; mereka hanya string (varchars) pada level ini. Perbedaannya ada di metadata. Satu-satunya pengecualian untuk ini adalah alamat pos, yang akan dijelaskan lebih rinci nanti.

Tabel kuning di sebelah kiri berisi metadata, dan tabel biru di sebelah kanan berisi data bisnis.

Kategori Utama

Meskipun kita memiliki banyak cara untuk menghubungi seseorang, cara-cara ini sebenarnya termasuk dalam sejumlah kecil kategori, atau jenis. Anda akan melihat apa yang saya maksud ketika Anda melihat daftar di bawah ini:

Dalam arti tertentu, ini berbeda secara fisik. Tentu saja, Anda dapat menggunakan ponsel untuk menelepon telepon rumah atau ponsel lain. Ketika berbicara tentang panggilan suara antara telepon rumah dan ponsel, perbedaannya tidak terlalu penting. Namun, kami lebih cenderung mengirim teks (SMS) ke ponsel daripada telepon rumah.

Tetapi Anda tidak mungkin dengan sengaja melakukan panggilan suara ke nomor faks. Lagi pula, apa yang akan Anda katakan ketika Anda mendengarnya, selain dari 'Ups, salah nomor'? Anda secara alami jauh lebih mungkin untuk menelepon dengan mesin faks lain, apakah itu fisik atau ditiru. Anda juga tidak akan mengirim surat ke telepon rumah, atau mencoba melakukan panggilan suara ke alamat pos.

Penting bagi kita untuk membedakan jenis-jenis ini, karena kita berinteraksi secara berbeda dengan mereka. Ini terutama benar jika aplikasi Anda memiliki integrasi apa pun dengan layanan komunikasi. Ia perlu mengetahui tipe mana yang akan berinteraksi.

Bagaimana Para Pihak Menggunakan Poin Kontak

Ini mungkin sedikit lebih intuitif, sedikit lebih sejalan dengan cara kita berpikir tentang jenis kontak. Berikut adalah daftar yang lebih panjang (tetapi tidak lengkap!) yang akan membantu Anda memahami jenis-jenis ini:

Alamat Pos – Kasus Khusus

Semua jenis titik kontak ini disimpan dalam satu bidang, dengan pengecualian alamat pos. Ini biasanya membutuhkan sejumlah baris (atau bidang).

Ada artikel blog di sini yang mengusulkan cara sederhana, agnostik bahasa untuk menyimpan alamat pos. Jika persyaratan Anda agak mendasar – mis. untuk mencetak label alamat cukup banyak saat mereka dimasukkan ke dalam sistem – pendekatan ini mungkin sudah cukup. Jika kebutuhan Anda lebih canggih, Anda mungkin harus mengembangkan solusi yang berbeda.

Untuk mendapatkan gambaran tentang betapa rumitnya pengalamatan, lihatlah Skema untuk Tipe Alamat BS7666 Standar Inggris ini. Standar ini terdiri dari sejumlah bagian yang mencakup Lembaran Negara, Lembaran Negara dan Properti, dan titik penyerahan. Itu tidak membedakan antara properti komersial atau residensial; antara tanah yang diduduki, dikembangkan atau kosong; antara perkotaan atau pedesaan; atau antara entitas yang dapat dialamatkan melalui pos dan entitas yang tidak dapat dialamatkan melalui pos s seperti tiang komunikasi (menara). Untuk mencapai hal ini, ia memperkenalkan istilah yang mungkin tidak kita kenal, seperti Primary Addressable Object (PAO), yang merupakan nama yang diberikan untuk objek yang dapat dialamatkan yang dapat dialamatkan tanpa referensi ke objek yang dapat dialamatkan lainnya. Contoh PAO yang familier termasuk nama gedung atau nomor jalan. Sebuah Obyek Beralamat Sekunder (SAO) diberikan ke setiap objek beralamat yang dialamatkan dengan mengacu pada PAO. Ini mungkin lantai pertama dari sebuah bangunan bernama.

Untuk memberi kita visualisasi tentang ini, saya dengan cepat merekayasa baliknya menjadi alat pemodelan UML. Inilah yang kami dapatkan:

Maksud saya adalah itu bisa menjadi sangat rumit dan berantakan; pengalamatan di beberapa domain memang bisa sangat kompleks.

Jika Anda meratakan ini menjadi satu tabel relasional, Anda akan mendapatkan sesuatu seperti berikut:

Meskipun ini menangkap komponen alamat BS7666, ini tidak memberi tahu Anda cara kerja model. Semua logika relasional skema XML disembunyikan dalam logika aplikasi.

Kedua diagram ini mewakili dua ekstrem pemodelan data . Tetapi apakah ada jalan tengah untuk memodelkan alamat?

Memang mungkin untuk memiliki model alamat yang relatif sederhana yang fleksibel dan dapat dikonfigurasi.

Komponen Alamat

Komponen alamat biasanya berupa baris pada label alamat, atau lebih tepatnya jenis baris pada label alamat. Jenis komponen yang biasanya kami gunakan untuk alamat UK tercantum dalam tabel berikut:

Anda dapat memiliki tiga atau empat baris alamat, ditambah kota pos dan kode pos. Namun, kesulitan yang akan Anda temui adalah mengidentifikasi apa isi sebenarnya dari baris ini ketika itu penting – mis. saat memetakan data antar sistem. Saat Anda melakukan pembuatan profil data, Anda akan menemukan bahwa Baris Alamat 3 terkadang berisi lokalitas dependen, tetapi di lain waktu berisi county atau lokalitas. Sekarang Anda masuk ke pemrosesan bahasa alami (NLP); Anda harus mengenali perbedaannya antara kabupaten dan kota. Dan permutasi berlipat ganda saat Anda menambahkan lebih banyak negara.

Jadi kita harus mendefinisikan semua komponen alamat untuk semua negara tempat kita beroperasi.

Format Alamat

Format alamat terdiri dari dua bagian:header dan detailnya. Header pada dasarnya adalah nama atau judul yang format alamat diketahui oleh. Contohnya dapat mencakup:

Sebagai contoh, Full Post Office Address Format (PAF) Inggris Raya, kami kemudian mendefinisikan komponen format alamat berikut:

Aplikasi kami membaca metadata ini dan menampilkan komponen alamat dalam urutan yang benar. Saat pengambilan alamat diperlukan, metadata memberi tahu kita apakah komponen alamat wajib atau tidak.

Lebih sering, aplikasi kita meminta kode pos dari pengguna akhir dan mencari nilai yang sesuai dan mengisi komponen alamat secara otomatis. Beberapa aplikasi memungkinkan pengguna untuk mengedit alamat; yang [mengganggu] lainnya tidak!

Ini tidak ditampilkan di PDM, tetapi jika organisasi Anda beroperasi secara internasional, Anda dapat menentukan hubungan banyak ke banyak antara address_format_type dan country sehingga format alamat yang benar (berdasarkan negara pengguna) disajikan kepada pengguna akhir (party ).

Kapan dan hanya jika contact_point adalah alamat pos contact_point_type , itu harus memiliki hubungan dengan address_format_type. Sebaliknya, jenis alamat non-pos tidak pernah memiliki hubungan dengan address_format_type . Selanjutnya, formatnya harus tetap untuk kehidupan contact_point , jika tidak, Anda akan memperkenalkan kemungkinan masalah integritas data. (Agar tidak demikian , target address_format_components harus merupakan subset dari address_format_components sumber ).

Kolom contact_value tidak memiliki arti untuk alamat pos karena nilainya disimpan dalamddress_line.line_content . Sebaliknya, contact_value wajib untuk semua contact_point_types lainnya . Pada dasarnya, contact_point.contact_value dan address_line.line_content saling eksklusif.

Hubungan Banyak-Ke-Banyak Antara Pihak dan Titik Kontak

Anda dapat memikirkan contact_point (ditambah address_line ) yang berisi nilai dan party_contact sebagai mendefinisikan penggunaan. Ini memungkinkan satu contact_point untuk memiliki banyak kegunaan . Alamat [pos] rumah kami juga bisa menjadi alamat penagihan dan alamat pengiriman kami, tergantung pada konteksnya.

Sejauh ini, narasi telah mengasumsikan bahwa suatu pihak memiliki contact_point tertentu . Tetapi model data tidak memaksakan aturan kepemilikan ini! Itu tidak membuat batasan seperti itu sama sekali. Ada kemungkinan lain yang ada dengan desain ini:banyak pihak untuk titik kontak yang sama.

Anda perlu mempertimbangkan implikasinya dengan hati-hati sebelum menelusuri rute ini.

Berikut ini contohnya. Di Inggris, Awarding Organizations (AOs) umumnya mempekerjakan guru sebagai penguji. Seorang guru memiliki dua hubungan:satu dengan sekolah tempat dia bekerja, dan satu lagi dengan AO sebagai penguji. Sekolah akan memiliki bank contact_points dengan berbagai nomor telepon dan mungkin satu atau lebih alamat pos. Ini akan menjadi hal-hal seperti alamat utama sekolah (alamat pos), email utama (alamat email), faks utama (nomor faks), dan telepon utama (nomor telepon).

Sangat mungkin bahwa pemeriksa kami dapat menggunakan contact_points yang sama sebagai sekolahnya, tetapi dia akan menggunakan party_contact untuk mendefinisikan mereka sebagai yang berhubungan dengan pekerjaan. Jika nomor telepon utama sekolah berubah, nomor tugas guru akan otomatis diperbarui, yang cukup rapi.

Jika Anda mengikuti rute ini, Anda perlu mendefinisikan di tingkat aplikasi pihak atau pihak mana yang diizinkan untuk memperbarui contact_points .

Kata Singkat Tentang Performa

Tabel metadata kuning akan terus digunakan oleh kueri. Akibatnya, mereka cenderung tetap dalam ingatan. Pada sebagian besar RDBMS, Anda dapat menyematkan tabel ke dalam memori untuk memastikan hal ini. Di Oracle, saya akan membuat ini sebagai tabel yang diatur indeks, yang kecil dan berkinerja baik. Lakukan apa pun yang setara untuk RDBMS Anda.

Anda juga ingin memastikan bahwa party_contact baris ditempatkan bersama di blok (atau halaman) yang sama menggunakan indeks berkerumun di party_id . Lakukan hal yang sama dengan address_line.contact_point_id . Ini mengurangi jumlah IO.

Opsi lain ada jika Anda menginginkan party untuk secara eksklusif memiliki contact_point . Anda kemudian dapat menggabungkan contact_point ke party_contact untuk membuat party_contact_point (masih mengelompok di party_id ). Ini menyederhanakan model dan dapat membantu kinerja.

Mengganti Kontak Tidak Berarti Mengubah Basis Data

Kita hidup di masa ketika dapat dikatakan bahwa perubahan adalah satu-satunya yang konstan.

Itu tidak berarti bahwa setiap kali sesuatu berubah, itu harus memengaruhi basis data Anda. Dengan sedikit pemikiran, kami dapat membuktikan desain kami di masa depan – mungkin lebih dari yang telah kami lakukan hingga saat ini. Melakukannya membantu kami merespons dengan cepat perubahan yang tak terhindarkan.

Jika Anda memulai proyek lapangan hijau, saya akan merekomendasikan menggunakan Model Pesta (di mana Titik Kontak adalah bagiannya) untuk organisasi dan orang-orang. Mengapa tidak membuka model dan menyesuaikannya dengan kebutuhan Anda? Silakan ambil salinannya dan buat sendiri.

Tetapi jika database atau database Anda sudah ditentukan, skema yang saya sajikan di sini masih dapat digunakan, dalam bentuk XML, untuk menentukan payload Anda saat mengintegrasikan data antar sistem.