처음 배우는 데이터베이스 15편 | 관계형 데이터 모델
오늘날 대부분의 정보시스템이 왜 테이블 중심으로 데이터를 다루는지, 그리고 관계형 데이터 모델이 왜 데이터베이스 학습의 중심축으로 자리 잡았는지를 차근차근 풀어보겠습니다. 개념 정의에서 멈추지 않고, 구조와 원리, 실무 예시, 초보자가 자주 헷갈리는 지점까지 함께 정리해보겠습니다.
Intro
데이터베이스를 처음 공부하시는 분들께서 어느 시점에 가장 크게 체감하는 변화가 있습니다. 앞부분에서 데이터베이스의 필요성, 데이터 모델의 의미, 계층형 데이터 모델과 네트워크형 데이터 모델을 배울 때까지는 “구조가 여러 가지 있구나” 정도로 받아들이는 경우가 많습니다. 그런데 관계형 데이터 모델에 들어서는 순간부터는 상황이 달라집니다. 지금 우리가 실제로 사용하는 거의 모든 업무 시스템, 쇼핑몰, 병원 예약 시스템, 수강신청 시스템, 은행 거래 시스템, 공공행정 시스템이 어떤 방식으로 데이터 구조를 설계하고 운용하는지 본격적으로 이해할 수 있기 때문입니다. 데이터베이스를 배우는 과정에서 관계형 데이터 모델은 선택 과목이 아니라 중심 과목에 가깝습니다. 이 개념을 제대로 이해하느냐에 따라 뒤에서 배우는 키, 제약조건, 정규화, SQL, 트랜잭션, 인덱스까지 거의 모든 주제의 이해 수준이 달라집니다.
관계형 데이터 모델이 중요한 이유는 표처럼 보이는 데이터를 저장한다는 외형적 특징 때문만은 아닙니다. 더 중요한 부분은 데이터를 “논리적으로 독립된 단위”로 나누고, 각 단위를 명확한 속성 집합으로 표현하며, 서로 다른 데이터 집합 사이의 연결을 규칙 있게 다룰 수 있게 해준다는 점에 있습니다. 예를 들어 대학의 학사관리 시스템을 생각해보면 학생 정보, 과목 정보, 교수 정보, 수강 정보는 모두 성격이 다릅니다. 학생의 이름과 학번은 학생을 설명하는 정보이고, 과목명과 학점은 과목을 설명하는 정보이며, 어떤 학생이 어떤 과목을 수강했는지는 관계를 설명하는 정보입니다. 관계형 데이터 모델은 이런 차이를 깔끔하게 구분하여 저장할 수 있게 해줍니다. 그래서 데이터 중복을 줄이고, 수정 오류를 막고, 검색과 분석을 체계적으로 수행할 수 있습니다.
이번 글에서는 먼저 관계형 데이터 모델이 무엇인지부터 분명하게 정리하겠습니다. 이어서 관계형 데이터 모델이 어떤 구조로 이루어져 있는지, 왜 이전 세대의 데이터 모델보다 널리 쓰이게 되었는지, 현실 시스템에서는 어떤 방식으로 구현되는지 살펴보겠습니다. 또한 초보자가 자주 혼동하는 테이블과 릴레이션의 차이, 행과 튜플의 관계, 열과 속성의 의미도 차근차근 설명하겠습니다. 글의 마지막에서는 앞으로 이어질 관계형 데이터베이스, 테이블·튜플·속성·도메인, 릴레이션, 스키마와 인스턴스 같은 주제와의 연결 고리까지 잡아드리겠습니다.
핵심 요약 1
관계형 데이터 모델은 데이터를 행과 열의 구조로 표현하고, 각 테이블 사이의 연결을 통해 현실 세계의 복잡한 정보를 체계적으로 다루는 방식입니다.
핵심 요약 2
핵심은 표의 모양이 아니라 논리적 구조에 있습니다. 어떤 데이터를 하나의 릴레이션으로 묶고, 어떤 속성을 부여하며, 테이블 간 연결을 어떻게 설계할지가 중요합니다.
핵심 요약 3
관계형 데이터 모델을 이해하면 뒤에서 배우는 기본키, 외래키, 무결성 제약조건, 정규화, SQL의 흐름이 훨씬 또렷해집니다.
관계형 데이터 모델은 무엇을 말하는가
관계형 데이터 모델은 영국의 컴퓨터 과학자 에드거 F. 코드(E. F. Codd)가 제안한 데이터 모델로, 데이터를 수학적 관계의 개념에 바탕을 두고 구조화하는 방식입니다. 입문 단계에서는 “테이블 형태로 데이터를 표현하는 모델”이라고 이해하셔도 흐름을 따라가는 데 큰 무리는 없습니다. 다만 여기서 꼭 기억하셔야 할 점이 있습니다. 우리가 화면에서 보는 표와 관계형 이론에서 말하는 릴레이션은 완전히 같은 말이 아닙니다. 화면에 보이는 표는 표현 형식이고, 관계형 데이터 모델의 릴레이션은 속성과 값의 집합을 논리적으로 구성한 데이터 구조입니다. 실무에서는 편의상 테이블이라고 많이 부르지만, 이론적으로는 릴레이션이 더 정확한 표현입니다.
관계형 데이터 모델이 가진 가장 큰 장점은 데이터의 의미를 비교적 명확하게 분리해서 다룰 수 있다는 데 있습니다. 예를 들어 쇼핑몰을 운영한다고 가정해보겠습니다. 회원 정보에는 회원번호, 이름, 연락처, 가입일이 들어갑니다. 상품 정보에는 상품번호, 상품명, 가격, 재고가 들어갑니다. 주문 정보에는 주문번호, 주문일, 결제상태가 들어갑니다. 그리고 주문 상세에는 어떤 주문에 어떤 상품이 몇 개 포함되었는지가 기록됩니다. 이처럼 성격이 다른 데이터를 각각 별도의 릴레이션으로 나누면 관리가 깔끔해집니다. 회원 이름이 바뀌었다고 해서 주문 테이블의 수많은 행을 모두 수정할 필요가 없고, 상품 가격이 바뀌었다고 해서 과거 주문 전체를 다시 쓰는 방식으로 운영하지 않아도 됩니다.
학사관리 시스템도 같은 원리로 이해할 수 있습니다. 학생 릴레이션, 교수 릴레이션, 과목 릴레이션, 수강 릴레이션을 나누면 각각의 역할이 선명해집니다. 학생 릴레이션은 학생 자신을 설명하고, 과목 릴레이션은 과목을 설명하며, 수강 릴레이션은 학생과 과목 사이의 관계를 설명합니다. 관계형 데이터 모델이라는 이름에서 “관계형”이라는 표현은 테이블끼리 줄로 연결된다는 시각적 의미만 가리키지 않습니다. 현실 세계의 객체들 사이에 맺어지는 의미 있는 관계를 데이터 구조 속에 녹여내는 관점을 담고 있습니다.
중요한 포인트
관계형 데이터 모델의 본질은 “테이블처럼 보인다”는 모양보다 “데이터를 성격별로 나누고, 그 사이의 연결을 규칙적으로 다룬다”는 논리에 있습니다.
왜 관계형 데이터 모델이 널리 쓰이게 되었을까
계층형 데이터 모델과 네트워크형 데이터 모델은 역사적으로 매우 중요한 위치를 차지합니다. 실제로 초기 정보시스템에서는 이 두 모델이 큰 역할을 했습니다. 그러나 시간이 지나면서 데이터의 구조가 복잡해지고, 업무 요구가 자주 바뀌고, 여러 부서와 여러 사용자 집단이 같은 데이터를 다양한 방식으로 조회해야 하는 상황이 늘어났습니다. 그 과정에서 기존 모델은 구조 변경에 유연하게 대응하기 어렵고, 탐색 경로에 대한 의존성이 크며, 사용자가 데이터를 논리적으로 보기보다 물리적 접근 방식까지 함께 고민해야 하는 문제가 드러났습니다.
관계형 데이터 모델은 이런 부담을 크게 줄여주었습니다. 사용자는 “어떤 경로를 따라가야 데이터에 도달하는가”보다 “어떤 조건을 가진 데이터를 찾고 싶은가”에 더 집중할 수 있게 되었습니다. 나중에 SQL이 널리 퍼진 것도 같은 이유와 연결됩니다. 예를 들어 병원 예약 시스템에서 특정 의사의 다음 주 예약 현황을 알고 싶다면, 관계형 환경에서는 예약 테이블과 의사 테이블, 환자 테이블을 연결해 조건에 맞는 데이터를 조회하면 됩니다. 반면 구조적 경로에 강하게 묶인 모델에서는 데이터 접근의 순서와 연결 구조를 훨씬 세밀하게 의식해야 했습니다.
또 하나 중요한 이유는 유지보수와 확장성입니다. 공공기관의 민원 처리 시스템을 생각해보면, 처음에는 민원 접수와 처리 결과만 저장하면 될 수 있습니다. 그런데 시간이 지나면 처리 담당자, 처리 기한, 민원 유형 분류, 만족도 조사, 재접수 이력, 첨부파일 정보까지 관리 범위가 넓어집니다. 관계형 데이터 모델은 이런 확장 요구에 비교적 대응하기 좋습니다. 새 속성을 추가하거나 새 릴레이션을 설계하여 기능을 확장할 수 있기 때문입니다. 물론 설계를 잘못하면 복잡성이 커질 수 있지만, 기본 철학 자체는 변화에 대응하기 좋은 방향을 가지고 있습니다.
데이터 무결성을 지키기 좋은 점도 큰 장점입니다. 같은 정보를 여러 곳에 중복해서 저장할수록 오류 가능성이 커집니다. 학생의 학과명이 다섯 개 테이블에 반복 저장되어 있다면 어느 한 곳만 수정되어 다른 곳과 불일치가 생길 수 있습니다. 관계형 데이터 모델은 이런 중복을 줄이고, 키와 제약조건을 통해 데이터의 일관성을 유지하는 데 유리합니다. 이 점은 뒤에서 배우게 될 정규화와 무결성 제약조건의 기반이 되며, 관계형 데이터베이스가 실무에서 신뢰받는 중요한 이유 가운데 하나입니다.
왜 필요한가를 한 문장으로 정리하면
데이터가 많아질수록 중요한 것은 저장 자체보다 정확성, 일관성, 변경 용이성, 조회 편의성입니다. 관계형 데이터 모델은 바로 이 네 가지 요구를 균형 있게 다루기 위해 발전해온 구조입니다.
관계형 데이터 모델의 핵심 구성 요소
관계형 데이터 모델을 이해할 때 가장 먼저 익숙해져야 할 단어는 릴레이션, 튜플, 속성, 도메인입니다. 릴레이션은 하나의 테이블에 해당하는 논리적 데이터 집합이라고 보시면 됩니다. 튜플은 그 릴레이션 안의 한 행을 뜻합니다. 속성은 각 열의 이름과 역할을 가리키며, 도메인은 해당 속성이 가질 수 있는 값의 범위를 말합니다. 예를 들어 학생 릴레이션에 학번, 이름, 학년, 학과코드라는 속성이 있다고 해보겠습니다. 이때 한 학생의 정보 한 줄이 튜플이고, 학년 속성의 도메인은 1, 2, 3, 4 같은 허용 범위로 이해할 수 있습니다.
초보자가 자주 헷갈리는 부분도 여기 있습니다. 엑셀 표도 행과 열로 이루어져 있으니 관계형 데이터 모델과 같다고 느끼기 쉽습니다. 하지만 엑셀 표는 자유로운 문서 작성 도구에 가깝고, 관계형 데이터 모델의 릴레이션은 일정한 규칙을 지켜야 합니다. 각 열은 같은 종류의 값을 가져야 하고, 한 속성은 명확한 의미를 가져야 하며, 한 튜플은 하나의 개체나 관계를 일관되게 표현해야 합니다. 학생 이름, 지도교수 이름, 수강 과목명, 등록금 납부 상태를 아무 기준 없이 한 시트에 계속 이어붙이면 보기에는 표일 수 있지만, 관계형 설계 관점에서는 좋은 구조라고 보기 어렵습니다.
관계형 데이터 모델의 강점은 바로 이 “의미의 분리”에 있습니다. 학생에 관한 사실은 학생 릴레이션에, 과목에 관한 사실은 과목 릴레이션에, 수강이라는 사건은 수강 릴레이션에 저장하는 식입니다. 그러면 각 릴레이션은 자신의 역할이 분명해지고, 서로를 키로 연결할 수 있습니다. 예를 들어 수강 릴레이션 안에 학번과 과목번호가 들어가면, 어떤 학생이 어떤 과목을 듣는지 표현할 수 있습니다. 이렇게 관계를 별도의 릴레이션으로 표현하는 설계 방식은 특히 다대다 관계를 깔끔하게 다루는 데 매우 중요합니다.
실무에서는 이 구조가 보고서 작성, 통계 분석, 서비스 운영, 권한 관리에도 영향을 줍니다. 예를 들어 지방자치단체 복지 서비스 관리 시스템에서 수급자 정보, 지원 프로그램 정보, 신청 이력, 지급 이력, 담당 공무원 정보가 모두 섞여 있다면 데이터 품질 관리가 매우 어려워집니다. 반대로 관계형 모델에 맞게 분리되어 있으면 지원 대상자별 현황, 프로그램별 집행 규모, 시기별 신청 추이, 담당자별 처리 실적을 훨씬 정확하게 뽑아낼 수 있습니다. 데이터 구조가 좋다는 말은 결국 관리와 분석이 가능하다는 뜻으로 이어집니다.
| 개념 | 쉽게 이해하는 표현 | 관계형 모델에서의 역할 |
|---|---|---|
| 릴레이션 | 테이블 전체 | 하나의 주제나 개체를 설명하는 데이터 집합 |
| 튜플 | 행 한 줄 | 개별 개체나 사건 하나를 표현 |
| 속성 | 열의 이름 | 데이터가 어떤 성질을 갖는지 규정 |
| 도메인 | 허용 가능한 값의 범위 | 속성 값의 의미와 유효 범위를 제한 |
위 표를 보시면 관계형 데이터 모델이 왜 구조 중심의 사고를 요구하는지 감이 잡히실 것입니다. 표를 채우는 것보다 먼저, 무엇을 하나의 릴레이션으로 볼 것인지, 한 튜플이 무엇을 대표하는지, 속성이 어떤 의미를 갖는지, 값의 범위를 어떻게 제한할지를 결정해야 합니다. 데이터베이스 설계가 중요한 이유도 여기에 있습니다. 겉보기에는 비슷한 표라도, 그 내부 논리가 다르면 품질과 활용 가능성은 크게 달라집니다.
관계형 데이터 모델은 실제 시스템에서 어떻게 작동할까
많은 분들이 관계형 데이터 모델을 “교과서용 개념”으로 받아들이지만, 현실에서는 매우 구체적인 운영 원리로 작동합니다. 예를 들어 은행 거래 시스템을 떠올려보겠습니다. 고객 릴레이션에는 고객번호, 이름, 연락처가 저장됩니다. 계좌 릴레이션에는 계좌번호, 개설일, 잔액, 고객번호가 저장됩니다. 거래내역 릴레이션에는 거래번호, 계좌번호, 거래일시, 거래금액, 거래유형이 저장됩니다. 이 구조를 보면 한 고객이 여러 계좌를 가질 수 있고, 한 계좌에는 수많은 거래내역이 쌓일 수 있다는 사실을 데이터로 자연스럽게 표현할 수 있습니다. 고객 정보가 바뀌어도 거래내역 전체를 다시 쓰지 않아도 되고, 특정 계좌의 거래 기록도 안정적으로 추적할 수 있습니다.
병원 예약 시스템도 마찬가지입니다. 환자 릴레이션, 의사 릴레이션, 진료과 릴레이션, 예약 릴레이션, 진료기록 릴레이션을 분리해두면 예약 관리와 진료 이력 관리가 훨씬 정확해집니다. 어떤 환자가 어느 의사에게 언제 예약했는지, 예약 후 실제 진료가 이루어졌는지, 어떤 진료과에 소속된 의사인지, 진료기록이 남았는지를 각각의 릴레이션과 연결 구조를 통해 파악할 수 있습니다. 만약 이 모든 정보를 하나의 거대한 표에 몰아넣는다면 환자 정보와 의사 정보가 반복해서 등장하게 되고, 수정과 조회 과정에서 오류 가능성이 크게 높아질 것입니다.
공공행정 분야에서도 관계형 모델은 매우 중요합니다. 주민 정보, 민원 신청 정보, 처리 부서 정보, 처리 결과 정보, 예산 집행 정보가 각각 구분되어야 행정 데이터의 신뢰성이 살아납니다. 예를 들어 한 시민이 여러 민원을 신청할 수 있고, 하나의 민원은 여러 처리 단계를 거칠 수 있으며, 특정 사업 예산과 연결될 수도 있습니다. 관계형 데이터 모델은 이런 복합 관계를 질서 있게 정리합니다. 그래서 행정 현장에서는 데이터가 많아지는 것보다 구조가 흐트러지는 것을 더 두려워합니다. 구조가 무너지면 집계가 흔들리고, 집계가 흔들리면 판단이 흔들리기 때문입니다.
여기서 한 가지 더 짚고 넘어가면 좋겠습니다. 관계형 데이터 모델은 모든 종류의 데이터를 무조건 가장 잘 처리하는 만능 해답은 아닙니다. 최근에는 문서형 데이터베이스나 그래프 데이터베이스처럼 다른 접근도 널리 쓰입니다. 하지만 구조가 명확하고, 데이터 정확성과 무결성이 중요하며, 여러 테이블을 조합한 질의가 빈번한 업무 환경에서는 관계형 모델이 여전히 강력한 선택지입니다. 그래서 데이터베이스 개론에서는 지금도 관계형 데이터 모델이 가장 중요한 축으로 다뤄집니다.
초보자가 특히 헷갈리는 부분 정리
첫째, 관계형 데이터 모델의 “관계”를 테이블과 테이블 사이의 선 연결로만 이해하면 폭이 좁아집니다. 물론 테이블 간 연결도 매우 중요합니다. 다만 더 넓게 보면 관계형 모델은 현실 세계의 개체와 개체 사이, 개체와 사건 사이, 사건과 사건 사이의 의미를 구조화하는 방식입니다. 학생과 과목, 고객과 주문, 환자와 진료, 민원과 처리 이력처럼 현실의 연결을 논리적으로 저장하는 체계라고 받아들이시면 이해가 훨씬 깊어집니다.
둘째, “표처럼 보이면 다 관계형이다”라고 생각하면 안 됩니다. 문서 작성용 표는 관계형 구조일 수도 있고 아닐 수도 있습니다. 관계형 모델에서는 각 열의 의미가 분명해야 하고, 중복과 모순이 최소화되어야 하며, 데이터 간 연결 논리가 설계되어 있어야 합니다. 겉으로 표처럼 보이지만 여러 개체의 정보가 뒤섞여 있다면 관계형 관점에서는 개선이 필요한 상태일 수 있습니다.
셋째, 관계형 데이터 모델을 배우면서 SQL을 곧바로 떠올리는 분들이 많습니다. SQL은 관계형 모델을 다루기 위한 대표적 언어이지만, 둘은 같은 말이 아닙니다. 관계형 데이터 모델은 이론적 구조와 설계 철학에 가깝고, SQL은 그 구조 위에서 데이터를 정의하고 조작하고 조회하기 위한 실용적 도구입니다. 이 차이를 이해하면 나중에 SELECT문, JOIN, GROUP BY, 서브쿼리를 배울 때 왜 그런 문법이 필요한지도 자연스럽게 연결됩니다.
넷째, 관계형 모델을 제대로 이해하려면 “하나의 행이 무엇을 뜻하는가”를 늘 점검하셔야 합니다. 학생 테이블의 한 행은 학생 한 명을 뜻해야 합니다. 주문 테이블의 한 행은 주문 한 건을 뜻해야 합니다. 주문 상세 테이블의 한 행은 주문 한 건 안에 포함된 상품 한 항목을 뜻해야 합니다. 이 기준이 흔들리면 데이터 구조가 금세 복잡해집니다. 좋은 설계는 언제나 한 튜플이 대표하는 현실의 대상이나 사건을 분명하게 설정하는 데서 시작합니다.
실무 체크포인트
- 한 테이블이 한 가지 주제에 집중하고 있는지 점검해보셔야 합니다.
- 한 행이 무엇을 대표하는지 문장으로 설명할 수 있어야 합니다.
- 반복 저장되는 정보가 있는지 확인해보셔야 합니다.
- 테이블 간 연결 기준이 되는 식별자가 명확한지 살펴보셔야 합니다.
- 앞으로 조회와 분석을 어떻게 할지까지 염두에 두고 구조를 설계해야 합니다.
기억해 둘 점
관계형 데이터 모델은 “표를 잘 만드는 법”을 배우는 주제가 아닙니다. 현실의 정보를 분리하고 연결하고 검증하는 법을 배우는 주제입니다. 이 감각이 잡히면 데이터베이스는 외워야 할 용어 모음이 아니라, 질서 있는 정보 설계의 언어로 다가오기 시작합니다.
용어사전
관계형 데이터 모델 : 데이터를 릴레이션 중심으로 구조화하고, 그 사이의 연결을 논리적으로 다루는 데이터 모델
릴레이션 : 하나의 주제에 대한 데이터 집합으로, 실무에서는 보통 테이블에 대응
튜플 : 릴레이션 안의 한 행으로, 하나의 개체나 사건을 표현
속성 : 릴레이션의 각 열이 가지는 이름과 의미
도메인 : 속성이 가질 수 있는 값의 범위와 형식
FAQ
Q1. 관계형 데이터 모델과 관계형 데이터베이스는 같은 말인가요?
완전히 같은 말은 아닙니다. 관계형 데이터 모델은 이론적 구조와 설계 원리이고, 관계형 데이터베이스는 그 모델을 실제 시스템으로 구현한 형태라고 이해하시면 좋습니다.
Q2. 엑셀 표도 관계형 데이터 모델인가요?
엑셀 표가 관계형 구조를 흉내 낼 수는 있지만, 모든 엑셀 표가 관계형 모델에 맞는 것은 아닙니다. 데이터 의미의 분리, 연결 구조, 무결성 관리가 함께 고려되어야 합니다.
Q3. 왜 테이블을 여러 개로 나누나요?
중복을 줄이고, 수정 오류를 막고, 구조를 명확하게 하기 위해서입니다. 성격이 다른 데이터를 억지로 한곳에 몰아넣으면 나중에 조회와 유지보수가 어려워집니다.
Q4. 관계형 모델을 이해하면 다음에 무엇이 쉬워지나요?
기본키, 외래키, 무결성 제약조건, 정규화, SQL JOIN 같은 주제가 훨씬 또렷해집니다. 뒤의 거의 모든 내용이 여기서 출발합니다.
참고자료 성격의 안내 박스
관계형 데이터 모델은 다음 주제들과 강하게 연결됩니다. 이어서 학습하실 때는 관계형 데이터베이스란 무엇인가, 테이블·튜플·속성·도메인, 릴레이션의 의미, 스키마와 인스턴스, 차수와 카디널리티 순서로 보시면 흐름이 자연스럽습니다.
특히 키와 제약조건, 정규화, SQL 학습 전에는 오늘 다룬 관계형 관점을 충분히 익혀두시는 편이 좋습니다. 구조를 모른 채 문법부터 배우면 명령은 외워도 설계 감각이 잘 잡히지 않기 때문입니다.
관계형 데이터 모델은 데이터베이스 세계의 문법을 열어주는 핵심 열쇠입니다. 앞에서 살펴본 것처럼 이 모델은 데이터를 보기 좋게 정리하는 방법을 넘어, 현실의 정보를 어떻게 나누고 어떻게 연결하며 어떻게 일관되게 유지할 것인가에 대한 깊은 사고를 담고 있습니다. 그래서 관계형 데이터 모델을 이해한다는 말은 데이터베이스를 표 형태의 저장소로 보는 수준을 넘어, 정보 구조를 설계하는 눈을 갖는다는 뜻에 가깝습니다. 이 관점이 생기면 쇼핑몰 주문 구조를 봐도, 학사관리 시스템을 봐도, 공공행정 정보시스템을 봐도 왜 테이블이 나뉘어 있는지, 왜 식별자가 중요한지, 왜 중복을 줄여야 하는지가 자연스럽게 보이기 시작합니다.
데이터베이스 학습 전체에서 관계형 데이터 모델은 매우 중요한 분기점에 놓여 있습니다. 앞선 데이터 모델 일반론이 지형을 보여주는 단계였다면, 이번 주제는 앞으로 실제 설계와 운용의 언어를 익히는 출발점이라고 할 수 있습니다. 여기서부터는 각 구성 요소를 더 세밀하게 나누어 보게 됩니다. 관계형 데이터베이스가 무엇인지, 테이블과 튜플과 속성과 도메인이 어떤 차이를 가지는지, 릴레이션을 어떻게 이해해야 하는지, 스키마와 인스턴스는 무엇인지가 이어서 등장합니다. 그 다음에는 키와 제약조건, 설계, SQL, 정규화, 트랜잭션으로 학습이 자연스럽게 뻗어나갑니다.
데이터베이스 공부를 하다 보면 많은 분들이 용어가 많아서 어렵다고 느끼십니다. 그런데 용어 하나하나를 외우는 방식보다, “현실의 대상을 어떻게 구조화할 것인가”라는 질문을 붙잡고 공부하시면 이해가 훨씬 오래갑니다. 관계형 데이터 모델은 바로 그 질문에 가장 오래 살아남은 답 가운데 하나입니다. 다음 회차에서는 관계형 데이터베이스란 무엇인가를 이어서 다루면서, 오늘 배운 관계형 모델이 실제 데이터베이스 시스템과 어떻게 만나는지 더 분명하게 연결해보겠습니다.
시리즈 안내
이 글은 처음 배우는 데이터베이스 시리즈의 15편입니다.
앞선 흐름 : 데이터 모델이란 무엇인가 → 개념적·논리적·물리적 모델 → 계층형 데이터 모델 → 네트워크형 데이터 모델
다음 흐름 : 관계형 데이터베이스란 무엇인가 → 테이블, 튜플, 속성, 도메인 → 릴레이션의 의미
댓글 쓰기