Czy dobry projekt bazy danych jest mniej ważny w przypadku baz danych przestrzennych?

Mam silne przeczucie, że projektowanie i normalizacja baz danych często przydaje się w przypadku danych przestrzennych.

Z oprogramowaniem kosztującym fortunę i bazami danych z ponad 100 tabelami pól muszę zapytać:

Czy istnieją uzasadnione powody, by brać pod uwagę inne czynniki niż normalizacja przy projektowaniu przestrzennej bazy danych?

Sądzę, że ludzie będą pytać o przykłady, ale których nie mogę tu podać, więc moje pytanie może być bardziej skierowane do tych, którzy oznaczają, że 100 pól nie stanowi problemu i jest łatwiejsze w utrzymaniu niż odpowiedni znormalizowany projekt.

Jakie są argumenty?

Uważam, że przestrzenne bazy danych nie powinny być traktowane inaczej niż tradycyjne bazy danych. Zasadniczo robią to samo, przechowując duże ilości danych w celu szybkiego wyszukiwania. Na przykład w PostgreSQL / PostGIS geometria jest tylko kolejnym typem danych. Podobnie jak tekst lub liczba całkowita. To samo w SQL Server 2008. To samo w Oracle. Jeśli część „przestrzenna” jest po prostu innym typem pola w bazie danych, to czy tak naprawdę różni się od oryginalnej bazy danych? Czy to oznacza, że ​​powinniśmy wyrzucić wszystkie zasady tradycyjnego projektowania baz danych?

Oczywiście normalizacja może być podjęta zbyt daleko, podobnie jak w przypadku tradycyjnych baz danych, więc kompromisem jest znalezienie najlepszego projektu, który odpowiada Twoim potrzebom.

Jeśli planujesz stworzyć wysoce zdenormalizowaną strukturę z tabelami zawierającymi 100 kolumn, musisz zadać sobie pytanie, co może się zmienić w przyszłości? Czy przy znacznym wzroście liczby wierszy wpłynie to również na wydajność zapytań? Czy wpłynie to na łatwość utrzymania w przyszłości?

Co jest złego w tworzeniu znormalizowanej struktury i korzystaniu z widoków w celu ujawnienia wszystkich danych klientowi bazy danych, czy to GIS, czy innemu klientowi?

Wszystkie te pytania dotyczą zarówno tradycyjnych baz danych, jak i baz danych przestrzennych. Jeśli przejdziesz przez http://en.wikipedia.org/wiki/Database_normalization , przekonasz się, że dotyczy to również baz danych przestrzennych.

Jeśli oprogramowanie, którego używasz na bazie bazy danych, zmusza cię do korzystania z wysoce zdenormalizowanych struktur, jest to inny argument. Jesteś ograniczony przez oprogramowanie, a nie bazę danych, więc nie masz wyboru w najlepszym projekcie bazy danych.

Myślę więc, że krótka odpowiedź brzmi (moim zdaniem) projektowanie baz danych jest tak samo ważne w przypadku baz danych przestrzennych, jak i tradycyjnych baz danych.

Często to widzę. Wydaje mi się, że wynika to z faktu, że tradycyjnie ludzie z GIS pochodzą z badań ankietowych i nie mają wiedzy o bazach danych. Widzę jednak tę zmianę, ponieważ coraz więcej organizacji przenosi infrastrukturę GIS do działu IT.

Starsze oprogramowanie GIS

Dotychczasowy wysoki koszt ArcSDE i brak typu danych przestrzennych w SQL Server (do 2008 r.) I Oracle do wersji 10 oznaczało, że nie było innego wyboru, jak przechowywać dane w plikach kształtowych dla wielu organizacji (i przez oferentów, aby obniżyć koszty ofert) .

Wprowadzenie rodzimych typów przestrzennych w SQL Server prawie natychmiast oznaczało, że ArcSDE przeszedł z ogromnej inwestycji, został włączony za darmo do ArcGIS i „wprowadził do foldu” danych przestrzennych w organizacjach.

Organizacje korzystające z ArcGIS i SQL Server wcześniej miały trzy możliwości:

1. Zapłać ponad 20 tys. Opłat za zakup ArcSDE i przechowywanie danych przestrzennych w „odpowiednich” bazach danych SQL Server.
2. Przechowuj dane przestrzenne w plikach kształtów / osobistych GDB i łącz z pozostałymi danymi organizacyjnymi w bazach danych (lub eksportuj te atrybuty do DBF)
3. Przełącz dostawców GIS i przechowuj dane przestrzenne w jednej bazie danych, ale w formacie dostępnym tylko dla nowego oprogramowania GIS

Gdy SQL Server miał natywny typ przestrzenny, większość dostawców używało go zamiast swoich zastrzeżonych formatów, co oznacza, że ​​dostęp do danych przestrzennych mogą nagle uzyskać inne aplikacje. ESRI musiał albo obniżyć koszty ArcSDE (co zrobili poprzez integrację z ArcGIS) i / lub pozwolić na przechowywanie danych przestrzennych w macierzystym formacie bazy danych.

Ponadto zapytania wykonywane w ArcIMS na plikach kształtu związanych z DBF musiały obejmować wszystkie wymagane pola i duplikacje, ponieważ nie było opcji tworzenia widoków przestrzennych ani łatwego łączenia funkcji z bazą danych zaplecza.

Przyczyny organizacyjne

Zgadzam się z innymi, że do niedawna dane przestrzenne stały się rodzimymi typami baz danych, długo były ignorowane lub przechowywane osobno przez administratorów baz danych w organizacjach i stały się odpowiedzialnością menedżera GIS. Pojęcia dotyczące projektowania baz danych, normalizacji, replikacji, zabezpieczeń i widoków SQL wymagają często bardzo różnych i specjalistycznych umiejętności i nie można ich łatwo nauczyć podczas pracy.

Powody kosztowe

Wyjaśnienie w przetargu wymogu poświęcenia dużej ilości czasu i wysiłku na model danych oraz czyszczenia / importowania danych do tego modelu jest często niemożliwe. Często nabywcy projektu wychodzą z analitycznego widoku GIS i pomijają znaczenie danych strukturalnych.

Przez 100-kolumnowe tabele zakładam, że masz na myśli rodzaje wyników, jakie uzyskujesz, budując nakładki „zasięgu głównego” wielu danych wejściowych. Tak, są to artefakty przepływu pracy Arc / INFO. Ale w obronie można również myśleć o nich jako o umyślnie zdenormalizowanych tabelach dla OLAP . Ponieważ są one używane głównie do przetwarzania zapytań, a nie do aktualizacji danych, forma zdenormalizowana ma pewien sens. Jak schemat gwiezdny , ale bez punktów. OK, słaba herbata, ale myślę, że coś tam jest.

Tak, jeśli rozpoczęcie nowego projektu GI jest ważne i może zaoszczędzić czas = pieniądze w przyszłości. http://www.amazon.com/Spatial-Database-Systems-Implementation-Management/dp/1402053916 to dobry przegląd, dlaczego jest to ważne.