분류 전체보기42 늦게 도착한 데이터가 최신 정보를 덮어쓰면? 순서와 중복을 다루는 방법 장비가 고장났다는 보고를 확인한 지 몇 분 뒤, 화면의 상태가 다시 ‘정상’으로 바뀌었다. 정비가 끝난 줄 알고 담당자에게 연락했는데 돌아온 답은 달랐다. 아직 수리 중이었다. 정상이라는 값은 고장 전에 보낸 보고였고, 통신이 지연되면서 뒤늦게 도착한 것이었다.이런 상황에서는 보고서의 내용이 틀리지 않았을 수도 있다. 두 보고 모두 작성 당시에는 사실이었다. 잘못된 것은 나중에 도착한 보고를 현재의 상태로 받아들인 처리 방식이다. 데이터를 정확하게 표현하고 서로 같은 뜻으로 읽도록 약속해도, 도착 순서와 재전송을 다루는 규칙이 없으면 화면은 현실과 어긋난다.이번 글은 여러 체계가 장비 상태를 주고받는 가상 사례를 따라간다. 늦게 온 정보를 어디에 남길지, 같은 보고가 두 번 도착하면 어떻게 처리할지, 갱.. 2026. 10. 2. 현실의 업무는 어떻게 데이터가 될까? 데이터 모델의 역할 새로운 업무체계를 만들 때 가장 먼저 화면부터 그리는 경우가 있다. 담당자는 익숙한 신청서나 보고서를 펼쳐 놓고 입력칸과 버튼의 위치를 정한다. 화면이 눈에 보이니 일이 빠르게 진행되는 듯하지만, 막상 개발이 시작되면 같은 단어를 두고 서로 다른 뜻으로 이해했다는 사실이 드러난다.‘장비 상태’가 현재 상태인지 점검 당시의 상태인지, ‘소속’이 장비의 관리부서인지 실제 운용부서인지에 따라 저장해야 할 값과 관계가 달라진다. 처음에는 작은 표현 차이처럼 보였던 문제가 검색, 통계와 다른 체계의 연동 단계에서는 전혀 다른 결과를 만든다.앞선 글에서는 SQL이 저장된 데이터에 질문하고, 인덱스가 필요한 기록으로 가는 길을 줄이는 원리를 살펴보았다. 그러나 질문이 정확하고 길이 빨라도 현실의 대상을 잘못 나누어 .. 2026. 9. 22. 데이터베이스에는 어떻게 질문할까? SQL과 SELECT의 원리 정리된 창고가 있다고 해서 필요한 물건이 저절로 손에 들어오는 것은 아니다. 어느 선반에서 무엇을 몇 개 꺼낼지 알려주어야 한다. 데이터베이스도 비슷하다. 고객, 주문, 장비와 정비 기록을 알맞게 나누어 저장해 두었더라도 사용자가 원하는 조건을 전달하지 않으면 화면에 보여줄 결과를 만들 수 없다.앞선 글에서는 데이터 중복을 줄이고 서로 다른 대상을 나누어 저장하는 정규화를 살펴보았다. 고객 정보는 고객 테이블에, 주문은 주문 테이블에 두면 같은 주소를 여러 번 고치는 문제를 줄일 수 있었다. 대신 지난달 주문이나 특정 고객의 구매내역을 보려면 떨어져 있는 기록 가운데 필요한 것만 골라 다시 연결해야 한다.이때 관계형 데이터베이스에 원하는 결과를 표현하는 언어가 SQL이다. 사람의 질문을 그대로 알아듣는 .. 2026. 9. 22. 정리된 데이터는 어떻게 빨리 찾을까? 데이터베이스 인덱스의 원리 앞선 글에서는 고객, 주문, 상품처럼 성격이 다른 대상을 나누어 저장하는 이유를 살펴보았다. 같은 주소와 상품 정보를 주문마다 반복하지 않고, 각각의 사실을 알맞은 테이블이 맡게 하면 한곳만 고쳐도 데이터가 일관되게 유지된다. 기본키와 외래키가 나뉜 기록의 관계를 이어주므로 필요할 때 다시 조합할 수도 있다.그런데 잘 나누어 저장했다는 사실만으로 필요한 정보가 곧바로 나타나는 것은 아니다. 고객이 수십 명이고 주문이 몇백 건일 때는 어느 방식으로 찾아도 큰 차이가 없다. 몇 년이 지나 주문이 수백만 건으로 늘고, 장비마다 정비와 장애 이력이 계속 쌓이면 이야기가 달라진다. 정확하게 저장된 자료도 제때 찾지 못하면 실제 업무에서는 쓰기 어렵다.정규화가 같은 사실을 어디에 저장할 것인지 정하는 과정이었다면,.. 2026. 9. 17. 데이터 중복은 왜 문제일까? 정규화가 필요한 진짜 이유 주소를 한 번 바꾸었는데 어떤 화면에는 새 주소가 나오고, 다른 화면에는 예전 주소가 남아 있다면 어느 쪽을 믿어야 할까. 담당자가 한 곳을 빠뜨렸을 수도 있고, 두 시스템의 갱신 시각이 달랐을 수도 있다. 이용자에게는 단순한 불편처럼 보이지만 데이터를 관리하는 쪽에서는 꽤 까다로운 문제다.같은 사실을 여러 곳에 적어 두면 처음에는 편하다. 주문내역을 열었을 때 고객 이름과 주소까지 한 줄에서 볼 수 있기 때문이다. 그러나 이름이나 주소가 바뀌는 순간, 편리하게 복사해 둔 값은 모두 고쳐야 할 숙제가 된다. 한 군데라도 놓치면 데이터베이스 안에 서로 다른 답이 생긴다.앞선 글에서는 고객과 주문처럼 성격이 다른 대상을 별도의 테이블로 나누고, 기본키와 외래키로 관계를 잇는 방법을 살펴보았다. 이번에는 왜 .. 2026. 9. 13. 외래키는 왜 필요할까? 나누어진 테이블을 다시 연결하는 방법 회원정보 화면에는 이름과 연락처가 보이고, 주문내역 화면에는 상품명과 결제금액이 나타난다. 사용자는 두 화면을 오가면서도 주문한 사람과 주문 기록이 당연히 연결되어 있다고 여긴다. 하지만 데이터베이스 안에서는 고객과 주문을 한 표에 모두 적어 두지 않는 경우가 많다.고객 정보는 고객 테이블에, 주문은 주문 테이블에 나누어 저장한다. 한 고객이 주문을 열 번 했다면 고객의 이름과 주소를 열 번 반복해서 기록하는 대신, 주문마다 고객을 가리키는 값만 남긴다. 표는 떨어져 있지만 정보의 관계는 끊어지지 않는다.앞선 글에서 살펴본 기본키가 자기 테이블 안의 한 행을 구별하는 이름표라면, 외래키는 다른 테이블에 있는 그 이름표를 가져와 관계를 표시하는 값이다. 관계형 데이터베이스가 여러 표를 따로 보관하면서도 하.. 2026. 9. 3. 이전 1 2 3 4 5 6 7 다음
