Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego

Transkrypt

1 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Zgodne z ogólną metodologią projektowania baz danych Baza danych przestrzennych modelowa reprezentacja fragmentu świata rzeczywistego Proces budowy bazy danych wymaga rozumowania na kolejnych poziomach abstrakcji.

2 WZRASTAJĄCY POZIOM ABSTRAKCJI PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH ŚWIAT RZECZYWISTY Rzeczywistość złożona z istniejących obiektów zawiera cechy, które mogą nie być istotne w danym opracowaniu.

3 WZRASTAJĄCY POZIOM ABSTRAKCJI PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH ŚWIAT RZECZYWISTY Rzeczywistość złożona z istniejących obiektów zawiera cechy, które mogą nie być istotne w danym opracowaniu. MODEL KONCEPTUALNY Ogólny model wybranych obiektów i procesów, które są uważane za istotne przy rozwiązywaniu danego zadania. Model konceptualny (pojęciowy) - abstrakcja rzeczywistości widziana z określonej perspektywy i o założonej szczegółowości, ma za zadanie zrozumienie problemu i udokumentowanie wyników analiz w czytelnej i abstrakcyjnej formie językowej oraz ułatwienie komunikacji w zespołach ludzkich.

4 WZRASTAJĄCY POZIOM ABSTRAKCJI PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH ŚWIAT RZECZYWISTY Rzeczywistość złożona z istniejących obiektów zawiera cechy, które mogą nie być istotne w danym opracowaniu. MODEL KONCEPTUALNY MODEL LOGICZNY Ogólny model wybranych obiektów i procesów, które są uważane za istotne przy rozwiązywaniu danego zadania. Model konceptualny (pojęciowy) - abstrakcja rzeczywistości widziana z określonej perspektywy i o założonej szczegółowości, ma za zadanie zrozumienie problemu i udokumentowanie wyników analiz w czytelnej i abstrakcyjnej formie językowej oraz ułatwienie komunikacji w zespołach ludzkich. Model logiczny jest reprezentacją rzeczywistości stworzoną w celu rozwiązania konkretnego zagadnienia. Ogólny model wybranych obiektów i procesów, które są uważane za istotne przy rozwiązywaniu danego zadania, opisany w ustrukturalizowany sposób, przy pomocy reguł i środków dostępnych ramach przyjętego modelu danych, zgodnie z przyjętymi regułami syntaktycznymi (w formie schematów danych).

5 WZRASTAJĄCY POZIOM ABSTRAKCJI PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH ŚWIAT RZECZYWISTY Rzeczywistość złożona z istniejących obiektów zawiera cechy, które mogą nie być istotne w danym opracowaniu. MODEL KONCEPTUALNY MODEL LOGICZNY MODEL FIZYCZNY Ogólny model wybranych obiektów i procesów, które są uważane za istotne przy rozwiązywaniu danego zadania. Model konceptualny (pojęciowy) - abstrakcja rzeczywistości widziana z określonej perspektywy i o założonej szczegółowości, ma za zadanie zrozumienie problemu i udokumentowanie wyników analiz w czytelnej i abstrakcyjnej formie językowej oraz ułatwienie komunikacji w zespołach ludzkich. Model logiczny jest reprezentacją rzeczywistości stworzoną w celu rozwiązania konkretnego zagadnienia. Ogólny model wybranych obiektów i procesów, które są uważane za istotne przy rozwiązywaniu danego zadania, opisany w ustrukturalizowany sposób, przy pomocy reguł i środków dostępnych w ramach przyjętego modelu danych, zgodnie z przyjętymi regułami syntaktycznymi (w formie schematów danych). Model fizyczny jest konkretnym zastosowaniem systemów informatycznych; określa jak opracowany schemat będzie przedstawiony w formie cyfrowej w systemie. Precyzyjnie opisuje pliki lub tabele baz danych, relacje między typami obiektów, możliwe do wykonania operacje. Oddzielenie modelowania logicznego od modelowania fizycznego umożliwia implementację bazy danych na wiele różnych sposobów.

6 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Etap I Identyfikacja obiektów Opracowanie modelu danych PROJEKT KONCEPCYJNY Opracowanie planu pozyskiwania danych Materiały źródłowe Ocena materiałów źródłowych Należy ustalić: 0. Przeznaczenie bazy danych 1. Tematyczny zakres bazy danych: Liczbę warstw tematycznych przechowujących informacje Rodzaje obiektów przestrzennych dla każdej z warstw, sposób reprezentacji obiektów (punktowe, liniowe, powierzchniowe) oraz atrybuty (wraz z podaniem dziedzin atrybutów) Związki między obiektami Modele danych reprezentujące wymienione obiekty (np. wektorowy prosty, wektorowy topologiczny, rastrowy TIN), 2. Parametry jakości danych geometrycznych i opisowych Dokładność położenia, Dokładność atrybutów, Szczegółowość i rozdzielczość, Aktualność, 3. Metody i źródła pozyskania danych 4. Ocena materiałów źródłowych oraz plan pozyskania danych 5. Struktura przestrzenna bazy danych (np. baza jednolita lub krój arkuszowy) oraz układ współrzędnych 6. Sposób prezentacji kartograficznej obiektów 7. Ogólne zasady dostępu do danych

7 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE Wynikiem modelowania koncepcyjnego jest dokument zawierający opis modelowanej rzeczywistości, sporządzony w języku naturalnym lub jednym z języków formalnych. Do opisu stosuje się wiele notacji, w tym diagramy związków encji ERD, odwzorowujące obiekt i powiązania między nimi w postaci grafu. Notacja ERD jest używana głównie do modelowania danych zawartych w relacyjnych bazach danych. Językiem modelowania wspierającym obiektowe podejście do projektowania i programowania jest UML (Uniwersalny Język Modelowania, Unified Modeling Language)

8 UML UML uwzględnia różne sposoby widzenia osób uczestniczących w procesie modelowania złożonych systemów. Jest często określany jako język modelowania z 4+1 perspektywą. Cztery pierwsze opisują wewnętrzną strukturę systemu na różnych poziomach abstrakcji i szczegółowości. Ostatnia perspektywa opisuje funkcjonalność systemu widzianą przez jego użytkowników. Każda perspektywa korzysta z własnego zestawu diagramów pozwalających czytelnie przedstawić modelowane zagadnienie. Są to: Perspektywa przypadków użycia opisuje funkcjonalność, jaką powinien dostarczać system, widzianą przez jego użytkowników. Perspektywa logiczna zawiera sposób realizacji funkcjonalności, strukturę systemu widzianą przez projektanta Perspektywa implementacyjna opisuje poszczególne moduły i ich interfejsy wraz z zależnościami; perspektywa ta jest przeznaczona dla programisty Perspektywa procesowa zawiera podział systemu na procesy (czynności) i procesory (jednostki wykonawcze); opisuje właściwości pozafunkcjonalne systemu i służy przede także programistom i integratorom Perspektywa wdrożenia definiuje fizyczny podział elementów systemu i ich rozmieszczenie w infrastrukturze; perspektywa taka służy integratorom i instalatorom systemu

9 UML Trzon UML stanową diagramy opisujące w różny sposób modelowaną strukturę. Aktualna specyfikacja UML definiuje 13 diagramów diagramy struktury - diagram klas - diagram obiektów - diagram pakietów - diagram struktur złożonych - diagram komponentów - diagram wdrożenia diagramy zachowań - diagram przypadków użycia - diagram czynności - diagram maszyny stanów diagramy interakcji - diagram sekwencji, - diagram komunikacji, - diagram opisu interakcji, - diagram przebiegów czasowych

10 UML Diagram przypadków użycia definiuje granice modelowanego systemu określa jego kontekst wymienia użytkowników systemu i jednostki zewnętrzne przedstawia funkcje dostępne dla użytkowników określa powiązania i zależności pomiędzy nimi Diagram przypadków użycia (ang. use-case diagram) służy do modelowania aktorów (użytkowników systemu, odbiorców efektów pracy systemu, systemów zewnętrznych) i ich potrzeb w stosunku do tworzonego systemu. Przypadki użycia prezentowane na tym diagramie to sekwencje czynności, które prowadzą do spełnienia celu przypadku użycia (zaspokojenia pewnej potrzeby użytkownika). Aktor inicjuje wykonanie funkcji systemu wymaga dostępu do systemu reprezentuje punkt widzenia na system jest osobą fizyczną, rolą w systemie lub systemem zewnętrznym

11 UML. Diagram klas Diagram klas przedstawia klasy występujące w systemie i statyczne relacje pomiędzy nimi wraz z ograniczeniami. Jest podstawowym diagramem struktury logicznej systemu. Klasa +atrybutpubliczny: Typ {readonly} #atrybutchroniony: Typ -atrybutprywatny: Typ ~atrybutpakietowy: Typ +metodapubliczna(): TypZwracany -metodaprywatna (TypParametru):void Na diagramie są prezentowane klasy, ich atrybuty i operacje, oraz powiązania między klasami. Klasa jest reprezentowana przez prostokąt z wydzielonymi przedziałami: nazwą, atrybutami i operacjami. W celu zwiększenia czytelności, dowolny z nich można ukryć bądź dodać nowy (np. przechowujący zdarzenia lub wyjątki). Obiekt jest instancją klasy, podobnie jak w przypadku programowania obiektowego. Nazwa obiektu jest umieszczana przed nazwą klasy i oddzielana od niej dwukropkiem. Obiekt:Klasa

12 UML. Diagram klas Klasa +atrybutpubliczny: Typ {readonly} #atrybutchroniony: Typ -atrybutprywatny: Typ ~atrybutpakietowy: Typ +metodapubliczna(): TypZwracany -metodaprywatna (TypParametru):void Cechy klasy reprezentują informację, jaką klasa przechowuje. Mogą zostać zapisane w postaci dwóch, w zasadzie równoważnych notacji: jako atrybuty klasy (umieszczane w przedziale atrybutów) lub jako relacje pomiędzy klasami (zapisywane w postaci linii łączącej klasy). Zwykle pierwsza notacja jest stosowana do typów prostych lub obiektów reprezentujących wartości, natomiast druga do typów złożonych. Operacje reprezentują usługi, jakie klasa oferuje. Ich realizacje metody dostarczają implementacji tych usług.

13 UML. Diagram klas Klasa +atrybutpubliczny: Typ {readonly} #atrybutchroniony: Typ -atrybutprywatny: Typ ~atrybutpakietowy: Typ +metodapubliczna(): TypZwracany -metodaprywatna (TypParametru):void Zwykle atrybut jest opisywany tylko przez dwa elementy: nazwę i typ. Jednak pełna definicja obejmuje także: widoczność atrybutu, definiującą, z jakich miejsc systemu atrybut jest dostępny, krotność, która określa ile obiektów mieści się w atrybucie, dodatkowe ograniczenia nałożone na atrybut i wartość domyślną. Elementom, których w definicji atrybutu nie podano wartości, przypisywane są wartości domyślne (widoczność prywatna, krotność 1) lub pomija się je.

14 UML. Diagram klas Klasa +atrybutpubliczny: Typ {readonly} #atrybutchroniony: Typ -atrybutprywatny: Typ ~atrybutpakietowy: Typ +metodapubliczna(): TypZwracany -metodaprywatna (TypParametru):void UML definiuje 4 poziomy widoczności cech i metod + publiczny element jest widoczny z każdego miejsca w systemie # chroniony element jest widoczny we własnej klasie i jej podklasach prywatny element jest widoczny tylko we własnej klasie ~ publiczny wewnątrz pakietu element jest widoczny tylko wewnątrz własnego pakietu

15 UML. Diagram klas Krotność pozwala określić minimalną i maksymalną liczbę obiektów, jakie można powiązać z daną cechą: dolna granica..górna granica przedział od-do 1 dokładnie jeden obiekt 0..1 opcjonalnie jeden obiekt 1..* przynajmniej jeden obiekt 1, 3, 5 konkretne liczby obiektów * dowolna liczba obiektów

16 UML Zależności są najprostszym i najsłabszym rodzajem relacji łączących klasy. Oznaczają, że zmiana jednej z nich w pewien sposób wpływa na drugą, np. «call» operacje w klasie A wywołują operacje w klasie B «create» klasa A tworzy instancje klasy B «instantiate» obiekt A jest instancją klasy B «use» do zaimplementowania klasy A wymagana jest klasa B Producent «create» Zasób Asocjacja reprezentuje czasowe powiązanie pomiędzy obiektami dwóch klas. Obiekty związane asocjacją są od siebie niezależne. Asocjacja jest też używana jako alternatywny (obok atrybutu) i równorzędny sposób zapisu cech klasy A 0..1 związek * +rola A w B +rola B w A B

17 UML Agregacja reprezentuje relację typu całość-część, w której część może należeć do kilku całości, a całość nie zarządza czasem istnienia części. Relacja agregacji jest zaznaczana linią łączącą klasy/obiekty, zakończoną białym rombem po stronie właściciela A B Kompozycja jest relacją typu całość-część, w której całość jest wyłącznym właścicielem części, tworzy je i zarządza nimi. Kompozycja jest najsilniejszą relacją łączącą klasy. Ani całość, ani części nie mogą istnieć bez siebie, dlatego czasy ich istnienia są bardzo ściśle ze sobą związane i pokrywają się: w momencie usunięcie obiektu całości obiekty części są również usuwane. Typowa fraza związana z taką relacją to "...jest częścią...". Kompozycja jest przedstawiana na diagramie podobnie jak agregacja, przy czym romb jest wypełniony. A B

18 UML Uogólnienie tworzy hierarchię klas, od ogólnych do bardziej szczegółowych. Pozwala wyłączyć części wspólne klas. A B C D

19 UML. Przykłady INSPIRE Data Specification. Generic Conceptual Model. Ref. D2.5.-v.32., p.39 Ekstrakt z ogólnego modelu obiektu.

20 UML. Przykłady Specyfikacje danych dla modelu georeferencyjnego Bazy Danych Ewidencji Gruntów i Budynków. BGWM/ZP/335-19/08 ETAP I/3b Diagram zależności przedmiotowe: ZależnościDziałkaBudynekLokal

21 GML - Geography Markup Language - język oparty na XML extensible Markup Language

22 GML. Przykład zapisu danych

23 GML. Przykład prostego schematu definiującego element złożony <?xml version="1.0" encoding="utf-8"?> <xs:schema xmlns:xs=" elementformdefault="qualified" attributeformdefault="unqualified"> <xs:element name="okresczasu"> <xs:annotation> <xs:documentation> Prosty przykład schematu </xs:documentation> </xs:annotation> <xs:complextype> <xs:sequence> <xs:element name="nazwa"/> <xs:element name="początek"/> <xs:element name="koniec"/> </xs:sequence> </xs:complextype> </xs:element> </xs:schema>