처음 배우는 데이터베이스 11편 | 데이터 모델이란 무엇인가
데이터베이스를 공부하다 보면 테이블, 키, 관계, 스키마 같은 용어를 빠르게 만나게 됩니다. 그런데 그보다 먼저 이해해야 할 뿌리가 있습니다. 바로 현실의 대상을 어떤 규칙과 구조로 표현할 것인가를 다루는 데이터 모델입니다. 오늘 글에서는 데이터 모델의 정의부터 필요성, 구성 요소, 실제 설계와의 연결점까지 차근차근 살펴보겠습니다.
질서 있는 구조로 표현하는 순간, 데이터 모델이 시작됩니다.
Intro. 왜 데이터 모델부터 이해해야 할까요?
데이터베이스를 처음 배우는 분들은 종종 SQL 문법이나 테이블 생성부터 공부하고 싶어 하십니다. 물론 그 접근도 나쁘지 않습니다. 다만 문법은 도구이고, 설계는 사고방식입니다. 도구를 잘 쓰려면 먼저 무엇을 어떻게 담아야 하는지 알아야 합니다. 데이터 모델은 현실 세계의 대상과 사건을 데이터베이스 안에서 어떤 모습으로 표현할지를 정하는 틀입니다. 학생과 과목, 고객과 주문, 환자와 진료 기록처럼 세상 속 요소들은 원래 흩어져 존재합니다. 데이터 모델은 그 흩어진 요소들 사이의 관계를 읽어 내고, 컴퓨터가 이해할 수 있는 구조로 바꾸는 과정의 출발점이 됩니다.
이 개념을 놓치면 데이터베이스 학습은 금방 암기 중심으로 흐르기 쉽습니다. 왜 어떤 정보는 한 테이블에 넣고, 왜 어떤 정보는 분리해야 하며, 왜 어떤 칼럼은 필수이고 어떤 값은 허용하면 안 되는지에 대한 판단 기준이 흐려지기 때문입니다. 반대로 데이터 모델을 이해하면 관계형 데이터베이스를 배우는 과정이 훨씬 또렷해집니다. 테이블이 왜 필요한지, 기본키와 외래키가 왜 등장하는지, 정규화가 왜 중요한지까지 자연스럽게 이어집니다. 한마디로 말씀드리면, 데이터 모델은 데이터베이스의 문법이 아니라 데이터베이스의 세계관이라고 보셔도 좋습니다.
오늘 글에서는 먼저 데이터 모델의 뜻을 정확히 정리하고, 이어서 데이터 모델이 왜 필요한지와 어떤 요소로 이루어지는지 살펴보겠습니다. 그 다음에는 현실 사례를 통해 데이터 모델이 실제 시스템 설계에서 어떤 역할을 하는지 설명드리겠습니다. 마지막에는 초보자가 헷갈리기 쉬운 지점과 다음 학습으로 이어지는 흐름까지 정리해 드리겠습니다. 이번 회차를 통해 독자 여러분께서 “데이터 모델이 무엇인지 안다”를 넘어 “왜 먼저 배워야 하는지 이해했다”라는 상태에 도달하실 수 있도록 깊이 있게 풀어가겠습니다.
핵심 요약 카드
현실 세계의 대상, 속성, 관계, 제약을 데이터 구조로 바꾸는 규칙 체계입니다.
중복, 누락, 모순, 확장성 부족 같은 문제를 미리 줄이는 기준을 제공합니다.
테이블, 키, 제약조건, 정규화, ER 모델을 배우기 위한 사고의 바탕이 됩니다.
데이터 모델의 기본 정의: 현실을 구조화하는 설계 언어
데이터 모델은 현실 세계에 존재하는 대상과 사건을 데이터베이스 안에서 표현하기 위한 개념적 틀입니다. 더 정확히 말씀드리면, 어떤 데이터를 저장할 것인지, 그 데이터는 어떤 성질을 가지는지, 데이터끼리는 어떤 관계를 맺는지, 어떤 규칙을 따라야 하는지를 정리한 표현 체계입니다. 여기에는 구조만 들어가는 것이 아닙니다. 구조를 다루는 규칙, 허용과 금지의 기준, 데이터를 조작하는 방식까지 함께 담깁니다. 그래서 데이터 모델을 “데이터를 담는 그릇”이라고만 이해하면 조금 부족합니다. 그릇의 모양뿐 아니라 그 안에 무엇을 담을 수 있는지, 어떻게 꺼내고 어떻게 보존할지까지 포함하는 약속에 가깝습니다.
예를 들어 대학의 수강신청 시스템을 떠올려 보겠습니다. 현실 세계에는 학생이 있고, 교수자가 있고, 강좌가 있으며, 한 학생은 여러 강좌를 신청할 수 있고, 한 강좌에는 여러 학생이 등록될 수 있습니다. 또 학생에게는 학번, 이름, 학과 같은 정보가 있고, 강좌에는 과목코드, 과목명, 학점, 분반 정보가 있습니다. 만약 이런 현실을 아무 규칙 없이 프로그램 안에 저장하면, 어떤 화면에서는 학생 이름을 다르게 적고, 다른 곳에서는 과목코드를 빼먹고, 등록 관계도 일관되게 관리하지 못할 수 있습니다. 데이터 모델은 이런 혼란을 막기 위해 현실을 분석하고, 핵심 대상을 식별하고, 각 대상의 속성과 관계를 명확히 정의합니다.
학문적으로 보면 데이터 모델은 보통 세 가지 축으로 설명됩니다. 첫째는 구조입니다. 무엇을 어떤 형태로 표현할지 정합니다. 둘째는 제약조건입니다. 어떤 값이 허용되고 어떤 상태가 허용되지 않는지 규정합니다. 셋째는 연산입니다. 데이터를 조회, 삽입, 수정, 삭제할 때 어떤 방식으로 다룰지 다룹니다. 이 세 축을 짧게 정리하면 아래와 같은 형태로 기억하셔도 좋습니다.
데이터 모델 = 구조(Structure) + 제약조건(Constraints) + 연산(Operations)
이 공식은 수학적 계산을 하려는 목적보다, 데이터 모델의 성격을 머릿속에서 정리하는 데 도움이 됩니다. 구조만 있으면 보기 좋은 틀은 만들 수 있어도, 잘못된 데이터가 들어오는 문제를 막기 어렵습니다. 제약조건만 강조하면 운영은 딱딱해지고 실제 사용 흐름을 반영하지 못할 수 있습니다. 연산만 생각하면 데이터를 꺼내 쓰는 기술은 익힐 수 있어도, 그 데이터가 어떤 질서 위에 놓여 있는지 놓치게 됩니다. 좋은 데이터 모델은 세 요소가 균형 있게 맞물릴 때 비로소 힘을 발휘합니다.
SQL을 잘 쓰는 사람과 데이터 구조를 잘 설계하는 사람은 완전히 같은 의미가 아닙니다. 오래 쓰이는 시스템은 대개 데이터 모델이 탄탄합니다.
왜 데이터 모델이 중요한가: 중복과 혼란을 줄이고, 확장을 준비합니다
데이터 모델이 중요한 가장 큰 이유는 현실이 생각보다 훨씬 복잡하기 때문입니다. 사람은 말로 상황을 설명할 때 어느 정도 모호함을 허용할 수 있습니다. “회원이 주문을 했다”라고 말하면 대부분 이해합니다. 하지만 컴퓨터 시스템은 모호함을 잘 견디지 못합니다. 회원 한 명이 여러 주문을 할 수 있는지, 주문 하나에 여러 상품이 포함될 수 있는지, 회원이 탈퇴한 뒤 주문 기록은 어떻게 남길지, 배송지는 주문 시점 기준으로 보관할지 회원 정보와 연결할지 같은 판단이 분명해야 합니다. 데이터 모델은 이런 질문을 체계적으로 던지게 해 주고, 설계자가 감으로 결정하는 일을 줄여 줍니다.
쇼핑몰 시스템을 예로 들어 보겠습니다. 고객 이름, 주소, 주문번호, 상품명, 수량을 한 테이블에 전부 몰아넣는 방식은 처음에는 편해 보일 수 있습니다. 그런데 고객이 주소를 바꾸면 과거 주문 데이터까지 일괄 수정해야 하는지, 상품명이 변경되면 예전 거래 내역도 바꿔야 하는지, 한 주문에 상품이 여러 개일 때 행이 어떻게 늘어나는지 같은 문제가 금방 생깁니다. 이때 데이터 모델을 바탕으로 고객, 주문, 주문상세, 상품을 나누어 생각하면 어떤 정보가 독립된 대상인지가 보입니다. 그 결과 중복 저장을 줄이고, 데이터 불일치 가능성을 낮추며, 시스템 변경에도 더 유연하게 대응할 수 있습니다.
병원 예약 시스템도 비슷합니다. 환자 정보, 진료과 정보, 의사 일정, 예약 기록, 처방 기록을 구분하지 않고 한 덩어리로 관리하면 조회 속도보다 먼저 정확성이 흔들립니다. 같은 환자 이름이 여러 방식으로 입력되거나, 이미 취소된 예약이 남아 있거나, 의사 변경 내역이 과거 기록에 섞이는 문제가 나타날 수 있습니다. 데이터 모델은 환자와 예약, 진료와 처방을 서로 다른 관점에서 정리하도록 돕습니다. 무엇이 본체 정보이고 무엇이 사건 기록인지 구분하게 만들기 때문입니다. 이 구분이 명확할수록 데이터 품질과 서비스 안정성은 좋아집니다.
또 하나 중요한 점은 확장성입니다. 많은 초보 설계가 “지금 당장 필요한 화면”을 기준으로 데이터 구조를 짭니다. 그렇게 되면 현재 기능은 돌아갈 수 있어도 나중에 요구사항이 늘어나면 금방 무너집니다. 예를 들어 학사관리 시스템에서 처음에는 학생과 과목만 있으면 될 것처럼 보여도, 시간이 지나면 재수강, 복수전공, 성적 정정, 휴학, 교환학생, 팀티칭 같은 예외 상황이 생깁니다. 데이터 모델을 갖추고 설계를 시작하면 처음부터 예외를 전부 예측할 수는 없어도, 구조를 바르게 나눠 두기 때문에 변경 비용을 크게 줄일 수 있습니다. 좋은 모델은 미래의 변화와 대화를 나눌 수 있는 구조입니다.
화면 수정은 비교적 쉬울 수 있지만, 데이터 구조를 뒤늦게 고치는 일은 훨씬 어렵고 위험합니다. 설계 초반의 고민이 중요한 이유가 여기에 있습니다.
데이터 모델은 무엇으로 이루어질까: 구조, 관계, 제약, 연산의 조합
데이터 모델을 구성하는 첫 번째 요소는 구조입니다. 구조는 현실의 대상을 어떤 형식으로 담을지를 다룹니다. 관계형 데이터베이스에서는 보통 테이블과 행과 열의 형태로 표현됩니다. 객체 지향 환경에서는 클래스와 속성, 문서형 데이터베이스에서는 JSON 문서 구조처럼 나타날 수 있습니다. 형식은 달라져도 핵심은 같습니다. 현실 속 요소를 표현 가능한 단위로 나누고, 그 단위가 어떤 속성을 가지는지 정하는 일입니다. 학생이라는 대상에는 학번, 이름, 학과, 입학년도 같은 속성이 붙고, 강좌라는 대상에는 과목코드, 과목명, 담당교수, 학점 같은 속성이 붙습니다.
두 번째 요소는 관계입니다. 현실의 정보는 혼자 존재하지 않습니다. 학생은 강좌를 수강하고, 고객은 주문을 만들고, 공공행정 시스템에서는 민원인이 신청서를 제출하며, 부서와 직원도 연결됩니다. 데이터 모델은 이런 연결을 식별하고 규칙화합니다. 한 학생이 여러 강좌를 들을 수 있고, 한 강좌도 여러 학생을 받을 수 있다면 다대다 관계가 생깁니다. 반면 한 주민등록번호는 한 사람에게만 연결되어야 한다면 일대일에 가까운 관리가 필요합니다. 관계를 정교하게 파악하지 못하면 데이터 구조가 비대해지거나, 억지로 한 칸에 여러 의미를 집어넣는 설계가 나올 수 있습니다.
세 번째 요소는 제약조건입니다. 데이터베이스가 믿을 만한 시스템이 되려면 아무 값이나 저장되면 안 됩니다. 학생의 학번은 비어 있으면 안 되고, 주문일자는 존재해야 하며, 수량은 음수가 되면 안 되고, 존재하지 않는 고객번호로 주문이 생성되면 안 됩니다. 제약조건은 데이터 품질의 마지막 방어선이 아니라, 설계 단계에서부터 데이터의 의미를 명시하는 약속입니다. 나중에 배우실 개체 무결성, 참조 무결성, 도메인 무결성도 모두 이 축에 들어갑니다. 운영 중 오류를 줄이고, 서로 다른 개발자와 사용자가 같은 해석을 공유할 수 있게 만드는 기능도 합니다.
네 번째 요소는 연산입니다. 데이터를 어떻게 읽고 어떻게 바꿀지를 규정하는 방식입니다. 관계형 모델에서는 선택, 투영, 조인 같은 연산 개념이 중요합니다. 사용자는 화면에서 “이번 학기 3학점 이상 과목만 보여 주세요”라고 요청하지만, 시스템 내부에서는 그런 요청을 수행할 수 있는 구조적 전제가 필요합니다. 좋은 데이터 모델은 데이터 저장만 잘하는 구조가 아니라, 필요한 질의를 효율적으로 수행할 수 있는 구조이기도 합니다. 그래서 모델을 설계할 때는 저장 관점과 조회 관점을 함께 보아야 합니다.
| 구성 요소 | 무엇을 다루는가 | 예시 | 왜 중요한가 |
|---|---|---|---|
| 구조 | 데이터 표현 형식 | 학생 테이블, 강좌 테이블 | 무엇을 저장할지 분명해집니다 |
| 관계 | 대상 간 연결 방식 | 학생-수강, 고객-주문 | 현실의 흐름을 반영합니다 |
| 제약조건 | 허용/금지 규칙 | 학번 필수, 수량 양수 | 데이터 신뢰성을 지킵니다 |
| 연산 | 조회와 변경 방법 | 검색, 삽입, 수정, 조인 | 실제 활용 가능성을 높입니다 |
위 표를 보시면 데이터 모델이 “표 하나 만드는 일”과 다르다는 점이 분명해집니다. 구조를 정하는 일은 시작일 뿐이고, 실제로는 관계를 읽고 규칙을 세우고 활용 방식을 함께 설계하는 과정까지 포함됩니다. 그래서 데이터 모델을 잘 세우는 사람은 데이터베이스 설계자는 물론, 서비스 기획자나 시스템 분석가에게도 매우 중요한 역량을 갖춘 사람이라고 할 수 있습니다.
현실 사례로 이해하는 데이터 모델: 쇼핑몰과 학사관리 시스템
먼저 쇼핑몰 사례를 보겠습니다. 온라인 쇼핑몰에서 핵심 대상은 고객, 상품, 주문, 주문상세, 결제, 배송입니다. 고객은 회원 정보를 가지고 있고, 상품은 가격과 재고를 가지며, 주문은 언제 어떤 고객이 무엇을 구매했는지를 기록합니다. 여기서 가장 자주 나오는 초보 설계 오류는 주문과 상품을 한 줄에 모두 넣으려는 방식입니다. 한 주문에 상품이 세 개 들어가면 어떻게 해야 할까요? 상품명1, 상품명2, 상품명3 같은 칼럼을 추가하는 방식은 보기에는 쉬워 보여도 실제 운영에는 매우 취약합니다. 상품 수가 늘어날 때마다 구조가 흔들리고, 조회도 어려워집니다. 데이터 모델 관점에서는 주문과 주문상세를 분리해야 한다는 판단이 자연스럽게 나옵니다.
학사관리 시스템에서는 학생, 교수자, 학과, 교과목, 분반, 수강내역, 성적이 주요 대상이 됩니다. 여기서도 학생 테이블 안에 수강 과목을 여러 칸으로 넣는 방식은 금방 한계에 부딪힙니다. 한 학생이 매 학기 다른 과목을 듣기 때문입니다. 또 같은 교과목이라도 학기와 분반에 따라 다른 운영 단위가 될 수 있습니다. 데이터 모델은 이런 시간성과 운영 맥락까지 구조 안에 반영해야 합니다. 교과목과 개설강좌를 구분할지, 수강신청과 성적 부여를 하나의 기록으로 볼지 분리할지 같은 판단이 모두 모델링의 영역입니다. 이런 사고를 통해 시스템은 현실의 흐름을 더 정확하게 닮아갑니다.
공공행정 시스템도 좋은 예시가 됩니다. 민원 신청 시스템에서는 민원인, 신청서, 처리부서, 처리상태, 첨부서류, 결과통보가 서로 연결됩니다. 만약 민원인의 인적사항과 매번 제출하는 신청서 내용을 구분하지 않으면, 같은 사람이 여러 차례 신청할 때 중복 저장이 과도해지고 이력 관리도 어려워집니다. 반대로 신청 기록과 처리 상태를 분리해 두면, 현재 진행 상황 조회와 과거 이력 감사가 모두 쉬워집니다. 행정정보시스템에서 데이터 모델은 효율뿐 아니라 책임성과 추적 가능성에도 연결됩니다. 나중에 감사, 분쟁 대응, 민원 재검토 상황까지 고려하면 더더욱 중요합니다.
이런 사례를 통해 보실 수 있듯, 데이터 모델은 현실을 예쁘게 요약하는 도식이 아닙니다. 업무의 흐름과 규칙을 정보 구조로 번역하는 작업입니다. 그리고 이 번역이 정확할수록 나중에 화면 구성, 보고서 작성, 통계 분석, 자동화 기능, 권한 관리까지 훨씬 안정적으로 이어집니다. 설계가 탄탄하면 개발이 쉬워지고, 운영도 편해지고, 데이터 분석 신뢰도도 높아집니다.
화면 기준으로 설계하면 당장 보이는 기능은 만들 수 있습니다. 업무 흐름 기준으로 모델링하면 오래 가는 시스템을 만들 수 있습니다.
초보자가 자주 헷갈리는 부분: 데이터 모델과 테이블 설계는 같은 말일까요?
많은 분들이 데이터 모델을 테이블 설계와 같은 의미로 받아들이십니다. 완전히 틀린 해석은 아니지만, 범위가 더 넓다는 점을 꼭 기억하셔야 합니다. 테이블 설계는 보통 관계형 데이터베이스에서 실제 저장 구조를 만드는 일에 가깝습니다. 반면 데이터 모델은 그보다 앞단에서 무엇을 대상화할지, 어떤 관계와 규칙을 인정할지 정하는 더 넓은 개념입니다. 쉽게 말씀드리면, 데이터 모델은 설계 철학이고 테이블 설계는 그 철학이 현실 시스템으로 내려오는 한 방식입니다.
또 하나 헷갈리기 쉬운 부분은 “현실을 그대로 복사하면 좋은 모델이 된다”라는 생각입니다. 현실은 너무 복잡해서 그대로 담을 수 없습니다. 중요한 것은 현실을 충실히 반영하되, 시스템 목적에 맞게 추상화하는 일입니다. 예를 들어 병원에서는 환자의 모든 생활 습관을 저장할 수 있겠지만, 예약 시스템에서는 그중 예약과 진료 흐름에 필요한 정보만 골라내는 편이 바람직합니다. 데이터 모델은 현실의 축소판이 아니라, 목적에 맞게 다듬어진 표현입니다. 그래서 분석과 선택의 과정이 꼭 들어갑니다.
마지막으로 데이터 모델을 한 번 만들고 끝나는 고정 문서로 생각하는 경우도 많습니다. 실제 현장에서는 업무가 바뀌고 정책이 달라지고 서비스 기능이 확장되면서 모델도 함께 발전합니다. 다만 자주 바뀐다고 해서 처음 설계를 가볍게 해도 된다는 뜻은 아닙니다. 오히려 처음 구조를 탄탄하게 잡아 두어야 변화가 생겼을 때 무너짐 없이 수정할 수 있습니다. 처음 설계는 뼈대를 세우는 일이고, 이후 개선은 그 뼈대 위에 방을 더하는 일에 가깝습니다.
실무 체크포인트
- 지금 설계하는 대상이 사람인지, 물건인지, 사건인지 먼저 구분해 보십시오.
- 속성은 대상의 성질인지, 다른 대상과의 관계인지 분리해서 보십시오.
- 한 칸에 여러 값을 넣고 싶어진다면 구조를 다시 나눌 시점일 가능성이 큽니다.
- 현재 화면보다 앞으로 추가될 업무 흐름을 함께 상상해 보십시오.
- 값이 비어 있으면 안 되는 항목, 범위가 제한되는 항목을 초기에 표시해 두면 설계 품질이 좋아집니다.
기억해 둘 점
데이터 모델은 현실을 데이터로 번역하는 틀입니다. 테이블 이름을 정하는 작업보다 먼저, 무엇이 핵심 대상이고 어떤 관계가 성립하는지 생각해야 합니다.
잘 만든 데이터 모델은 기능 추가, 데이터 분석, 운영 안정성, 오류 방지까지 넓은 영역에 좋은 영향을 줍니다. 그래서 설계 초기의 고민은 결코 낭비가 아닙니다.
용어사전
데이터 모델 : 현실의 대상과 관계를 데이터 구조와 규칙으로 표현하는 체계입니다.
구조 : 데이터를 어떤 형식으로 저장하고 구분할지 정하는 틀입니다.
제약조건 : 허용되는 값과 금지되는 상태를 규정하는 규칙입니다.
연산 : 데이터를 조회·삽입·수정·삭제하는 방식입니다.
모델링 : 현실을 분석해 데이터 모델로 표현하는 과정입니다.
추상화 : 모든 사실을 담는 대신 목적에 맞는 핵심만 골라 표현하는 작업입니다.
FAQ
Q1. 데이터 모델은 개발자만 알아야 하나요?
아닙니다. 기획자, 분석가, 행정 담당자, 운영자도 이해할수록 업무 정의가 명확해집니다. 특히 요구사항을 정리하는 역할을 맡는 분에게 큰 도움이 됩니다.
Q2. 데이터 모델과 ER 모델은 같은 말인가요?
완전히 같지는 않습니다. ER 모델은 데이터 모델링을 표현하는 대표적 방법 중 하나입니다. 뒤에서 배우게 될 개체, 속성, 관계를 시각적으로 정리하는 데 강점이 있습니다.
Q3. 데이터 모델을 잘 만들면 정규화도 쉬워지나요?
그렇습니다. 대상과 관계를 올바르게 파악해 두면 중복과 종속 관계가 더 잘 보이기 때문에 정규화 학습과 적용이 수월해집니다.
Q4. 작은 프로젝트에도 데이터 모델이 필요한가요?
규모가 작아도 필요합니다. 프로젝트가 작을수록 더 빨리 구조를 정리할 수 있고, 나중에 커졌을 때 혼란을 줄일 수 있습니다.
참고자료 성격의 안내
데이터 모델은 뒤에서 배우게 될 관계형 데이터 모델, ER 모델, 키, 제약조건, 정규화와 긴밀하게 연결됩니다. 교과서에서는 보통 개념적 모델, 논리적 모델, 물리적 모델의 흐름 속에서 설명하며, 실무에서는 요구사항 분석과 함께 반복적으로 다듬는 경우가 많습니다.
다음 회차에서 다룰 개념적 모델·논리적 모델·물리적 모델의 차이를 함께 보시면, 오늘 공부한 내용이 한층 입체적으로 정리될 것입니다.
오늘 우리는 데이터 모델이 무엇인지, 왜 중요한지, 그리고 어떤 요소로 이루어지는지를 살펴보았습니다. 데이터 모델은 현실을 컴퓨터 안에 옮겨 담는 설계 언어입니다. 사람, 사물, 사건, 관계, 규칙을 질서 있게 정리해 주며, 데이터베이스를 믿을 만한 정보 시스템으로 만드는 기초를 제공합니다. 공부를 시작하는 단계에서는 이 개념이 다소 추상적으로 느껴질 수 있습니다. 그렇지만 한 번 사고의 틀을 잡아 두면 앞으로 배우게 될 관계형 데이터베이스, 테이블 구조, 키, 제약조건, 정규화가 모두 훨씬 잘 연결됩니다.
특히 데이터 모델은 기술보다 먼저 사고를 바꾸는 힘을 가집니다. 화면에 무엇을 보여 줄지보다, 현실에서 어떤 대상이 존재하고 어떤 관계가 실제로 성립하는지를 먼저 보게 만듭니다. 그래서 좋은 모델링은 좋은 프로그래밍 이전에 좋은 이해에서 출발합니다. 설계가 정확하면 개발과 운영이 편해지고, 데이터 분석의 신뢰도도 올라갑니다. 반대로 모델이 흔들리면 시스템은 시간이 갈수록 복잡해지고, 기능을 추가할수록 균열이 커질 수 있습니다.
다음 단계에서는 개념적 모델, 논리적 모델, 물리적 모델의 차이를 살펴보면서 데이터 모델이 실제 설계 과정에서 어떤 단계로 구체화되는지 이어서 공부하겠습니다. 오늘 회차를 바탕으로 현실의 시스템을 볼 때 “무엇이 대상이고, 무엇이 관계이며, 어떤 규칙이 필요한가”를 한 번씩 떠올려 보시면 데이터베이스가 더 이상 낯선 기술 용어가 아니라 질서 있는 사고의 도구로 보이기 시작할 것입니다.
현실을 구조화해서 이해하는 방식입니다.
시리즈 안내
지금 읽고 계신 글은 처음 배우는 데이터베이스 시리즈의 11편입니다.
앞선 회차에서는 데이터 독립성과 데이터베이스 사용자 유형까지 살펴보며 데이터베이스 기초 이해를 다졌습니다.
다음 회차에서는 처음 배우는 데이터베이스 12편 | 개념적 모델, 논리적 모델, 물리적 모델로 이어집니다.
마지막 한 문장 정리 : 데이터 모델은 현실을 데이터베이스로 옮길 때 길을 잃지 않게 해 주는 가장 기본적인 지도입니다.
댓글 쓰기