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

15

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?

Nicklas Avén
źródło
W przypadku ArcGIS znormalizowana baza danych z referencyjną integralnością jest trudna do osiągnięcia, ponieważ jesteś ograniczony tylko do funkcji bazy danych, które są dostępne i obsługiwane przez ArcGIS. Jest to bardzo frustrujące, gdy facet relacyjnych baz danych ... gra w telefon, z ArcSDE pośrodku.
nw1

Odpowiedzi:

16

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.

Kelso
źródło
1
+1 za kluczowy punkt rozróżnienia między oprogramowaniem dyktującym strukturę db a „najlepszym” projektem dla charakteru danych.
matt wilkie
Tak, zgadzam się zarówno z tą odpowiedzią, jak i komentarzem Matta. Mam jednak nadzieję, że ktoś może wyjaśnić, dlaczego tak często się nie stosuje. Zmienię trochę pytanie.
Nicklas Avén
Zgadzam się. Jedną dodatkową rzeczą, którą znalazłem, jest to, że wydajność bazy danych może wpływać na decyzję o normalizacji lub nie. W niektórych przypadkach widzę, że używane są dwie bazy danych, jedna „główna” baza danych zawierająca znormalizowane dane i jedna dodatkowa baza danych używana tylko do celów wyświetlania. Ten zawiera tylko to, co jest potrzebne do wyświetlenia danych (GIS), zwykle w jednej tabeli.
Berend
Aby rozwinąć punkt Berendsa, jednym z głównych powodów tej denormalizacji jest to, że zmaterializowane widoki są często nieco trudne i specyficzne dla DB do wdrożenia, więc zwykle lepiej jest po prostu stworzyć własną tabelę / bazę danych do przechowywania zdormalizowanych danych.
Alexander
6

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.

BlinkyBill
źródło
1
to też czuję, ale mam nadzieję, że wyjaśnienie bardziej przypomina dyskusję Paula, że ​​jest w jakiś sposób świadomym wyborem. dałoby to więcej sensu działalności GIS przy tak wielu fantazyjnych słowach, modeluje „techniki niż odkrywanie, że baza danych na dole była niewłaściwie wykorzystywana z powodu niewiedzy.
Nicklas Avén
1
przepraszam, niewłaściwe użycie jest złe. jeśli jest to delibirat z uzasadnionego powodu, nie jest niewłaściwie używane.
Nicklas Avén
5

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.

geografia
źródło
Rozumiem i zgadzam się z większością tego, co piszesz. Ale powiedzenie, że część SDE jest przyznawana za darmo po zmianie nazwy na serwer ArcGIS, nie oznacza to, że: jeśli kupisz piękny kolor tego samochodu za 100000 dolarów, resztę samochodu otrzymasz za darmo. Nie znam ArcGIS tak dobrze, ale czym jest serwer ArcGIS bez części SDE? i nigdy nie słyszałem, żeby ktokolwiek powiedział, że serwer ArcGIS jest tani. Naprawdę nie widzę wpływu typów przestrzennych SQL Server na ArcGIS. Ale ponieważ produkty Arc są tak szeroko rozpowszechnione, zgadzam się, że droga Arc ma duży wpływ na to, jak ludzie myślą o swoich danych przestrzennych.
Nicklas Avén
Przed ArcGIS Server ArcSDE był całkowicie oddzielny od ArcMap i ArcIMS i musiał być kupowany i licencjonowany osobno. Ponieważ ArcSDE był jedynym sposobem przechowywania danych przestrzennych w SQL Server (lub Oracle w tym czasie), oznaczało to, że dane przestrzenne były przechowywane gdzie indziej.
geographika
ok, ArcIMS w pakiecie z SDE to nowy pomysł. Arcmap nadal potrzebuje oddzielnych licencji na użytkownika lub zmienną, prawda? offtopic, ale jestem trochę ciekawy.
Nicklas Avén
Nowa koncepcja nie zapewnia dostępu do danych przestrzennych / ich przechowywania w relacyjnej bazie danych bez płacenia dużych kwot. esri.com/software/arcgis/arcsde/index.html
geographika
czy serwer ArcGIS nie ma dużych pieniędzy? O ile wiem, nie można używać formatu sqlserver fomat lub postgis (bez ziggis) w arcmap bez sde, przepraszam ArcGIS Server pomiędzy.
Nicklas Avén
4

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.

Paul Ramsey
źródło
1
tak, Paul. Wiedziałem, że będzie jakieś wyjaśnienie, w tym słowa, których tak naprawdę nie rozumiem :-). Bardzo ciekawe, że kryje się za tym przemyślana historia. Świetny!
Nicklas Avén