Data model: Document description of data
DB를 build하기 위해서 Data model이 필요함
DB build할 때 참고해야 할 것들
- querying ability
- redundancy(최소화)
- consistency(유지)
GIS는 layer의 집합으로 구성된 데이터들임
GIS layer 단계
- background
- network
- POI: Point of interest (지명, 건물 등)
Data model의 이점들
• Early analysis of properties, e.g. storage cost, querying ability, ...
• Reuse of shared data among multiple applications
• Exchange of data across organization
• Conversion of data to new software / environment
2 types of datamodel
1. Generic data model
- support simple abstract data type(ADT): 숫자, 문자 등등
2. Application Domain specific
- spatial models
Spatial data 모델링 방법
위의 GIS정보를 표현한다고 할 때,
1. Field based
- 함수형태로 표현
2. Object based (이것에 대해서 배울 것임)
무엇을 객체화 할 것인가
object를 객체화함
object: 구별가능하고 식별 가능한 것을 객체화 하기로 함
attribute : 객체의 속성을 표현(나이, 위치 좌표)
- spatial: 위치
- non-spatial: 길의 이름, 거주지역, 고속도로인지 일반도로인지, 몇 차선인지 등
operation: 길의 길이, 다른도로와 겹치는지에 대한 opertion을 정의
Spatial object type
- simple: 점, 선, 면
- collection: 여러개의 simple이 합쳐진 것
eg) 하와이의 경계선을 표현하기위해 선, 면 등의 다양한 것으로 표현함
관계도 설명
위의 그림에서
빨간 화살표 방향은 generalization
파란 화살표 방향은 specialization
하얀색은 다이아몬드는 하나의 포인트가 여러개에 sharing되어 있음을 뜻함
(하얀색 다이아몬드 = 네비게이션)
검은색은 다이아몬드는 구성원이긴 하나 sharing 안되어 있는 것을 뜻함
(검은색 다이아몬드 = composition)
2*옆에 star마크는 선이 여러개 있음을 뜻함
eg) 선분을 구성하기위해서는 최소 점 2개가 있어야함
Classifying operation
- Set based
- Topological operation
- Directional
- Metric: 2포인트가 metric space에있다는 것은 아래의 조건을 만족한다는 것임
topological operation 예시
선과 면의 관계에서 하나의 선이 면을 cross 하는지에 대한 True False 값
Topological Relationships
두 object에 대한 관계를 표현하는 것으로 spatial data에서 많이 사용 됨
eg) 미국과 인접한 국가는 어느 국가인가(touch - region, region)
Topological concept 예시
A, B의 2개의 object 가 있다면
위와 같은 9개의 조합으로 표현할 수 있고
그 값에 대해 1, 0 으로 나타낼 수 있음
A의 내부와 B의 외부는 겹침 = 1 (파란색으로 표시한 부분) = disjoint되어있음
A의 내부와 B의 boundary는 겹치지 않음 (빨간색 표시부분)
DB 설계를위한 3 steps
1. 개념설계 단계
conceptual modeling(ER diagram 모델)
개념설계, 데이터 타입, 제약조건 확인
2. logical 설계 단계
어떤 logic을 사용하는지
관계형 모델이라면 관계형 DB구조로 바꿔줘야 함
(모든 형태의 데이터를 table 형태로 변환하는 과정임)
3. physical 설계 단계
실제 저장할때는 어떤 file 형태로 저장할지 정의해야함
어떤 indexing으로 저장할지 정의
** DB설계 시, end-users와의 requirements 논의가 중요함
개념설계 단계에서의 3가지 기본개념
- entity 파악 (숲, 도로, 나무)
- entity 속성(숲 이름)
- entity간의 관계(숲은 access라는 관계로 접근할 수 있음)
ER model의 단점:
사용자가 정의한 operation은 허용 되지 않음
객체지향모델에서는 관계가 적용되지 않음(지원불가)
→ 객체전환 operation을 통해 다른 객체하고 관계를 표현하는 것으로 해결할 수 있음
Relation type: Cardinality 타입
Types of Cardinality constraints for binary relationships
- One-One: An instance of an entity relates to a unique instance of other entity.
- Many-One: Many instances of an entity relate to an instance of another.
- Many-Many: Many instances of one entity relate to multiple instances of another
Cardinality constraints relationship 예시)
Many facilities belong to a forest. Each facility belongs to one forest.
> one - many
A manager manages 1 forest. Each forest has 1 manager.
> one - one
A river supplies water to many facilities. A facility gets water from many rivers.
> many - many
ER diagram 구성 도식
River는 곡선이므로 여러개의 line id(직선)로 곡선을 표현함
Relation schema
- Primary key: 주민등록번호
하나의 속성이나, 여러 속성의 집합으로 만듦
- Foreign key
R, S라는 테이블이 있을 때, 타 테이블의 primary key이면서 현 테이블의 속성인 값
• Value of a foreign key in any tuple of R match values in some row of S
(normal forms 수업 X pass)
Mapping rule for ER ( 객체전환 operation?)
1. entity는 관계로 표현됨
2. entity의 모든 속성은 colunm으로 표현
3. multi-value가 있는 것은 새로운 테이블로 만들고 foreign key로 가지고 옴
4. 1:N, 1:1에 대해서는 별도의 테이블로 만들 지 않음 (foreign key로 연결할 수 있기 때문에)
forest name(ForName)을 foreign key로 만들어서 사용함
(Manager table도 마찬가지로 ForName을 foreign key로 사용함)
5. M:M는 별도의 테이블로 만들 연결시킴(River, Facility)
supplies water to(물의양)은 별도의 표를 만들어서
FacName, River Name의를 primary key로 함(밑줄)
관계형 모델에서 속성 domain 표현의 한계점
polygon id에 대한 table 내용
id | seq_no | Point_id |
77 | 1 | a |
77 | 2 | d |
77 | 3 | b |
77 | 4 | c |
>> 결론: spatial object는 ER diagram으로 표현하기 어려움
>> Extending ER with Spatial Concepts : 확장버전으로 사용
Extending ER with Spatial Concepts: ER모델의 확장판
라인이라는 뜻
polygon이라는 뜻
위의 표시 처럼 기존 ER관계도에서 special 속성 더 간단히 나타낼 수 있음
'IT > 공간정보처리시스템' 카테고리의 다른 글
z-ordering Tree (0) | 2022.10.13 |
---|---|
1005 Spatial Access Methods 3 - The Linear Quadtree (1) | 2022.10.05 |
Spatial Access Methods 1 - Space-Driven Structure (3) | 2022.10.01 |
Spatial DB system 0921 (1) | 2022.09.28 |
Spatial Data Processing System (0) | 2022.09.07 |