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. 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).

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. 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 Conceptual model Model koncepcyjny identyfikuje najważniejsze rodzaje encji i powiązań między tymi jednostkami. Encja (ang. entity) reprezentacja wyobrażonego lub rzeczywistego obiektu (grupy obiektów) stosowana przy modelowaniu danych podczas analizy informatycznej. Pojęcie to posiada różniące się definicje, zmieniające się z czasem

7 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Conceptual model Model koncepcyjny identyfikuje najważniejsze rodzaje encji i powiązań między tymi jednostkami. Cechy modelu koncepcyjnego: Zawiera ważne encje i powiązania między nimi. Własności encji nie są określone. Klucze główne nie są określone.

8 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Logical Model Model logiczny opisuje dane tak dokładnie jak to możliwe, ale bez szczegułów jak one fizycznie będą przechowywane w bazie danych. Cechy modelu logicznego: zawiera wszystkie encje i powiązania między nimi. własności każdej encji są określone. klucz główny każdej encji jest określony. klucze obce (klucze identyfikujące powiązania między encjami) są określone.

9 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Logical Model Poziom występowania normalizacji. Kroki projektowania modelu logicznego bazy danych: określ klucze własne wszystkich encji określ powiązania pomiędzy encjami określ wszystkie własności encji. rozwiąż powiązania many-to-many między encjami. Normalizacja - Sprawdzenie integralności, redundancji (nadmiarowości), upraszczanie bazy (optymalizacja struktury) poprzez kompozycję lub dekompozycję encji i powiązań

10 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Logical Model Poziom występowania normalizacji.

11 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Logical Model Poziom występowania normalizacji.

12 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Physical model Model fizyczny przedstawia jak model bazy będzie zrealizowany w bazie danych. Model fizyczny określa kompletną strukturę tablic, w tym: nazwy kolumn, typy danych, ograniczenia wartości, klucz główny, klucze obce, powiązania między tablicami,.

13 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Physical model Cechy modelu fizycznego: Specyfikacja wszystkich tablic i ich kolumn Wszystkie klucze obce są użyte do tworzenia powiązań między tablicami.. Na życzenie użytkownika może pojawić się Denormalizacja bazy.

14 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Physical model Realizacyjne aspekty mogą powodować, że moel fizyczny bazy może być całkiem odmienny od modelu logicznego Model fizyczny może być różny dla różnych systemów baz danych RDBMS.

15 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Physical model Kroki tworzenia bazy fizycznej: konwertuj encje na tablice konwertuj powiąznia na klucze obce konwertuj atrybuty na kolumny modyfikuj model fizyczny stosownie do ograniczeń/rekomendacji dla danego systemu bazy danych

16 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH Model koncepcyjny Model Logiczny Model Fizyczny (Conceptual model) (Logical Model) (Physical model) Własność Koncepcyjny Logiczny Fizyczny Nazwa encji Powiązania encji Atrybuty Klucz główny Klucz obcy Nazwy tablic Nazwy kolumn Typy danych kolumn

17 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) Powiązania 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

18 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY Wynikiem modelowania koncepcyjnego jest dokument zawierający opis modelowanej rzeczywistości, sporządzony w: języku naturalnym lub jednym z języków formalnych.

19 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY języki formalne: ERD (Entity Relational Data model) UML (Uniwersalny Język Modelowania, Unified Modeling Language)

20 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY ERD (Entity Relational Data model) 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.

21 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY ERD (Entity Relational Data model) Notyfikacja Crow Foot

22 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY ERD (Entity Relational Data model) Notyfikacja Martin a

23 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY ERD (Entity Relational Data model) Notyfikacja Chen a

24 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY UML (Uniwersalny Język Modelowania, Unified Modeling Language) Język modelowania wspierający obiektowe podejście do projektowania i programowania.

25 UML UML - język utworzony do wspomagania inżynierii systemów i oprogramowania do Specyfikacji Wizualizacji Projektowania Dokumentowania Projektów

26 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY, LOGICZNY, FIZYCZNY UML (Uniwersalny Język Modelowania, Unified Modeling Language) Język modelowania wspierający obiektowe podejście do projektowania i programowania.

27 PROJEKTOWANIE BAZ DANYCH PRZESTRZENNYCH - NOTACJE MODEl KONCEPCYJNY I LOGICZNY UML (Uniwersalny Język Modelowania, Unified Modeling Language)

28 UML UML - uwzględnia różne sposoby widzenia zasobów przez osoby uczestniczące 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.

29 UML 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 wszystkim 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

30 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

31 UML MS VISIO

32 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

33 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

34 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.

35 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.

36 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

37 UML. Diagram klas Relacje między obiektami różnych klas - pojęcie krotności 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

38 UML Tryger (wzbudzenie) są najprostszym i najsłabszym rodzajem relacji łączących klasy. Oznaczają, że zmiana jednej z nich w pewien sposób wpływa na drugą (Triggers), 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

39 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

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

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