İyi veritabanı tasarımı, uzamsal veritabanları için daha az önemli midir?

Uzamsal verilerle uğraşırken veritabanı tasarımı ve normalleştirmenin genellikle ikinci elden geldiğini güçlü bir şekilde hissediyorum.

Yazılım servet maliyeti ve 100'den fazla alan tabloları ile veritabanları ile sormak zorunda:

Bir uzamsal veritabanı tasarlarken normalleştirmekten başka düşünmek için iyi nedenler var mı?

Sanırım insanlar örnek isteyecekler, ama burada veremiyorum, bu yüzden sorum belki 100 alanın problemsiz ve bakımı normalleştirilmiş bir tasarıma göre daha kolay olduğu anlamına gelenlere daha fazla yönelik.

Tartışmalar nelerdir?

Uzamsal veritabanlarının geleneksel veritabanlarından farklı davranılmaması gerektiğini hissediyorum. Aslında aynı şeyi yapıyorlar, hızlı erişim için büyük miktarda veri depolıyorlar. Örnek olarak, PostgreSQL / PostGIS'de geometri sadece başka bir veri tipidir. Tıpkı metin veya tamsayı gibi. SQL Server 2008 ile aynı. Oracle ile aynı. "Uzamsal" bölüm veritabanındaki başka bir alan türüyse, orijinal veritabanından gerçekten farklı mıdır? Bu, geleneksel veritabanı tasarımının tüm kurallarını atmamız gerektiği anlamına mı geliyor?

Açıkçası normalleştirme, geleneksel veritabanlarında olduğu gibi çok ileriye götürülebilir, bu nedenle ihtiyaçlarınıza en uygun tasarımı bulmak bir değiş tokuştur.

100 sütunlu tablolarla oldukça normalleştirilmemiş bir yapı oluşturmayı planlıyorsanız, gelecekte neyin değişmesi muhtemel olduğunu kendinize sormalısınız? Satırlardaki büyük artışla bu, sorgulama performansını da etkiler mi? Bu, gelecekte sürdürülebilirliği etkileyecek mi?

Normalleştirilmiş bir yapı oluşturmada ve görünümleri kullanarak tüm verileri veritabanı istemcisine, CBS'ye veya başka bir istemciye göstermek için yanlış olan nedir?

Tüm bu sorular hem geleneksel veritabanları hem de uzamsal veritabanları için geçerlidir. Http://en.wikipedia.org/wiki/Database_normalization üzerinden giderseniz , bunun uzamsal veritabanları için de geçerli olduğunu göreceksiniz.

Veritabanının üstünde kullandığınız yazılım sizi oldukça normalleştirilmemiş yapıları kullanmaya zorluyorsa, bu farklı bir argüman. Veritabanı tarafından değil yazılım tarafından kısıtlandığınızdan, en iyi veritabanı tasarımında seçeneğiniz yoktur.

Bence, kısa cevap (bence) veritabanı tasarımı, geleneksel veritabanlarında olduğu gibi mekansal veritabanlarında da önemlidir.

Bunu çok görüyorum. Geleneksel CBS insanlarının araştırma geçmişinden geldiği ve veritabanları hakkında bir arka plana / anlayışa sahip olmadığı gerçeğinden kaynaklandığını hissediyorum. Yine de bu değişikliği görüyorum, gitgide daha fazla kuruluş CBS altyapısını BT katmanına taşıyor.

CBS Yazılım Eski

ArcSDE'nin önceki yüksek maliyeti ve SQL Server'da (2008'e kadar) ve Oracle'da sürüm 10'a kadar uzamsal bir veri türünün olmaması, birçok kuruluş için (ve teklif sahipleri tarafından teklif maliyetlerini düşük tutmak için) verileri dosya dosyalarında depolamaktan başka bir seçenek olmadığı anlamına geliyordu. .

SQL Server'da yerel uzamsal türlerin tanıtımı, ArcSDE'nin büyük bir yatırımdan ArcGIS'e ücretsiz olarak dahil edilmesine ve kuruluşlardaki uzamsal verilerin "katlanmasına" gitmesi anlamına geliyordu.

ArcGIS ve SQL Server kullanan kuruluşların önceden üç seçeneği vardı:

1. ArcSDE'yi satın almak ve uzamsal verileri "uygun" SQL Server veritabanlarında depolamak için 20k + ücretini ödeyin.
2. Uzamsal verileri şekil dosyalarında / kişisel GDB'lerde depolayın ve diğer kurumsal verilerin veritabanlarında bağlantı oluşturun (veya bu öznitelikleri DBF'lere aktarın)
3. CBS satıcılarını değiştirin ve uzamsal verileri tek bir veritabanında saklayın, ancak yalnızca yeni CBS yazılımı tarafından erişilebilir bir biçimde

SQL Server yerel bir uzamsal türe sahip olduğunda, çoğu satıcı bunu özel formatları yerine kullandı, yani uzamsal verilere aniden diğer uygulamalar tarafından erişilebilir. ESRI, ArcSDE'nin maliyetini (ArcGIS'e entegre ederek yaptıkları) azaltmak ve / veya uzamsal verilerin yerel veritabanı formatında saklanmasına izin vermek zorundaydı.

Buna ek olarak, DBIM'lerle ilişkilendirilen şekil dosyalarında ArcIMS'de yapılan sorgular, uzamsal görünüm oluşturma veya özellikleri bir arka uç veritabanıyla kolayca bağlama seçeneği olmadığından gerekli tüm alanları ve çoğaltmayı içermelidir.

Örgütsel Nedenler

Yakın zamanda uzamsal verilerin yerel bir veritabanı türü haline gelmesine kadar uzun süredir göz ardı edildiği veya kuruluşlardaki veritabanı yöneticileri tarafından ayrı tutulduğu ve bir CBS yöneticisinin sorumluluğu haline geldiğini kabul ediyorum. Veritabanı tasarımı, normalleştirme, çoğaltma, güvenlik ve SQL görünümleri kavramları genellikle çok farklı ve özel bir beceri seti gerektirir ve ilerledikçe kolayca öğrenilemez.

Maliyet Nedenleri

Bir ihalede bir veri modeline harcanacak çok fazla zaman ve çaba gerekliliğinin açıklanması ve bu modele veri temizlenmesi / aktarılması çoğu zaman imkansızdır. Genellikle proje alıcıları CBS'nin analitik bir bakış açısıyla geliyor ve yapılandırılmış verilerin önemini göz ardı ediyor.

100 sütunlu tablolar ile, birden çok girdinin "ana kapsama alanı" kaplamalarını oluştururken elde ettiğiniz çıktı türlerini kastediyorsunuz. Evet, bunlar Arc / INFO iş akışının eserleridir. Ancak, savunmada, onları OLAP için kasıtlı olarak normalize edilmemiş tablolar olarak da düşünebilirsiniz . Veri güncellemesi için değil, büyük ölçüde sorgu işleme için kullanıldığından, normalleştirilmemiş form bir anlam ifade eder. Bir yıldız şeması gibi , ama noktaları olmadan. Tamam, zayıf çay, ama yine de orada bir şey olduğunu düşünüyorum.

Evet, eğer yeni bir GI proje tasarımı başlatmak önemlidir ve gelecekte zamandan tasarruf = para kazanabilirsiniz. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 neden önemli olduğuna dair iyi bir genel bakış.