태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.

'공지'에 해당되는 글 1건

댓글로 질문해주세요.

어떤 질문도 무관합니다.

공개가 곤란하면 비밀댓글로 해주세요.

자세한 내용은 이메일로 주셔도 됩니다.

bluepupi@gmail.com

'공지' 카테고리의 다른 글

질문하시면 성심껏 답변드리겠습니다  (39) 2011.07.02
블로그 이미지

블루퍼필

댓글을 달아 주세요

  • 2011.07.05 12:54  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

    • 블루퍼필 2011.07.05 13:34 신고  댓글주소  수정/삭제

      예.. 물론이죠.
      모델을 이메일로 보내주시면 가능한 범위내에서 검토한 후 제 의견을 메일로 보내드리겠습니다.
      실제 모델을 보고 생각하는 게 저한테도 많은 도움이 됩니다.

  • infordb 2011.07.15 01:43  댓글주소  수정/삭제  댓글쓰기

    관계형 데이터 모델 페이지 289에 관한 내용입니다.

    [그림 9.8]일반적인 코드 모델

    SELECT A.계좌번호, B.코드명
    FROM [거래내역] A, [코드] B
    WHERE A.매수매도구분코드 = B.코드값
    AND B.코드유형코드 = '001' /*매수매도구분코드*/
    AND A.계좌번호 = '123456789'


    문의 1) 코드 테이블의 키가 #코드유형번호, #코드값으로 복합키입니다.
    그런데, 업무테이블(계좌번호)에 관계를 통해 코드유형번호와 코드값이 속성으로 생성되었을겁니다.
    그럼에도 불고하고, B.코드유형코드 = '001' /*매수매도구분코드*/ 소스에 하드코딩하는 이유가 있나요?


    문의 2) 업무테이블에서 코드테이블의 키 2개를 내려받고, 아래와 같이 사용해야 되지 않는지요?

    SELECT A.계좌번호, B.코드명
    FROM [거래내역] A, [코드] B
    WHERE A.매수매도구분코드 = B.코드값
    AND A.매수매도유형코드 = B.코드유형번호 --> 수정부분
    AND A.계좌번호 = '123456789'

    • 블루퍼필 2011.07.15 19:47 신고  댓글주소  수정/삭제

      우선 코드를 관리하는 방법은 다양할 거 같습니다.
      시스템이나 사람 등 환경에 따라서요.

      그중에 하나를 제가 설명했고, 저는 가장 효과적이라 생각합니다.

      말씀하신 방법도 가능하지만, 최근에는 덜 사용하는 방법입니다.
      거래내역 테이블에 ~코드 속성이 10~20개가 있을텐데, 유형까지 관리하면 너무 많은 속성이 생겨서요.

      하지만 이게 결정적이진 않아서 성향에 따라 몇 가지 방법이 사용되는 거 같습니다.

    • infordb 2011.07.16 09:04  댓글주소  수정/삭제

      답변 감사합니다. ^^
      그렇다면 코드 테이블의 키는 2개 인데, 업무테이블(거래내역)에는 키를 하나만 가져간다는 말씀이신거죠
      즉 코드테이블과 업무테이블의 관계를 연결하지 않는다는 것이죠?

      정합성을 위해서는 연결해야 할것 같고, 그렇다고 업무 테이블에서 각 코드마다 키를 2가 가져가기는 부담스럽고, 유형과 실제코드를 대표하는 인조키로 가져가는 방법 등 코드를 관리하는 방법은 다양한 것 같습니다. 프로젝트 상황에 맞게 사용해야 할것 같은데, 그렇다면 프로젝트에서 코드방식을 선택할 때, 어떤 기준에 따라 선택을 해야할지? 혹시 기준이 있나요?

    • 블루퍼필 2011.07.16 23:08 신고  댓글주소  수정/삭제

      예.. 맞습니다.
      말씀하신대로 위와 같은 방법이라면 코드 테이블과 업무 테이블은 관계선을 연결하지 않습니다.

      대형 프로젝트에서 코드 설계는 DA(모델러 아님)나 공통팀(표준화팀), 프레임워크나 메타 시스템에 따라 달라지는데요. 기준이 있다고는 생각하지 않지만 관습이 있는 거 같아 숙고할 필요가 있습니다.

      저는 [9.10]이 가장 효과적이라고 생각합니다.

  • infordb 2011.07.15 01:50  댓글주소  수정/삭제  댓글쓰기

    관계형 데이터 모델 페이지 291, 292에 관한 내용입니다.

    [그림9.10]코드유형과코드를 통합관리하는모델

    [그림9.11[순환관계로상위코드를 관리하는모델

    위 2 모델의 차이를 모르겠습니다. 제 생각에는 구조도 동일하고 단지 [그림9.10]에서 순환관계를 누락한 것으로 보입니다.

    그리고 순환관계가 구조적으로 더 유연해서 확정성이 좋지 않나요?

    • 블루퍼필 2011.11.30 23:21 신고  댓글주소  수정/삭제

      [9.10]과 [9.11]은 유사합니다.

      다른 부분은 순환관계로 관리하느냐와 데이터를 어떻게 생성하냐죠.

      순환구조가 보통은 확장성이 많이 좋은데 이 경우는 비슷한 거 같아 [9.10]을 먼저 설명했습니다.
      그리고 일반적으로 알고 있는 [9.11]은 생략하면 안 될 거 같아서 추가했고요

  • 지현명 2012.02.21 09:11  댓글주소  수정/삭제  댓글쓰기

    테이블 설계시에 컬럼들의 순서를 정하는 룰같은게 있나요? 회원테이블 같은경우
    회원번호/주민번호/고객명/가입매장/연락처/주소 ..이런식으로 하는데...이렇게 컬럼순서를 정하는 룰이 있으면 알려주세요

    • 블루퍼필 2012.02.22 12:59 신고  댓글주소  수정/삭제

      모델에서 컬럼의 순서는 덜 중요합니다.

      룰이 있다면 자주 사용되는 속성이 위쪽에 있는 것이 가독성에 좋고요.
      Not Null 속성이 위쪽에 있는 것이 좋습니다.

      저는 식별자(후보,대체)와 기초 속성을 위쪽으로 배치합니다.

  • lee 2012.03.23 10:10  댓글주소  수정/삭제  댓글쓰기

    필수(Mandatory) 속성 & 선택(Optional) 속성 에댜하여
    설명과 예제 부탁 드립니다

    • 블루퍼필 2012.03.25 09:39 신고  댓글주소  수정/삭제

      필수 속성은 테이블에 데이터가 인서트될 때 값이 반드시 필요한 속성입니다.

      예를 들어 고객 테이블에 고객명, 고객주민등록번호 등이 필수 속성일 수 있고요.

      닉네임, 취미 등은 반드시 입력하지 않아도 되는 선택 속성일 수 있습니다.

      설명이 더 필요하면 메일 보내주세요.

  • 윤봉운 2012.07.26 18:03  댓글주소  수정/삭제  댓글쓰기

    enq : TX - row lock contention 대기 이벤트에 대한 설계적 관점에서의 튜닝 방법이 있을까요?

    로그인 정보를 관리하는 테이블이 있는데
    동시접속에 의해 위의 대기이벤트가 극심하게 나타납니다. update에 의해 발생하고 1건당 거의 16초나 걸립니다.

    update logoninfo
    set last_logontime =systimestamp
    where acount_id=:1

    같은 아이디가 로그인할때 마다 최종접속시간을 계속 갱신합니다.

    제 생각에는 update를 하지말고 자식테이블을 하나 만들어서 insert를 전부 해버리도록 바꾸고 select를 할때 최종로그인 시간값만 읽어오도록 바꿔주면
    해결되지 않을까 생각하는데
    이렇게 관리하는걸 선분이력이라고 하나요? 그리고 이 경우의 대기이벤트를 해소하기 위한 설계 지침이 있을까요?

    • 블루퍼필 2012.07.30 22:28 신고  댓글주소  수정/삭제

      안녕하세요.
      동료 전문가한테 물어보느라 답변이 늦었습니다. ㅎ

      logoninfo 엔터티가 로그인 정보를 관리하는 엔터티인 거 같은데요. 아이디(acount_id) 속성만 PK인 거 같고요.
      그래서 update가 생기는 것 같은데요.

      모델링 관점으로 보면요.
      말씀하신대로 insert하는 방식이 돼야 할 거 같습니다.

      따라서 로그인한 내역을 관리하는 엔터티가 있어야 할 거 같습니다. 이 내역에서 최종값을 뽑아 별도의 엔터티에서 관리할지는 무관하게요. 최종값은 추출 속성이죠.

      그런데 추출 속성은 관리하지 않는 것이 좋을 거 같습니다. row lock 이벤트 때문에요.

      row lock 이벤트를 없애는 방법은... 혹시 for update 구문을 사용했다면 이 구문과 commit 사이의 로직을 줄이는 방법이 있다고 하고요.

      혹시 last_logontime 속성에 인덱스를 생성했다면 삭제하는 게 좋다고 합니다.

      원론적으로 튜닝은 플랜 보면서 해봐야 알 거 같지만요.
      로그인 내역을 관리하는 엔터티는 필요할 거 같습니다.

  • 윤봉운 2012.07.31 16:07  댓글주소  수정/삭제  댓글쓰기

    답변 감사드립니다. 결국 현재 운영방식이
    추출 속성을 관리함에 따른 성능 악화라고
    볼 수 있겠네요. 추출 속성 관리의 문제가 설계 지침이 되겠군요.

    어제 선생님 책 구입했는데 지금 찾아보니까 270페이지 정도쯤에 이 내용이 나오네요.

    프리미엄 가이드 틈틈이 읽어 볼 생각인데 흥미있어 지네요 ^^

    • 블루퍼필 2012.07.31 22:57 신고  댓글주소  수정/삭제

      감사합니다.
      덕분에 저도 도움이 됐습니다.

      혹시 모델러가 목표시라면 틈틈이 3~4번 읽어보세요. ㅎ

      열공하실 거 같네요.
      잠언 문구가 마음에 드셨다면 틀림없이...

  • 윤봉운 2012.07.31 16:11  댓글주소  수정/삭제  댓글쓰기

    잠언에 프로페셔널에 관한 이렇게 멋진 문구가 있는지 몰랐네요.
    책장 넘기다 확 소름이 돋았네요. ^^

  • 방정문 2013.07.04 13:45  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 관계형 데이터 모델링 프리미엄 가이드로 공부중입니다.
    100p [그림 4.29] BC정규형에서 그림4.28 [예제1]의 정규형에 해당하는 내용이 누락되어 있습니다.
    책은 2013년 4월 10일 출간된 2쇄입니다.

    • 블루퍼필 2013.07.04 22:37 신고  댓글주소  수정/삭제

      예.. 2쇄에서 누락됐습니다.
      최종 검판용 파일에는 정상인데, 인쇄 시 누락된 거 같습니다.
      책을 소중하게 생각하는 사람으로서 죄송하게 생각합니다.

      해당 이미지는 아래에 올렸습니다.
      http://dataprofessional.tistory.com/103

  • 2013.07.14 08:11  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  • 방정문 2013.07.15 15:35  댓글주소  수정/삭제  댓글쓰기

    안녕하세요.
    초판도 아니고 2쇄인데, 누락된 내용이 너무나 많네요..;;

    316p [그림 10. 1] 종속 관계의 엔티티
    324p [그림 10.12] 엔티티 사이에 많은 관계가 발생한 모델
    327p [그림 10.16] 고유 속성을 가지는 관계 엔티티
    328p [그림 10.17] 중복 속성을 갖는 관계 엔티티
    335p [그림 10.26] 양쪽 옵셔널리티가 선택(Optional)인 집합

    위 내용들이 누락되었습니다. 저번처럼 답변 부탁드립니다.

    책은 2013년 4월 10일 출간된 2쇄입니다.

    • 블루퍼필 2013.07.15 22:21 신고  댓글주소  수정/삭제

      죄송합니다. 확인해 보니 정말 많네요.
      생각지도 못해서 어떻게 해야될지 모르겠습니다.
      이미지들은 곧 올리겠습니다.

    • 방정문 2013.07.19 16:32  댓글주소  수정/삭제

      답변 감사합니다. 이미지 누락은 아쉽지만.. 빨리 올려주신 덕분에 끊기지 않고 계속 공부하고 있습니다.^^
      이름을 바꿔도 '귀하는 차단되었으므로 사용하실수 없습니다.'는 메시지가 나옵니다.

  • 방정문 2013.07.15 16:44  댓글주소  수정/삭제  댓글쓰기

    320p 3번째 단락 '바로 위의 관계 이외에ㄱ도' 오탈자있습니다.

    408p 밑에서 3번째 단락에 '현행 데이터베이스가 존재한다는 것은 업무 요건이 많다는 것을 의미하고' 라고 나와 있는데 이해가 잘 되지 않아 추가 설명 문의드립니다.

    • 블루퍼필 2013.07.15 22:27 신고  댓글주소  수정/삭제

      현행 DB에는 요건을 다양하게 이미 사용하기 있다는 의미입니다. 현행 DB가 없으면 요건을 만들어야 하기 때문에, 사용하고 있는 것에 비해 요건이 없을 수 있다는 의미입니다.

  • 꼬랑지 2013.08.21 06:19  댓글주소  수정/삭제  댓글쓰기

    수퍼-서브타입의 경우 물리단계에서 여러가지 모양으로 테이블이 도출되는데 논리단계에서 인스턴스 샘플을 작성할 수 있는지 궁금합니다. [고객]이 있고 서브타입으로 <개인고객>,<사업자고객이 있습니다. 공통속성으로는 고객번호,고객명,고객구분이 있고 <개인고객>에는 주민번호,취미,결혼여부가, <사업자고객>에는 사업자번호,대표자명,업종,업태 속성이 있습니다. 이 엔터티의 개인,사업자고객에 대한 인스턴스 샘플을 작성할 때 두개다 10개의 속성을 가지는 가요 아니면 개인의 경우 6개,사업자의 경우 7개의 속성을 가지는가요?

    • 블루퍼필 2013.08.26 16:29 신고  댓글주소  수정/삭제

      물리 모델이 결정되기 전의 서브타입이라면 슈퍼타입, 서브타입에 대해 각각 인스턴스 샘플을 작성해야 될 거 같습니다.

      고객 엔터티에 3개 속성, 개인고객 엔터티에 4개(고객번호 포함), 사업자고객 엔터티에 5개 속성이 있을 거 같습니다.
      위와 같이 사례 인스턴스를 만들면 배타/포함 서브타입인지, 완전/불완전 서브타입인지도 알 수 있어 더욱 좋고요.

      물리가 결정되기 전인데 개인고객, 사업자고객 엔터티만 사례 데이터를 작성하면 마치 정해진 거 같아서 혼란스러울 거 같고요. 만약 작성한다면 전체 10개 속성으로 작성해서, 개인고객 인스턴스는 6개 속성만 채워지고, 사업자속성 인스턴스는 7개 속성이 채워지도록 작성하면 될 거 같습니다.

    • 꼬랑지 2013.08.30 08:44  댓글주소  수정/삭제

      10개의 속성으로 해서 인스턴스 샘플을 작성해야 하는 것이 맞군요. 답변 감사합니다

  • 소영아빠 2013.09.04 22:37  댓글주소  수정/삭제  댓글쓰기

    지인의 추천으로 책을 구입하여 보고 있습니다.
    저자께서 실무에서 터득한 지식이라 그런지 제가 실무에서 한번쯤 고민하고 막혔던 기억이 나는 문제들이 많이 설명되어 있네요
    다만, 쉬우면서도 잘 이해가 안 가는 부분이 보이네요 ㅠ

    다시 한번 정독을 하면서
    모르는 것은 질문을 올리겠습니다.

    좋은 책을 만나게 되어서 기쁩니다.

    건승하시길 바랍니다.
    꾸벅..

  • 2013.10.08 11:21  댓글주소  수정/삭제  댓글쓰기

    비밀댓글입니다

  • 제피에취한귀촉 2013.12.24 13:11  댓글주소  수정/삭제  댓글쓰기

    안녕하세요^^
    모델링을 잘 몰라서 공부하고 있는 직장인입니다.
    덕분에 많은 도움을 받고 있습니다. 감사드려요.
    질문드리고 싶은 것은, 예전글을 보니, 예제를 보다 많이 넣은, 모델링 책을 출판할 계획이라는 것을 보았습니다. 계획이 여전히 유효한가요? 언제쯤 출간되려나요^^ 감사합니다.

    • 블루퍼필 2014.01.07 16:33 신고  댓글주소  수정/삭제

      막상 쓰고 보니 예제가 많은지는 모르겠습니다. ㅎ
      다만 좀 더 세분화해서 책을 썼고요.
      현재 인쇄 들어가서 몇일 내로(1월 15일 정도) 서점에 배포될 거 같습니다.
      새해 복 많이 받으세요.

  • 이상정 2014.04.07 23:30  댓글주소  수정/삭제  댓글쓰기

    관계형 데이터 모델링 프리미엄 가이드
    정오표 가 있나요?
    제가 잘 못찾는건지 찾기가 힘드네요.

    • 블루퍼필 2014.04.09 14:59 신고  댓글주소  수정/삭제

      별도의 프리미엄가이드 정오표는 없습니다. ㅎ

      2판에서는 발견된 오타를 수정했는데요.
      이미지 누락이 있어서 아래 블로그로 올렸습니다.

      http://dataprofessional.tistory.com/103

  • 밥바라기 2015.11.11 10:13  댓글주소  수정/삭제  댓글쓰기

    안녕하세요. 김기창 이사님.
    현재 관계형 데이터 모델링 프리미엄 가이드를 통해 많이 배우고 있습니다.

    다른 아니라 책 296P 보면 [그림 9.14]에
    '코드이력' 엔터티가 '코드유형'의 하위 엔터티로 그려져 있는데 '코드' 엔터티의 하위 엔터티로 그려지면 틀린 것인지 궁금합니다.
    ('코드' 일 대 다 '코드이력' )

    • 블루퍼필 2016.03.20 15:52 신고  댓글주소  수정/삭제

      답변이 너무 늦었네요.
      이메일 등의 정보가 없어서 그냥 답변으로 올립니다.

      댓글로 설명하기에는 좀 어렵네요. ㅎ
      책에는 비교적 자세히 설명을 적었는데요.
      간단히 요약하면 코드에 대한 이력 관리를 어떤 방식으로 하는지에 따라 달라지고요.
      저는 코드 인스턴스가만을 관리하는 게 의미가 없을 거 같아서 코드유형 엔터티와의 관계로 설계했습니다.
      사례 데이터를 만들어 보시는 것도 관계를 이해하는 데 도움이 될 거 같습니다.

      감사합니다.