LEE CHANWOO

📝 Blog 2024 version 1.6.1
🔖 NOV 1, 2024

4 분 소요

Database System

Data Modeling

Data Modeling

  • 컴퓨터에 저장할 데이터의 구조를 논리적으로 표현하기 위한 행위
  • 주어진 개념으로부터 논리적인 데이터 모델을 구성하는 작업을 말하며, 일반적으로 이를 물리적인 데이터베이스 모델로 환원하여 고객의 요구에 따라 특정 정보 시스템의 데이터베이스에 반영하는 작업을 포함한다
  • DB구조 기반으로 데이터, 데이터 관계, 데이터 의미, 데이터 제약 등을 기술하기 위한 개념적 표현 방법
  • 시스템의 대상이 되는 업무를 분석하여 정보시스템으로 구성하는 과정에서 업무의 내용과 정보시스템의 모습을 적절한 표기법으로 표현하는 것

즉, 추상적인 데이터베이스 구조를 가시적으로 구현화(형태화)시키는 것으로,
데이터베이스 설계 시 어려움을 도와주는 등의 역할을 한다

Data Modeling의 특징

  • Leverage(파급력): 계속 변화되는 데이터들을 변경하는 데 용이하다 → 유지보수의 이점이 있다
  • Conciseness(간결한 표현): 설계도면처럼, 가시적인 Diagram으로 표현하여 복잡한 유저들의 요구를 쉽게, 직관적으로 이해할 수 있다
  • Data Quality(품질): 데이터들의 중복, 비유연성, 비일관성 등 기존 file system의 단점들을 극복할 수 있다

데이터 모델링의 3단계

📌 개념적 데이터 모델, 논리적 데이터 모델, 물리적 데이터 모델

  • 1. 개념적 데이터 모델링
    • 업무중심적이며 포괄적인, 추상적 모델링
  • 2. 논리적 데이터 모델링
    • 구축하고자 하는 업무에 대해 Key, Attribute, Relation 등을 정확하게 표현 (재사용성 높음)
  • 3. 물리적 데이터 모델링
    • 실제로 DB에 이식할 수 있도록 성능, 저장 등 물리적인 성격까지 고려하여 설계

💡
아래로 내려올수록 구체적이며 위에 있을수록 추상적이다

Relational Data Model

Relation

  • Data를 담은 2차원 Table, Row(행)과 Column(열)로 이루어 진다
  • 릴레이션의 특징
    • 릴레이션의 튜플들은 모두 다르며, 유일한 존재
    • 릴레이션의 튜플들 간의 순서는 의미가 X
    • 릴레이션의 속성들 간의 순서는 의미가 X
    • 튜플들의 삽입, 갱신, 삭제작업이 실시간으로 일어나므로 릴레이션은 수시로 변함
    • 속성은 더이상 분해할 수 없는 원자값만 가짐

Relational Data Model - RDM

  • Relation을 이용한 Data Model
  • 데이터를 표현하는 방법 중 하나인 ‘데이터 모델’의 여러 갈래 중 하나
  • 설계의 의미보단 ‘데이터를 어떻게 표현할까’하는 개념적 의미
  • RDM의 특징
    • 단순하며 유용하다 (실제로 DB implementation)의 대부분이 RM기반)
    • SQL(Structured Query Language)이라는 high-level language를 이용하여 Relation의 Data를 원하는 대로, 쉽게 조작할 수 있다
  • 설계 측면에서는, E/R(Entity Relationship) 표기법을 기반으로 Entity(개체), Relationship(관계), Attribute(속성)들을 적절하게 RM표기법으로 변형하여 설계 할 수 있다
  • 이러한 설계 방식으로 각 Relation 간의 제약(Constraint), 함수 종속(Functional Dependency), Key 등을 명확하게 이해하고 보다 정확한 Relation을 설계할 수 있다

image

  • 구성요소
    • Attribute
      • table 맨 위에 표시되며 각 column의 이름을 명세
      • E/R Model의 entity set과 동일
    • Tuples
      • table 맨 윗줄을 제외한 나머지 행들을 각각 일컬음
      • 각 atturibute에 대해 하나의 구성요소를 가짐
      • 괄호와 쉼표를 사용하여 표기한다
      • ex) Star Wars, 1977, 124, color
    • Instance
      • relation의 주어진 모든 tuple들의 집합을 칭함
    • Component
      • table의 한 ‘칸’을 의미
  • Schemas
    • Data Model에 대해 이야기할 때 항상 ‘Schema(스키마)’를 언급한다
    • Schema란, DB를 구성하는 레코드의 크기, 키(key), 레코드들의 관계(relationship), 검색방법 등 ‘자료를 저장하는 구조와 표현법을 정의한 것’이라고 칭할 수 있다
    • relation 이름 뒤에 괄호로 묶어 표기하며 (예: Movies(title, year, length, filmType)) Relational database schema (혹은 그냥 Database schema)라고 한다

💡
여기서 attributes들은 list등의 레코드가 아니라 set이다


  • 용어
    • 필드(Field): 어떤 의미를 지니는 정보의 한 조각으로, DB 시스템에서 처리의 최소 단위를 뜻함
    • 레코드(Record): 정보를 처리하는 기본적인 단위로, 필드(혹은 다른 items)의 모임을 뜻함
    • 도메인(Domain): 필드 값에 주어지는 값의 유효한 범위(어떠한 조건을 만족하는 범위)를 정해줌 수학에서는 정의역


💡
각 component 값들은 structure, set, list 등의 record 타입이 아닌, atomic해야 한다
또한 같은 column에 존재하는 component 값들 모두 같은 타입(이거나 정해진 값 중 하나)이어야 한다

image

  • Relation은 tuple들의 set이기 때문에 제시된 tuple들의 ‘순서’는 중요하지 않다
  • 즉, tuple들의 순서가 바뀌어도 동일한 Relation으로 본다
  • 더 나아가 attribute들의 순서 역시 재배치할 수 있다
  • 하지만 데이터가 섞이거나 변경되는 일 없이 재배치해야 한다
  • 결과적으로 각각의 tuple은 attribute 순서대로 정렬된다
  • 그러므로 그림과 같은 두 개의 Relation은 완전히 ‘같다’라고 할 수 있다

💡
스키미와 인스턴스의 구별은 확실히 해야한다
스키마는 Relation의 attribute와 name이며 대개 ‘변하지 않는다’
반면, 인스턴스는 tuple의 집합으로 값이 바로바로 변한다
디자인 시 인스턴스는 고려하지 않는다
다만, 어떤 구조로 설계할 지만 고려하면된다

Functional Dependencies

  • Constraint
    • E/R design을 Relational schema로 컨버팅 시 Application의 요구에만 Relational schema를 제공하면 큰 위험이 따를 수 있다
    • 또한 별개로 빈번히 특정 제약(Constrain)에 얽매일 수 밖에 없다
    • 이때 생기는 제약들 중 가장 중요한 것은 ‘Functional dependency’(이하 FD)라고 불리는 unique-value 제약이다
    • 이제약은 중복을 제거하는 Database redesign에 있어 아주 위험할 수 있다
    • 이 밖에도 도메인 제약조건(Domain constraint), 참조 무결성(Referential integrity) 등이 있다
    • 종류
      • 도메인 제약 조건(Domain constraint): 각 component들이 Data type/size 등 도메인에 위배되는지에 대한 제약조건
      • 엔티티 무결성 제약조건(Entity integrity constraint): Entity의 기본 키(Primary key)를 구성하는 어떤 열도 NULL 값을 포함할 수 없다는 것에 대한 제약조건
      • 참조 무결성 제약조건(Referential integrity constrain): 외래 키(Foreign key)의 값은 참조된 relation의 기본 키 값들 중 하나와 같다는 제약조건

💡
널 값(null value)은 공백, 0, 길이가 0인 문자열들과는 다른 말 그대로의 아직 입력되지 않은 데이터를 의미한다
한 개의 Relation으로 모든 데이터를 표현할 수 있다는 이론상으로 좋아보이지만
쿼리 및 갱신이 복잡해지며 제약 조건을 위배할 수 있다는 문제점도 따른다
따라서, 일반적으로 NULL 값은 허용하지 않는 것이 좋다


  • Functional dependency
    • Relation R의 두 튜플 T1, T2에 대해 n개의 attribute(A1, A2, …, An)값이 같다면 T1, T2의 m개의 attribute(B1, B2, …, Bn)도 반드시 같은 값이다
    • 즉, An이 결정되면 그 값에 따른 Bn도 단 하나의 값으로 결정된다
      • 표기: A1A2…An -> B1B2…Bn

image

💡
Functional dependency의 ‘Functional’이란?
마치 정의역의 한 값을 대입하면 그에 해당하는 치역이 단 한개만 나온다는 수학의 ‘function’과 같기 때문

Key

  • Key
    • Relation 내 다른 모든 attributes를 unique하게 결정하는(hold, identify) attribute(s)이다 → 즉 , 두개의 distinct한 tuple의 모든 attribute값들은 각각 다 다른값이다
    • Key 외엔 다른 attribute를 unique하게 결정하는 다른 부분집합이 없어야 한다 → 즉, key는 minimal해야 한다(key가 하나의 attribute A를 포함하면, A를 key라고 한다)
  • Primary key
    • 여러 key 중 user가 지정한 key를 일컫는다
    • Implementation issue가 될 수 있기 때문에 underline으로 명확하게 표시함
  • Superkeys(Superset of key)
    • Key의 제약이 걸려있는 attribute(들)
    • Key는 모두 Superkey이지만, Superkey이면 Key는 아니다 (minimal의 조건)
  • Foreign key
    • 다른 Relation의 Primary의 Primary key attribute를 참조하는 key로, 참조 무결성 제약조건과 더불어 두 Relation들의 일관성을 유지하는 데 사용한다
    • 또한 외래 키는 일종의 ‘key’ 개념이라고 보기엔 다소 무리가 있다

💡
Superkey 중 최소의 Key(s)를
후보키(candidate Key)라고 따로 정의하기도 한다

댓글남기기

참고