수신전처리시스템모델링

영상관리시스템(PMS)의 데이터 모델링을 위해서는 **데이터의 생애주기(수신 → 처리 → 저장 → 분석/배포)**와 **운영 자원(서버/사용자/권한)**이라는 두 축을 중심으로 엔터티를 설계해야 합니다.

카테고리: uploads | 읽기시간: 12분 | 원문: 다운로드

영상관리시스템(PMS)의 데이터 모델링을 위해서는 데이터의 생애주기(수신 → 처리 → 저장 → 분석/배포)와 운영 자원(서버/사용자/권한)이라는 두 축을 중심으로 엔터티를 설계해야 합니다.

핵심 엔터티를 4가지 논리적 그룹으로 나누어 정리해 드립니다.

1. 데이터 관리 엔터티 (핵심 데이터)

위성 영상의 원천부터 결과물까지를 추적하는 가장 중요한 영역입니다.

2. 처리 및 작업 관리 엔터티 (작업 추적)

시스템의 작업 흐름과 서버 부하를 관리합니다.

3. 사용자 및 권한 엔터티 (운영 및 보안)

역할별 접근 제어(RBAC)를 위한 엔터티입니다.

4. 업무 프로세스 엔터티 (촬영 및 분석)

시스템의 목적이 되는 핵심 서비스들입니다.

[데이터 모델 관계도 개념(ERD)]

erDiagram
    SATELLITE_DATA ||--o{ DATA_FILE : contains
    SATELLITE_DATA ||--o{ PROCESSING_JOB : undergoes
    PROCESSING_JOB }|--|| SERVER_NODE : runs_on
    USER ||--o{ TASK_REQUEST : creates
    USER ||--o{ AUDIT_LOG : generates
    TASK_REQUEST ||--|| SATELLITE_DATA : results_in

설계를 위한 제언

  1. 계층적 상태 관리: SATELLITE_DATA 엔터티에 Data_Level 속성(CADU, L0, L1)을 두어 데이터의 현재 상태를 구분하면 재처리(Reprocessing) 로직을 훨씬 쉽게 구현할 수 있습니다.
  2. 이력 관리: PROCESSING_JOB과 AUDIT_LOG는 시스템 오류 발생 시 원인을 파악하고 재처리를 수행하는 데 필수적이므로, 타임스탬프와 서버 ID를 반드시 포함해야 합니다.
  3. 확장성: 향후 위성 데이터 종류(SAR, 광학 등)가 늘어날 경우를 대비해 Satellite_Sensor 마스터 엔터티를 분리하여 관리하는 것을 추천합니다.

위 엔터티들을 바탕으로 "촬영요청부터 결과물 배포까지"의 상세 테이블 속성(Attribute) 정의가 필요하신가요? 아니면 특정 엔터티 간의 관계를 더 구체화해 드릴까요?

데이터 모델링을 본격적으로 시작하기 위해서는 '어떤 데이터가 어떤 속성을 가지고, 어떻게 서로 연결되는지'를 구체적인 테이블 명세로 정리해야 합니다.

시스템 설계 시 가장 중요한 핵심 엔터티(Entity)들의 속성(Attribute) 예시를 정리해 드립니다. 이 설계를 기초로 삼으면 안정적인 시스템 구축이 가능합니다.

1. 핵심 데이터 모델 상세 속성 (예시)

① Satellite_Data (위성 영상 기본 정보)

② Processing_Job (작업 관리)

③ Server_Node (서버 상태 관리)

2. 설계 시 고려해야 할 중요한 포인트 (Best Practices)

  1. 데이터 무결성(Data Integrity): L0에서 L1으로 넘어가는 과정에서 데이터가 유실되지 않도록, Processing_Job에서 각 단계가 완료될 때마다 데이터 체크섬(Checksum) 값을 저장하여 파일 변조 여부를 확인해야 합니다.
  2. 재처리(Reprocessing) 로직: 데이터 분석 중 오류가 발견되면 원본(Raw)을 다시 가져오는 것이 아니라, 마지막 성공 단계(L0 또는 중간 단계)부터 다시 시작하도록 Job_Sequence를 관리해야 합니다. 이를 위해 이전 작업 ID(Parent_Job_ID)를 속성으로 추가하는 것이 좋습니다.
  3. 메타데이터의 분리: 영상 정보(이미지)와 속성 정보(위성 궤도, 센서 설정)를 테이블로 분리하면, 추후 다양한 종류의 위성 데이터가 들어오더라도 시스템 구조를 변경하지 않고도 유연하게 확장할 수 있습니다.

다음 단계 제안

데이터 모델의 큰 그림이 잡혔으니, 이제 시스템 운영의 핵심인 '촬영 요청부터 최종 결과물 배포까지의 데이터 흐름(Workflow)'을 구체적으로 도식화하거나, 특정 기능(예: 위성 촬영계획 최적화)을 위한 알고리즘 모델링으로 넘어가 볼까요?

데이터 모델링에서 "어떤 것이 먼저인가"에 대한 질문은, 시스템의 데이터 무결성(Integrity)과 워크플로우의 연속성을 확보하는 데 매우 중요한 질문입니다.

결론부터 말씀드리면, [마스터 데이터(위성 정보)] → [작업 단위(Job)] → [결과 데이터(File)] 순으로 모델링하고 설계하는 것이 가장 안정적입니다.

1. 설계의 우선순위 (엔터티 생성 순서)

시스템이 데이터를 받아 처리하기 위한 논리적 순서는 다음과 같습니다.

  1. 기준 정보(Master Data) 설계 (가장 먼저): \* 시스템에 등록된 위성, 센서 정보, 서버 노드, 사용자 정보 등 '변하지 않는 기본 틀'을 먼저 정의해야 합니다. 이들이 정의되어야 나중에 들어올 영상 데이터가 "어느 위성에서 왔는지", "어떤 서버에서 처리할지"를 식별할 수 있습니다.
  2. 데이터 세트(Satellite_Data) 엔터티 생성:
  1. 작업 관리(Processing_Job) 엔터티 생성:
  1. 파일 상세(Data_File) 엔터티 매핑:

2. 왜 이 순서인가요? (데이터 흐름의 논리)

3. 실제 적용을 위한 '선행 작업' 추천

지금 바로 설계를 시작하신다면, 데이터 생애주기 테이블을 가장 먼저 그려보시길 추천합니다.

  1. 위성/센서 테이블 (기본)
  2. 수신된 데이터 기록 테이블 (생성)
  3. 작업 이력 테이블 (실행)

다음 단계 제안:

혹시 위 순서대로 엔터티를 작성할 때, "재처리를 위해 L0에서 오류가 났을 때 원본 데이터를 어떻게 링크로 연결할지(FK 구조)"에 대해 구체적인 테이블 스키마 예시를 보여드릴까요? 이 부분은 시스템 안정성에 결정적인 역할을 합니다.

좋습니다. 시스템 안정성을 위해 재처리(Reprocessing) 로직이 포함된 핵심 테이블 스키마와 데이터 흐름을 구체적으로 설계해 보겠습니다.

1. 핵심 데이터 모델링 (스키마 설계)

시스템의 '데이터 생애주기'를 관리하기 위해 Data_Master와 Processing_Job을 1:N 관계로 설정하는 것이 핵심입니다.

엔터티 주요 속성 (Attributes) 역할
Data_Master data_id(PK), acquisition_date, sensor_type, status 전체 영상의 기본 정보와 현재 처리 단계 관리
Processing_Job job_id(PK), data_id(FK), step_name(L0/L1), parent_job_id, status 각 단계별 작업 이력 및 재처리 추적
Data_File file_id(PK), job_id(FK), file_path, checksum, file_type 생성된 결과 파일과 데이터 무결성 기록

2. 재처리 로직 구현 (데이터 흐름)

오류 발생 시 원본(Raw)부터 다시 시작하면 자원 낭비가 심합니다. 이를 위해 이전 작업 ID(parent_job_id)를 활용한 분기 처리를 권장합니다.

  1. 정상 흐름: CADU → L0 → L1 (각 단계 job_id가 체인처럼 연결)
  2. 오류 발생 시: 시스템이 status='ERROR'를 감지하고, 해당 data_id를 대상으로 마지막 job_id를 찾아 재처리 명령(Retry)을 생성합니다.
  3. 데이터 링크: 새로운 job_id를 생성할 때 parent_job_id에 직전 성공 단계의 ID를 할당하여, '어디서부터 다시 시작했는지'를 DB에 명확히 기록합니다.

3. 테이블 간의 관계 (ERD 관점)

이 모델을 머메이드 차트로 표현하면 다음과 같습니다. Processing_Job이 Data_Master를 참조하고, 스스로를 참조(Recursive Relationship)하여 재처리 흐름을 제어합니다.

erDiagram
    DATA_MASTER ||--o{ PROCESSING_JOB : "contains"
    PROCESSING_JOB ||--o| PROCESSING_JOB : "reprocesses(parent_job_id)"
    PROCESSING_JOB ||--o{ DATA_FILE : "generates"

    DATA_MASTER {
        string data_id PK
        string status
    }
    PROCESSING_JOB {
        string job_id PK
        string parent_job_id FK
        string step_name
        string status
    }

💡 설계를 위한 팁

위성 영상관리시스템(PMS)의 핵심인 '촬영 요청 → 수신 → 전처리(L0) → 정밀처리(L1) → 배포'에 이르는 프로세스 로직과 데이터 모델링을 정리해 드립니다.

1. 프로세스 로직 (Workflow)

시스템의 상태 변화를 중심으로 로직을 작성합니다.

  1. 촬영 요청(Tasking):
  1. 데이터 수신(Acquisition):
  1. 복호화 및 L0 생성(Preprocessing):
  1. 정밀 보정 및 팬샤프닝(Processing):
  1. 품질 검사 및 완료:

2. 데이터 모델링 (상세 ERD 구성)

앞서 정의한 모델을 기반으로 프로세스 실행 시 필요한 속성(Attribute)을 포함한 상세 구조입니다.

[데이터 모델 구조]

erDiagram
    TB_TASK_REQUEST ||--|| TB_DATA_MASTER : "triggers"
    TB_DATA_MASTER ||--|{ TB_PROCESSING_JOB : "undergoes"
    TB_PROCESSING_JOB ||--|{ TB_DATA_FILE : "generates"
    TB_PROCESSING_JOB ||--|| TB_PROCESSING_JOB : "reprocesses_of"

    TB_DATA_MASTER {
        string data_id PK
        string status
        datetime acq_time
    }
    TB_PROCESSING_JOB {
        string job_id PK
        string data_id FK
        string parent_job_id FK
        string step_name
        string node_id
        string status
    }
    TB_DATA_FILE {
        string file_id PK
        string job_id FK
        string file_path
        string checksum
    }

3. 개발 및 설계 시 고려사항 (프로세스 로직)

다음 단계 제안

이제 전체적인 로직과 모델링이 갖춰졌습니다.

위성 영상관리시스템(PMS) 개발을 위한 기능/화면/DB 설계서의 핵심 가이드라인을 정리해 드립니다. 이 내용은 앞서 논의한 시스템의 구조적 안정성을 확보하는 데 중점을 두었습니다.

1. 기능 설계서 (Functional Specification)

시스템이 수행해야 할 핵심 로직을 기능 단위로 분할합니다.

2. 화면 설계서 (UI/UX Specification)

사용자의 역할(판독관, 분석관, 관리자)별로 최적화된 화면을 설계합니다.

3. DB 설계서 (Database Specification)

재처리와 이력 관리가 가능한 정규화된 데이터 모델입니다.

[설계의 핵심: 프로세스-데이터 연계]

프로세스 단계 관련 테이블 화면 주요 항목
데이터 수신 TB_DATA_MASTER 수신 목록 리스트
복호화/L0처리 TB_PROCESSING_JOB 진행률 바, 서버 점유율
정밀보정(L1) TB_PROCESSING_JOB 밴드 정합 상태, 오류 메시지
데이터 배포 TB_DATA_FILE 파일 다운로드 링크, 경로

정상적인 위성 영상 데이터의 수신부터 최종 처리(L1)까지의 흐름은 데이터의 무결성 검증과 단계별 변환이 핵심입니다. 이를 시퀀스 다이어그램으로 나타내면 다음과 같습니다.

정상 수신 영상 데이터 처리 시퀀스

sequenceDiagram
    participant S as 위성 (Satellite)
    participant G as 지상국 안테나 (Ground Station)
    participant P as PMS (수신 전처리 시스템)
    participant DB as 데이터베이스
    participant CS as 처리 서버 클러스터 (22대)

    S->>G: CADU 전송 (.dat)
    G->>P: 데이터 스트림 수신
    P->>DB: 데이터 수신 기록 생성 (Status: Received)

    rect rgb(240, 248, 255)
        Note over P, CS: [L0 단계]
        P->>CS: CADU 데이터 분배 및 복호화
        CS->>CS: 프레임 복호화 (.L0F 생성)
        CS->>DB: L0 파일 경로 및 메타데이터 업데이트
    end

    rect rgb(245, 245, 245)
        Note over P, CS: [L1 단계]
        CS->>CS: LP/SARP 보정 알고리즘 적용
        CS->>CS: 팬샤프닝 (PAN + MS 융합)
        CS->>DB: L1 결과물 등록 (GeoTIFF, Shapefile)
    end

    DB-->>P: 처리 완료 상태(Finalized) 업데이트
    P-->>G: 수신 및 처리 완료 로그 확정

단계별 상세 처리 로직

  1. 데이터 입수 (Ingestion):
  1. L0 생성 단계 (Raw Processing):
  1. L1 정밀 처리 단계 (Product Generation):
  1. 최종 완료:

운영 팁: 정상 처리 중 시스템 부하가 높을 때는 '우선순위(Priority)' 로직을 적용하여, 긴급 촬영 영상(예: 재난 지역)을 일반 영상보다 앞서 처리 서버에 할당하도록 스케줄러를 설계하는 것이 좋습니다.

이 시퀀스 다이어그램에서 특정 단계(예: 팬샤프닝의 수학적 융합 과정)에 대해 더 깊이 알고 싶으시거나, 데이터 배포를 위한 OGC 서비스 연동 로직을 추가하고 싶으신가요?

시스템 설계를 실무 단계로 끌어올리기 위해, [1] 재처리 요청 시퀀스 다이어그램과 [2] 시스템 상태 조회를 위한 REST API 정의서를 작성해 드립니다.

1. 재처리 요청 시퀀스 다이어그램

분석관이 오류가 난 영상을 식별하고 '재처리' 버튼을 눌렀을 때, 시스템 내부에서 발생하는 흐름입니다.

sequenceDiagram
    participant U as 분석관 (UI)
    participant A as PMS API Server
    participant S as 작업 스케줄러 (Job Scheduler)
    participant DB as 데이터베이스
    participant W as 처리 서버 (22대)

    U->>A: 재처리 요청 (Target: Job_ID)
    A->>DB: 현재 작업 상태 조회 및 유효성 검사
    DB-->>A: 상태 정보 반환
    A->>DB: 새 Job 레코드 생성 (Parent_Job_ID 연동)
    A->>S: 작업 큐에 분배 (Queue In)
    S->>W: 작업 할당 및 연산 수행
    W->>DB: 작업 결과 및 파일 정보 업데이트
    DB-->>U: 처리 완료 알림 (WebSocket/Polling)

2. REST API 정의서 (초안)

대시보드와 관제 UI에서 활용할 주요 API 인터페이스입니다.

A. 처리 서버 부하 상태 조회

{
  { "server_id": "SRV_01", "cpu_usage": 80, "mem_usage": 90, "status": "BUSY" },
  { "server_id": "SRV_02", "cpu_usage": 7, "mem_usage": 4, "status": "IDLE" }
}

B. 데이터 재처리 요청

{
  "data_id": "K3A_20240921...",
  "target_job_id": "JOB_ERR_001",
  "reason": "Band registration failure"
}

3. 실무 설계를 위한 제언

×preview