정확도가 떨어지는 잡학다식 : The 2nd Stage

ietranger.egloos.com

방명록

 


"도서관 통합서비스 환경 구축 지침"이란 것을 봤는데... 이런저런 이야기

휴... 한숨만 나온다.

여전히 파일 시스템 기반의 사고에서 벗어나지 못하고 있다.

바로 이것은 정규화의 문제와 직결된다.

RDBMS를 이용하면서 데이터를 정규화하지 않고 사용하는 것은 아무런 의미가 없다.

이렇게 하면 데이터베이스는 그냥 저장소에 불과하다.

그리고 RDBMS와 데이터 모델링과 데이터 표준화에 대한 이해가 반영되어 있지 않다.

표준화인 것처럼 보이지만, 동음이의어를 각각 도메인으로 지정하면서 서로 다른 데이터 길이를 지정하고 있다.

설명에서도 일자와 시간이라면서 일자라고 정의하고 있다. 설명도 오류다.

명백한 구조적 모순이자 결함이다.

그리고 NULL 허용 여부에 있어서는 엔티티가 생성되는 수준, 즉 이것이 핵심 엔티티인지, 핵심 엔티티의 관계에서 생성되는 메인 엔티티인지에 대해서도 이해가 부족하다.

즉, 한 인스턴스가 생성될 때, 거기에 필수적인 데이터임에도 불구하고 이것을 뜬금 없이 NULL 허용으로 정의했다.

당장에 물리 수준에서 시스템 감사 컬럼이 추가될 것인데, 그것과 모순되는 상황이 발생하는 것이다.

시스템 감사 컬럼은 데이터 로그 기록 목적인데, 핵심 속성에 NULL이 허용됨으로써 엉뚱하게 보조 컬럼이 핵심 속성으로 전용되는 어처구니 없는 일이 발생할 수도 있게 되는 것이다.

말이 안된다.

그 데이터는 이벤트가 발생하여 튜플(즉, 인스턴스나 로우)이 신규로 테이블에 삽입될 때, 반드시 들어가야 하는 데이터다.

그리고 시스템에 결합하여 사용하는 보조 자동화 시스템들은 오프라인 처리에 대한 기준이 들어 있지 않다.

그런데 거기에 개별적으로 저장해야 하는 데이터들의 길이를 명시했다.

오프라인 처리에 대한 기준 없이 그런 정의를 하는 것은 무의미하다.

DB에 그냥 해당 UID를 넣으면 되는 거다.

MARC를 더 이상 데이터의 저장 기준이나 형식으로 생각하면 안된다.

이것은 데이터를 교환하는 포맷이다.

즉, 관계형 데이터베이스의 개념을 생각하면 이런 식의 가이드라인은 혼선만을 초래할 뿐이다.

그리고 거기에 저장된 데이터가 텍스트 등으로 추출되어야 할 때, MARC 형식으로 만들어지면 되는 것이다.

규약(프로토콜)을 정의한다면서 모순이 확연히 드러나는 것을 공식 지침으로 그냥 내보내다니...

공청회하면서 학위 가진 교수들이 이거 하나 못 잡아내나?

데이터베이스에 대한 기본적인 이해 부족이 이런 엉터리 가이드라인을 만들어냈다고 밖에 할 수 없다.

어처구니가 없다.

덧글

  • 천하귀남 2013/12/09 15:09 #

    워낙 말도 안되는 상황을 그나마 건의조차 불가능한 경우가 많아 관공서쪽 IT일은 절대 안하고 있습니다. ^^;
  • 떠리 2013/12/09 15:53 #

    즉, 한 인스턴스가 생성될 때, 거기에 필수적인 데이터임에도 불구하고 이것을 뜬금 없이 NULL 허용으로 정의했다. <-- 호옹이?!
※ 로그인 사용자만 덧글을 남길 수 있습니다.