Apakah desain basis data yang baik kurang penting untuk basis data spasial?

Saya memiliki perasaan yang kuat bahwa desain dan normalisasi basis data sering muncul di tangan kedua ketika berhadapan dengan data spasial.

Dengan perangkat lunak yang berharga mahal dan database dengan lebih dari 100 tabel bidang, saya harus bertanya:

Apakah ada alasan bagus untuk mengambil pertimbangan selain normalisasi ketika merancang basis data spasial?

Saya kira orang akan meminta contoh, tetapi saya tidak bisa memberi di sini, jadi pertanyaan saya mungkin lebih ditujukan untuk mereka yang berarti bahwa 100 bidang tidak masalah dan lebih mudah dirawat daripada desain normal yang tepat.

Apa argumennya?

Saya merasa bahwa basis data spasial harus diperlakukan tidak berbeda dengan database tradisional. Mereka pada dasarnya melakukan hal yang sama, menyimpan sejumlah besar data untuk pengambilan cepat. Sebagai contoh, dalam PostgreSQL / PostGIS, geometri hanyalah tipe data lain. Sama seperti teks, atau integer. Sama di SQL Server 2008. Sama di Oracle. Jika bagian "spasial" hanyalah tipe bidang lain dalam database, lalu apakah benar-benar berbeda dari database asli? Apakah ini berarti kita harus membuang semua aturan desain database tradisional?

Tentunya normalisasi dapat dilakukan terlalu jauh, seperti halnya dengan database tradisional, jadi merupakan trade off untuk menemukan desain terbaik yang sesuai dengan kebutuhan Anda.

Jika Anda berencana membuat struktur yang sangat tidak normal dengan tabel 100 kolom, maka Anda harus bertanya pada diri sendiri apa yang mungkin berubah di masa depan? Dengan peningkatan besar dalam baris, apakah ini juga akan mempengaruhi kinerja permintaan? Apakah ini akan mempengaruhi rawatan di masa depan?

Apa yang salah dengan membuat struktur yang dinormalisasi dan menggunakan tampilan untuk mengekspos semua data ke klien basis data, baik itu GIS, atau klien lain?

Semua pertanyaan ini berlaku untuk basis data tradisional dan basis data spasial. Jika Anda pergi melalui http://en.wikipedia.org/wiki/Database_normalization Anda akan menemukan bahwa itu berlaku untuk basis data spasial juga.

Jika perangkat lunak yang Anda gunakan di atas database memaksa Anda untuk menggunakan struktur yang sangat tidak dinormalisasi, maka ini adalah argumen yang berbeda. Anda dibatasi oleh perangkat lunak dan bukan database, sehingga Anda tidak punya pilihan dalam desain database terbaik.

Jadi saya pikir, jawaban singkatnya adalah (menurut saya) desain basis data sama pentingnya dengan basis data spasial dengan basis data tradisional.

Saya sering melihat ini. Saya merasa bahwa itu berasal dari fakta bahwa orang-orang GIS tradisional berasal dari latar belakang survei, dan tidak memiliki latar belakang / pemahaman tentang database. Saya melihat perubahan ini, karena semakin banyak organisasi memindahkan infrastruktur GIS ke dalam lipatan TI.

Warisan Perangkat Lunak GIS

Biaya tinggi ArcSDE sebelumnya dan kurangnya datatype spasial dalam SQL Server (sampai 2008), dan Oracle hingga versi 10, berarti ada sedikit pilihan selain menyimpan data dalam shapefile untuk banyak organisasi (dan oleh para tender untuk menekan biaya penawaran) .

Pengenalan tipe spasial asli dalam SQL Server berarti hampir secara instan bahwa ArcSDE berubah dari investasi besar, untuk dimasukkan secara gratis di ArcGIS, dan "membawa masuk ke lipatan" data spasial dalam organisasi.

Organisasi yang menggunakan ArcGIS dan SQL Server sebelumnya memiliki tiga pilihan:

1. Bayar biaya 20k + untuk membeli ArcSDE dan menyimpan data spasial dalam database SQL Server yang "tepat".
2. Menyimpan data spasial dalam shapefile / GDB pribadi, dan menautkan ke seluruh data organisasi dalam basis data (atau mengekspor atribut ini ke DBF)
3. Beralih vendor GIS dan menyimpan data spasial dalam satu basis data tetapi dalam format yang hanya dapat diakses oleh perangkat lunak GIS yang baru

Setelah SQL Server memiliki tipe spasial asli, kebanyakan vendor menggunakan ini alih-alih format kepemilikannya, yang berarti data spasial tiba-tiba dapat diakses oleh aplikasi lain. ESRI harus mengurangi biaya ArcSDE (yang mereka lakukan dengan mengintegrasikannya ke ArcGIS) dan / atau memungkinkan data spasial disimpan dalam format database asli.

Selain itu, pertanyaan yang dilakukan di ArcIMS pada shapefile yang dimaksudkan terkait dengan DBF harus menyertakan semua bidang yang diperlukan dan duplikasi karena tidak ada opsi untuk membuat tampilan spasial, atau dengan mudah menghubungkan fitur dengan basis data ujung belakang.

Alasan Organisasi

Saya setuju dengan yang lain bahwa hingga saat ini data spasial menjadi tipe basis data asli, data tersebut telah lama diabaikan atau dipisahkan oleh administrator basis data dalam organisasi, dan menjadi tanggung jawab manajer GIS. Konsep-konsep desain basis data, normalisasi, replikasi, keamanan, dan tampilan SQL memerlukan skillet yang sangat berbeda dan terspesialisasi serta tidak dapat dipelajari dengan mudah saat Anda melanjutkan.

Alasan Biaya

Menjelaskan dalam tender persyaratan jumlah besar waktu dan upaya untuk dihabiskan pada model data, dan pembersihan / impor data ke dalam model ini seringkali tidak mungkin. Seringkali pembeli proyek datang dari pandangan analitis GIS dan mengabaikan pentingnya data terstruktur.

Dengan 100-kolom-tabel, saya berasumsi Anda maksud jenis output yang Anda dapatkan dari membangun "cakupan utama" overlay beberapa input. Ya, ini adalah artefak dari alur kerja Arc / INFO. Tapi, di pertahanan, Anda juga bisa menganggapnya sebagai tabel de-normalisasi sengaja untuk OLAP . Karena mereka digunakan sebagian besar untuk pemrosesan permintaan, bukan untuk pembaruan data, formulir yang dinormalisasi menjadi masuk akal. Seperti skema bintang , tetapi tanpa, er, poin. OK, teh lemah, tapi tetap saja saya pikir ada sesuatu di sana.

Ya, jika memulai desain proyek GI baru adalah penting dan dapat menghemat waktu = uang di masa depan. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 adalah gambaran umum yang baik mengapa itu penting.