테이블, 튜플, 속성, 도메인
관계형 데이터베이스를 이해할 때 가장 먼저 정확히 붙잡아야 할 네 가지 언어가 있습니다. 테이블은 무엇을 담는 그릇인지, 튜플은 어떤 기록을 가리키는지, 속성은 어떤 항목을 뜻하는지, 도메인은 왜 값의 질서를 지키는지 차근차근 정리해 보겠습니다.
Intro
데이터베이스를 처음 공부하실 때 가장 자주 마주치는 어려움 가운데 하나는 용어가 비슷해 보인다는 점입니다. 화면에 보이는 것은 대체로 표처럼 생겼기 때문에 많은 분들이 “행과 열이 있으면 다 같은 구조 아닌가요?”라고 생각하십니다. 그런데 데이터베이스에서는 눈에 보이는 모양보다 훨씬 더 중요한 약속이 함께 작동합니다. 같은 표처럼 보여도 어떤 값이 들어와야 하는지, 어떤 항목이 어떤 의미를 갖는지, 한 줄의 기록이 무엇을 대표하는지, 값의 범위를 어디까지 허용할지를 미리 정해 두지 않으면 저장된 정보는 곧바로 혼란스러워집니다. 그래서 관계형 데이터베이스는 표를 닮은 모양을 빌리되, 그 안에 매우 엄격한 구조적 질서를 심어 둡니다. 오늘 다루는 테이블, 튜플, 속성, 도메인은 바로 그 질서를 읽어 내는 첫 번째 언어입니다.
이 네 가지 개념을 제대로 이해하지 못하면 뒤에서 배우는 내용이 자꾸 흐릿해집니다. 예를 들어 기본키를 설명할 때 “어느 속성이 튜플을 구별하는가”라는 말이 등장하고, 정규화를 설명할 때는 “속성 사이의 함수 종속”이라는 표현이 나오며, SQL을 배울 때는 “테이블에서 특정 속성을 조회한다”라는 문장을 자연스럽게 읽어야 합니다. 또 데이터 무결성을 설명할 때는 도메인이 허용하는 값과 실제 입력값이 맞는지 따져야 합니다. 말하자면 오늘의 내용은 앞단에서 잠깐 배우고 지나가는 기초가 아니라, 관계형 데이터베이스 전반을 지탱하는 바닥 구조라고 보시면 좋습니다. 기초가 흔들리면 뒤에서 아무리 많은 개념을 외워도 머릿속에서 서로 연결되지 않습니다. 반대로 이 네 개념이 선명하게 정리되면 이후 학습이 아주 편안해집니다.
이번 글에서는 먼저 테이블과 튜플, 속성과 도메인이 각각 무엇을 뜻하는지 학문적으로 정확하게 설명드리겠습니다. 그다음에는 왜 이 개념들이 필요한지, 실제 쇼핑몰·학사관리·병원예약 시스템에서 어떻게 쓰이는지 사례와 함께 살펴보겠습니다. 이어서 초보자가 가장 자주 헷갈리는 지점도 짚어 보겠습니다. 열과 속성은 같은 말인지, 행과 튜플은 언제 같고 언제 다르게 써야 하는지, 자료형과 도메인은 어떤 관계인지도 차분히 정리하겠습니다. 마지막에는 다음 단계 학습인 릴레이션, 스키마, 키 개념으로 자연스럽게 넘어갈 수 있도록 연결 고리까지 잡아 드리겠습니다.
핵심 요약 1
테이블은 관련된 데이터를 구조적으로 모아 두는 논리적 저장 단위이며, 우리가 흔히 보는 표의 형태로 이해하면 좋습니다.
핵심 요약 2
튜플은 테이블 안의 한 행이 표현하는 하나의 개별 기록입니다. 회원 한 명, 주문 한 건, 수강 신청 한 건이 모두 튜플이 될 수 있습니다.
핵심 요약 3
속성은 데이터를 설명하는 항목이고, 도메인은 그 속성에 들어갈 수 있는 값의 범위와 규칙을 정해 데이터 품질을 지키는 기준입니다.
1. 테이블은 데이터를 담는 판이 아니라, 의미를 정리한 구조입니다
테이블은 관계형 데이터베이스를 설명할 때 가장 먼저 떠올리는 형태입니다. 행과 열로 구성되어 있고, 비슷한 종류의 데이터를 한데 모아 관리한다는 점에서 엑셀 표와 닮아 보입니다. 하지만 데이터베이스의 테이블은 눈으로 보기 편한 표라는 수준을 넘어서, 어떤 대상을 어떤 기준으로 기록할지를 미리 정의한 구조입니다. 예를 들어 “학생” 테이블을 만든다고 하면, 아무 정보나 적어 넣는 것이 아니라 학번, 이름, 학과, 학년, 입학일처럼 학생을 설명하는 항목을 체계적으로 설계해야 합니다. 그러고 나서 각 학생의 실제 값이 그 구조 안에 들어갑니다. 그래서 테이블은 정보가 흩어지지 않도록 질서를 부여하는 설계도에 가깝습니다.
왜 이런 구조가 중요할까요. 현실의 정보는 대부분 반복성과 공통 속성을 갖고 있기 때문입니다. 쇼핑몰 회원을 관리할 때 회원마다 이름, 연락처, 이메일, 가입일이 필요하고, 병원 예약 시스템에서는 환자번호, 예약일시, 진료과, 담당의사, 접수상태가 필요합니다. 기록 대상이 달라져도 “공통적으로 관리해야 할 항목이 있고, 그 항목별로 수많은 개별 기록이 쌓인다”는 패턴은 크게 다르지 않습니다. 테이블은 바로 그 공통 항목을 기준으로 데이터를 안정적으로 누적하는 도구입니다. 잘 설계된 테이블은 검색, 수정, 삭제, 통계, 연계 처리까지 모두 수월하게 만들어 줍니다.
학문적으로 조금 더 표현하면, 관계형 모델에서는 테이블을 릴레이션으로 이해합니다. 이를 기호로 적으면 보통 \( R(A_1, A_2, ..., A_n) \)처럼 나타냅니다. 여기서 \(R\)은 테이블 이름에 해당하고, \(A_1\)부터 \(A_n\)까지는 속성 목록입니다. 이 표현에서 벌써 중요한 사실이 드러납니다. 테이블은 행이 먼저가 아니라 속성 구조가 먼저라는 점입니다. 다시 말해 테이블은 데이터를 쌓아 두는 상자가 아니라, 어떤 성질을 가진 기록들이 모이는 공간인지를 규정하는 논리적 틀입니다.
같은 모양의 표라도 항목 정의와 값의 규칙이 없으면 데이터베이스 테이블이라고 보기 어렵습니다. 데이터베이스는 저장과 동시에 질서를 관리해야 하므로, 테이블 설계 단계에서 의미와 규칙이 함께 들어갑니다.
2. 튜플은 한 줄이 아니라, 한 대상을 대표하는 기록입니다
테이블 안에 실제 데이터가 채워지면 각 행이 생깁니다. 관계형 데이터베이스에서는 그 한 행을 튜플이라고 부릅니다. 많은 입문서에서 “튜플은 행이다”라고 설명하는데, 학습 초반에는 그렇게 이해하셔도 괜찮습니다. 다만 조금 더 정확하게 말하면 튜플은 행의 모양을 가진 하나의 완성된 기록입니다. 학생 테이블이라면 학생 한 명의 정보가 하나의 튜플이고, 주문 테이블이라면 주문 한 건의 정보가 하나의 튜플이며, 은행 거래 테이블이라면 입출금 한 건의 정보가 하나의 튜플입니다. 튜플은 데이터의 최소 설명 단위라고 보시면 이해가 쉬워집니다.
이 개념이 중요한 이유는 데이터베이스가 개별 사건과 개별 대상을 관리하기 때문입니다. 예를 들어 병원 예약 시스템에서 환자 김민지 씨가 2026년 4월 20일 오전 10시에 내과 진료를 예약했다면, 그 예약 정보 전체가 하나의 튜플입니다. 여기에는 환자번호, 예약일시, 진료과, 의사명, 상태값 등이 함께 들어갑니다. 만약 이 기록이 분리되어 있거나 일부 항목이 빠져 있다면 예약 관리가 곤란해집니다. 그래서 튜플은 “한 줄”이라는 시각적 개념보다 “하나의 업무 단위가 완결된 정보 묶음으로 저장된 상태”라고 이해하시는 편이 더 깊습니다.
또 하나 기억하실 점은 관계형 모델에서 튜플은 원칙적으로 중복되지 않아야 한다는 사실입니다. 회원 테이블에 완전히 같은 회원 기록이 두 번 들어가면 어떤 정보가 진짜인지 혼란이 생깁니다. 주문 테이블에 같은 주문번호가 두 번 저장되어도 업무 오류가 발생합니다. 그래서 튜플을 서로 구별할 수 있도록 기본키 같은 장치가 필요해집니다. 오늘은 키를 본격적으로 다루는 편이 아니지만, 튜플을 구별하는 문제가 왜 중요해지는지는 여기서 이미 시작됩니다. 튜플은 기록의 덩어리이고, 그 기록은 다른 튜플과 구별 가능해야 데이터베이스가 안정적으로 움직입니다.
학사관리 시스템을 떠올려 보셔도 좋습니다. 수강신청 테이블이 있다고 할 때 학생 A가 데이터베이스개론 과목을 신청한 기록 하나가 튜플입니다. 학생 A가 같은 과목을 실수로 두 번 신청했다면 중복 여부를 판별해야 하고, 학생 B의 신청 기록과도 분리되어야 합니다. 이처럼 튜플 개념은 현실의 개별 사건을 정보 구조 안에 정확히 대응시키는 핵심 단위입니다. 행이라는 말보다 튜플이라는 말을 익혀 두시면 데이터베이스가 표가 아니라 모델이라는 사실을 더 잘 이해하게 됩니다.
3. 속성은 무엇을 기록할지 정하는 항목이며, 도메인은 무엇이 들어올 수 있는지 정하는 규칙입니다
속성은 테이블의 열에 해당하는 개념입니다. 학생 테이블에서 학번, 이름, 학과, 생년월일, 연락처가 모두 속성입니다. 주문 테이블에서는 주문번호, 주문일자, 상품코드, 수량, 결제금액이 속성이 됩니다. 속성은 기록 대상을 설명하는 관점이자 질문의 방향입니다. “우리는 학생을 어떤 정보로 파악할 것인가”, “우리는 주문을 어떤 항목으로 관리할 것인가”라는 물음에 대한 답이 속성 설계입니다. 따라서 속성은 아무렇게나 늘릴수록 좋은 것이 아니라, 관리 목적에 맞게 정교하게 선택되어야 합니다.
속성 설계가 서툴면 데이터가 금세 지저분해집니다. 예를 들어 회원 테이블에 “회원정보”라는 속성 하나만 두고 그 안에 이름, 연락처, 주소, 가입경로를 한꺼번에 적어 버리면 검색도 어렵고 수정도 어렵습니다. 반대로 이름, 연락처, 이메일, 생년월일처럼 의미별로 분리하면 필요한 정보만 조회하거나 조건을 걸기 쉬워집니다. 데이터베이스 설계는 결국 현실을 속성 단위로 잘게 해석하는 작업이라고 할 수 있습니다. 속성이 곧 질문 가능성을 만듭니다. 어떤 속성을 두느냐에 따라 “4학년 학생만 찾기”, “이번 달 가입 회원 수 세기”, “예약 상태가 대기인 환자만 조회하기” 같은 작업이 가능해집니다.
도메인은 속성보다 한 단계 더 깊은 규칙입니다. 도메인은 특정 속성이 가질 수 있는 값의 범위와 형식을 뜻합니다. 예를 들어 학년 속성의 도메인은 1, 2, 3, 4처럼 정해진 정수 집합이 될 수 있고, 성별 속성은 남·여 또는 더 확장된 코드 체계로 정할 수 있으며, 평점 속성은 0.0부터 4.5 사이의 실수값으로 제한할 수 있습니다. 병원 예약 상태 속성이라면 “예약완료, 접수, 진료중, 수납대기, 종료, 취소”처럼 업무 흐름에 맞는 값 집합을 도메인으로 둘 수 있습니다. 이 약속이 있어야 잘못된 값이 들어오는 것을 막을 수 있습니다.
많은 초보자가 도메인을 자료형과 같은 뜻으로 이해하시는데, 둘은 완전히 같지 않습니다. 자료형은 문자형, 정수형, 날짜형처럼 기술적 형식에 더 가깝고, 도메인은 그 형식 위에 업무 의미까지 얹은 규칙입니다. 예를 들어 우편번호는 문자형일 수 있지만, 모든 문자 조합이 허용되는 것은 아닙니다. 학번도 문자형으로 저장할 수 있지만, 학교가 정한 길이와 체계가 맞아야 올바른 값입니다. 다시 말해 자료형이 “어떤 그릇인가”를 말한다면, 도메인은 “그 그릇에 무엇을 어떤 규칙으로 담을 것인가”를 말합니다. 데이터 무결성을 지키는 힘은 바로 여기서 나옵니다.
도메인을 기호로 간단히 적으면 \( dom(학년) = \{1,2,3,4\} \)처럼 표현할 수 있습니다. 또 \( dom(평점) = \{x \mid 0.0 \le x \le 4.5\} \)처럼 범위 형태로도 나타낼 수 있습니다. 이런 약속은 입력 실수를 줄이고, 시스템 간 데이터 연계를 안정화하며, 분석 결과의 신뢰도도 높여 줍니다. 결국 속성은 “무엇을 기록할 것인가”를 결정하고, 도메인은 “어떤 값이 올바른가”를 판단하는 기준을 제공합니다. 이 둘이 함께 작동해야 데이터베이스가 관리 가능한 지식 체계로 유지됩니다.
속성은 항목 이름이고, 도메인은 그 항목에 허용되는 값의 규칙입니다. “생년월일”이라는 속성을 두는 것과, 그 값이 날짜 형식이며 미래 날짜를 허용하지 않는다고 정하는 일은 서로 다른 설계 작업입니다.
4. 네 개념은 따로 외우는 용어가 아니라, 하나의 구조 안에서 함께 움직입니다
지금까지 설명한 내용을 하나로 묶어 보겠습니다. 테이블은 관련 데이터를 관리하는 구조이고, 그 안의 한 건 한 건의 기록이 튜플이며, 튜플을 구성하는 항목이 속성이고, 각 속성이 가질 수 있는 값의 범위와 형식이 도메인입니다. 이 네 개념은 따로따로 존재하지 않습니다. 오히려 하나의 데이터 구조를 다른 각도에서 설명하는 언어라고 보시는 편이 맞습니다. 학생 테이블이 있다면 학생 한 명의 정보는 튜플이고, 학번·이름·학과는 속성이며, 학과명에 허용되는 코드 체계나 학번의 자리수 규칙은 도메인에 해당합니다.
쇼핑몰 주문 시스템 사례로 연결해 보겠습니다. 주문 테이블에는 주문번호, 회원번호, 주문일시, 주문상태, 총결제금액 같은 속성이 들어갑니다. 여기서 주문번호 20260418-0001에 대한 한 건의 주문 정보는 하나의 튜플입니다. 주문상태 속성은 “결제완료, 배송준비, 배송중, 배송완료, 취소” 같은 값만 허용할 수 있습니다. 이 값 집합이 도메인입니다. 만약 누군가 주문상태 칸에 “기분좋음” 같은 값을 입력할 수 있다면 시스템은 거의 바로 무너집니다. 업무의 언어와 저장의 언어가 어긋나기 때문입니다.
공공행정 시스템에서도 마찬가지입니다. 민원 접수 테이블을 만든다고 가정해 보겠습니다. 속성으로 접수번호, 민원유형, 접수일, 처리부서, 처리상태, 완료일을 설계할 수 있습니다. 접수번호 하나에 대응하는 각 민원 건이 튜플이며, 처리상태 도메인은 “접수, 검토중, 보완요청, 처리완료, 종결” 등으로 제한될 수 있습니다. 이때 도메인 규칙이 명확해야 통계가 살아납니다. 월별 처리완료 건수, 지연 건수, 보완요청 비율 같은 행정 성과 지표는 결국 속성과 도메인이 바르게 설계되어 있을 때 신뢰할 수 있습니다.
그래서 데이터베이스 공부는 용어 암기가 목표가 아닙니다. 더 중요한 목표는 한 시스템의 정보를 어떤 구조로 표현해야 관리와 분석과 의사결정이 쉬워지는지를 이해하는 데 있습니다. 테이블, 튜플, 속성, 도메인을 바로 세우는 일은 데이터의 질서와 업무의 질서를 맞물리게 하는 출발점입니다. 이 바탕이 갖추어져야 다음 단계인 릴레이션의 의미, 스키마와 인스턴스, 기본키와 외래키, 정규화 같은 내용도 자연스럽게 연결됩니다.
5. 초보자가 자주 헷갈리는 부분을 한 번에 정리해 보겠습니다
첫째, 열과 속성은 비슷하게 쓰이지만 맥락이 다릅니다. 화면에서 보이는 형태를 말할 때는 열이라고 해도 무리가 없지만, 데이터 모델의 언어로 설명할 때는 속성이라는 표현이 더 정확합니다. 속성이라는 말에는 “이 항목이 어떤 의미를 가지는가”라는 설계 관점이 들어 있기 때문입니다. 데이터베이스 이론을 배울수록 열보다 속성이라는 용어를 더 자주 만나게 됩니다.
둘째, 행과 튜플도 비슷해 보이지만 완전히 같은 느낌은 아닙니다. 행은 화면상의 배열에 가깝고, 튜플은 의미적으로 완결된 기록에 가깝습니다. 실무에서 둘을 크게 구분하지 않고 말하는 경우도 많지만, 이론적 설명이나 설계 문서에서는 튜플이라는 표현이 더 정밀합니다. 데이터베이스를 깊이 있게 공부하실수록 “보이는 모양”보다 “논리적 의미”를 담는 용어가 중요해집니다.
셋째, 자료형과 도메인은 같은 개념이 아닙니다. 자료형이 정수형인지 문자형인지 정하는 일은 기술적인 기초 설정이고, 도메인은 그 자료형 위에 업무 규칙을 얹는 일입니다. 주민등록번호가 문자형으로 저장될 수 있다는 사실만으로는 충분하지 않습니다. 자리수, 형식, 허용 여부, 마스킹 규칙, 저장 정책까지 고려해야 실제 업무에서 쓸 수 있는 설계가 됩니다. 데이터베이스가 현장과 만나는 지점은 늘 도메인 규칙에서 드러납니다.
넷째, 속성은 많다고 좋은 것이 아닙니다. 반대로 너무 적어도 문제가 생깁니다. 관리 목적을 반영하지 못하면 나중에 분석이 불가능하고, 지나치게 세세하면 입력 부담과 유지 비용이 커집니다. 좋은 설계는 필요한 정보만 빠짐없이 담되, 중복과 혼란을 줄이는 방향으로 이루어집니다. 그 균형 감각이 바로 데이터베이스 설계 역량입니다.
위 표를 보시면 네 개념의 차이가 한눈에 들어옵니다. 테이블과 튜플은 데이터의 덩어리 수준을 설명하고, 속성과 도메인은 그 덩어리를 구성하는 항목과 규칙을 설명합니다. 초보자 입장에서는 화면에 드러나는 테이블, 행, 열만 먼저 보이기 쉽습니다. 하지만 데이터베이스를 정확하게 이해하려면 눈에 잘 드러나지 않는 도메인까지 함께 살펴야 합니다. 설계의 품질은 대개 겉모양이 아니라 보이지 않는 규칙에서 갈립니다.
실무 체크포인트
- 테이블을 만들기 전, “무엇을 관리할 것인가”보다 “어떤 속성으로 구별하고 설명할 것인가”를 먼저 정리해 보십시오.
- 속성을 정한 뒤에는 각 속성의 도메인을 문서로 남겨 두는 습관이 중요합니다. 코드값, 허용 범위, 필수 여부까지 함께 기록하면 협업 품질이 좋아집니다.
- 튜플 단위가 업무 단위와 일치하는지 점검해 보십시오. 주문 한 건, 예약 한 건, 민원 한 건처럼 현실의 사건과 저장 단위가 어긋나면 데이터 품질 문제가 자주 생깁니다.
- 엑셀 표를 데이터베이스처럼 쓰고 있다면, 각 열이 वास्तव में 어떤 속성인지, 허용값 규칙이 있는지부터 다시 점검하시는 것이 좋습니다.
기억해 둘 점
테이블은 구조이고, 튜플은 기록이며, 속성은 항목이고, 도메인은 규칙입니다.
데이터베이스는 표처럼 보이지만, 실제 핵심은 보이지 않는 설계 원칙에 있습니다.
도메인을 가볍게 여기면 입력 오류, 분석 왜곡, 시스템 간 불일치가 뒤따르기 쉽습니다.
용어사전
테이블(Table) : 같은 성격의 데이터를 일정한 속성 구조로 모아 둔 논리적 저장 단위입니다.
튜플(Tuple) : 테이블 안에서 하나의 개체나 사건을 대표하는 개별 기록입니다.
속성(Attribute) : 튜플을 설명하기 위해 사용하는 항목 이름입니다.
도메인(Domain) : 특정 속성에 입력될 수 있는 값의 범위, 형식, 규칙을 뜻합니다.
FAQ
Q1. 테이블과 릴레이션은 같은 뜻인가요?
학습 초반에는 거의 비슷하게 이해하셔도 괜찮습니다. 다만 릴레이션은 관계형 모델의 이론적 표현이고, 테이블은 실무와 화면에서 더 자주 쓰는 말입니다.
Q2. 행과 튜플을 구분해서 외워야 하나요?
실무 대화에서는 섞어 쓰는 경우가 많습니다. 그래도 이론을 공부할 때는 튜플이 “하나의 완결된 기록”이라는 뜻을 담고 있다는 점을 기억해 두시면 좋습니다.
Q3. 도메인은 왜 중요한가요?
허용되지 않은 값이 들어오면 조회, 통계, 연계, 검증이 모두 흔들리기 때문입니다. 도메인은 데이터 품질과 무결성을 지키는 첫 번째 안전장치입니다.
Q4. 엑셀에도 속성과 도메인 개념을 적용할 수 있나요?
충분히 적용할 수 있습니다. 열 이름을 의미 있게 설계하고, 드롭다운 목록이나 입력 규칙을 걸어 두면 데이터베이스 설계의 기본 감각을 익히는 데 큰 도움이 됩니다.
참고자료 성격의 안내
관계형 데이터베이스의 기본 개념을 더 깊이 공부하고 싶으시다면 데이터베이스 개론서에서 관계형 모델, 릴레이션, 속성, 무결성 제약 부분을 함께 읽어 보시는 것이 좋습니다.
특히 C. J. Date 계열의 관계형 데이터베이스 설명, Abraham Silberschatz 등의 데이터베이스 시스템 개론서, 국내 대학 데이터베이스 개론 교재를 함께 비교해 보시면 용어의 맥락이 더 선명해집니다.
실습을 병행하실 때는 학생관리, 도서대출, 주문관리처럼 익숙한 주제로 직접 테이블과 속성, 도메인을 설계해 보는 연습이 가장 효과적입니다.
오늘 살펴본 테이블, 튜플, 속성, 도메인은 관계형 데이터베이스의 가장 작은 출발선이면서도 가장 오래 남는 기초입니다. 겉으로 보면 네 단어를 구분하는 일처럼 보이지만, 실제로는 데이터베이스를 바라보는 관점을 바꾸는 공부라고 할 수 있습니다. 표처럼 생긴 화면을 보는 눈에서 멈추지 않고, 그 안에 어떤 구조가 있고 어떤 규칙이 있으며 어떤 기록 단위가 움직이는지를 읽어 내는 눈으로 넘어가야 비로소 데이터베이스를 이해했다고 말할 수 있습니다. 공부가 깊어질수록 복잡한 SQL 문장이나 정규화 규칙보다 먼저 떠올라야 하는 것이 바로 오늘의 네 개념입니다.
특히 도메인 개념은 입문 단계에서 가볍게 지나가기 쉽지만, 실무에 가까워질수록 그 중요성이 더 크게 다가옵니다. 데이터 오류의 상당수는 거창한 기술 문제가 아니라 잘못된 값이 들어온 데서 시작됩니다. 반대로 구조와 규칙이 잘 잡힌 데이터는 검색도 빠르고, 분석도 정확하며, 시스템 간 연계도 안정적입니다. 그래서 좋은 데이터베이스는 데이터를 많이 담는 시스템이 아니라, 의미 있는 데이터가 올바른 규칙 속에 머무를 수 있도록 설계된 시스템이라고 말할 수 있습니다. 오늘의 네 개념은 바로 그 설계 감각의 첫 문입니다.
다음 단계에서는 이 기초를 바탕으로 릴레이션의 의미를 더 깊이 살펴보게 됩니다. 왜 관계형 모델에서 테이블을 릴레이션이라고 부르는지, 단순한 표와 이론적 릴레이션 사이에는 어떤 차이가 있는지 이해하게 되면 데이터베이스의 언어가 한층 더 정교하게 보이기 시작합니다. 지금 단계에서는 테이블이 구조이고, 튜플이 기록이며, 속성이 항목이고, 도메인이 규칙이라는 점을 분명히 기억해 두시면 충분합니다. 그 네 개념이 선명해지는 순간, 관계형 데이터베이스는 더 이상 낯선 기술 용어의 모음이 아니라 현실의 정보를 질서 있게 다루는 설계 철학으로 다가오실 것입니다.
데이터베이스를 잘 배운다는 말은 표를 읽는 법을 배우는 것이 아니라, 정보가 질서를 갖는 방식을 배우는 일입니다.
시리즈 안내
이번 편은 데이터 모델과 관계형 구조 흐름에서 관계형 데이터베이스의 기본 구성 요소를 다룬 글입니다.
앞선 편에서 관계형 데이터 모델과 관계형 데이터베이스의 큰 틀을 이해하셨다면, 이번 편은 그 구조를 이루는 최소 단위를 정리하는 단계입니다.
다음 편에서는 릴레이션의 의미를 통해 관계형 모델의 이론적 언어를 한층 더 정확하게 연결해 보겠습니다.
한 문장 정리 : 테이블은 구조, 튜플은 기록, 속성은 항목, 도메인은 규칙입니다.
댓글 쓰기