데이터베이스 문서 작성 방법
(주의: 이것은 데이터베이스 구조를 문서화하는 방법에 가깝다는 것은 알고 있습니다만, 동일하지 않다고 생각합니다.)
저는 수백 개의 테이블과 뷰가 있는 데이터베이스를 가지고 있고모음이 거의 없고 문서도 없는 수수께끼 같은 이름을 가진 곳에서 작업을 시작했습니다또한 데이터베이스 스키마를 불필요하게 변경할 수 없습니다.또, 자신의 머신으로 테스트한 것(정기적으로 삭제해 재작성)을 제외하고, 데이타베이스에 손을 댈 수 없기 때문에, 누구에게도 도움이 되는 코멘트를 추가할 수 없습니다.
"토드"를 사용하여 ER 다이어그램을 작성하려고 했지만 48시간 동안 계속 실행해도 아무것도 보이지 않아 컴퓨터가 필요했습니다.저는 최근에 고용된 다른 직원들과 이야기를 나눴는데, 우리는 모두 특정 표나 그 열의 의미를 이해할 때마다 개발자 Wiki에서 업데이트해야 한다고 제안했습니다.
그럼 어떻게 하면 좋을까요?테이블/뷰와 그 열을 나열한 후 작성하면 됩니까?기본 툴은 Toad, Oracle의 "SQL Developer", MS Office 및 Visio입니다.
제 경험상 ER(또는 UML) 다이어그램은 가장 유용한 아티팩트가 아닙니다. 많은 수의 테이블이 있는 다이어그램(특히 역설계된 다이어그램)은 종종 아무도 배울 수 없는 매우 복잡한 혼란입니다.
참고로 사람이 읽을 수 있는 좋은 문서(아마도 시스템의 작은 부분에 대한 다이어그램으로 보충)가 가장 많은 마일리지를 제공합니다.여기에는 각 테이블에 대해 다음이 포함됩니다.
- 표의 의미와 사용 방법에 대한 설명(UI 등)
- 각 속성의 의미에 대한 설명(분명하지 않은 경우)
- 이 표에서 다른 표로의 관계(외부 키)에 대한 설명 및 그 반대
- 추가 제약 및/또는 트리거 설명
- 테이블에 접하는 주요 뷰 및 프로세서에 대한 추가 설명(아직 제대로 문서화되어 있지 않은 경우)
위와 같은 모든 것을 문서화하기 위해 문서화를 하지 마십시오. 당연한 것을 다시 기술하는 문서화가 사람들을 방해합니다.대신에, 처음에 당신을 혼란스럽게 했던 것에 집중하고, 몇 분 동안 정말 명확하고 간결한 설명을 쓰세요.이렇게 하면 이 테이블을 처음 접하는 다른 개발자들에게도 큰 도움이 될 것입니다.
이미 언급한 바와 같이 Enterprise Architect, Red Gate SQL Doc, 다양한 벤더의 빌트인 툴 등 이를 관리하는 데 도움이 되는 다양한 툴이 있습니다.그러나 툴 지원은 도움이 되지만(더 큰 데이터베이스에서는 중요하기도 하지만), 데이터베이스의 개념 모델을 이해하고 설명하는 힘든 작업을 수행하는 것이 진정한 성공입니다.이러한 관점에서 텍스트 파일로도 할 수 있습니다(Wiki 형식으로 하면 여러 사람이 공동으로 문서를 증분 추가할 수 있습니다.따라서 누군가가 무언가를 알아낼 때마다 문서를 빠르게 추가할 수 있습니다).
고려해야 할 것은 DBMS에 내장된 CONT 기능입니다.DBMS 자체의 모든 테이블과 모든 열에 코멘트를 붙이면 데이터베이스 시스템 내에 문서가 있습니다.
코멘트 기능을 사용해도 스키마 자체는 변경되지 않고 USER_에만 데이터가 추가됩니다.TAB_COMMENTS 카탈로그 테이블.
팀에서는 레거시 대규모 Oracle 및 SQL Server 데이터베이스를 문서화하는 데 유용한 접근 방식을 찾았습니다.Dataedo를 사용하여 데이터베이스 스키마 요소(데이터 사전)를 문서화하고 ERD 다이어그램을 작성합니다.Dataedo는 문서 저장소와 함께 제공되므로 모든 팀이 최신 문서를 온라인으로 문서화하고 읽을 수 있습니다.또한 데이터베이스(Oracle 주석 또는 SQL Server MS_Description)를 간섭할 필요가 없습니다.
먼저 스키마(트리거, 외부 키 등 모든 테이블, 뷰, 저장 프로시저 및 함수)를 가져옵니다.다음으로 논리 도메인/모듈을 정의하고 모든 오브젝트(드래그&드롭)를 그룹화하여 보다 작은 데이터베이스 청크를 분석 및 작업할 수 있도록 합니다.모듈별로 ERD 다이어그램을 작성하여 최상위 설명을 작성합니다.그런 다음 테이블과 뷰의 의미를 발견하면 각각에 대한 간단한 설명을 작성합니다.각 열에 대해 동일한 작업을 수행합니다.Dataedo를 사용하면 각 개체와 열에 의미 있는 제목을 추가할 수 있습니다. 개체 이름이 모호하거나 잘못된 경우 유용합니다.Pro 버전에서는 외부 키, 고유 키/제약 및 트리거를 설명할 수 있습니다.이것은 유용하지만 데이터베이스를 이해하는 데 필수적인 것은 아닙니다.
UI를 통해 문서에 액세스하거나 PDF 또는 대화형 HTML로 내보낼 수 있습니다(후자는 Pro 버전에서만 사용 가능).
여기서 설명하는 것은 일회성 작업이 아닌 연속적인 프로세스입니다.데이터베이스가 변경된 경우(예: 새 열, 보기) 정기적으로 문서를 동기화해야 합니다(데이터도와 두 번 클릭).
샘플 매뉴얼을 참조해 주세요.http://dataedo.com/download/Dataedo%20repository.pdf
문서 프로세스에 관한 가이드라인:
그림:
- 그림을 작게 읽고 읽을 수 있도록 합니다.중요한 표, 관계, 컬럼을 포함하기만 하면 됩니다.기본/비즈니스 키, 중요한 속성 및 관계 등 큰 그림을 이해하는 데 의미가 있는 것만을 포함합니다.
- 다이어그램의 키 테이블에 다른 색상을 사용합니다.
- 모듈당 여러 개의 다이어그램을 가질 수 있습니다.
- 가장 중요한 표(대부분의 관계)의 설명에 다이어그램을 추가할 수 있습니다.
설명:
- document.date 열에 "Document date"라는 설명을 쓰지 마십시오.굳이 덧붙일 게 없다면 그냥 비워두세요.
- 테이블에 저장된 객체가 유형 또는 상태를 가지고 있는 경우 테이블에 대한 일반적인 설명으로 나열하는 것이 좋습니다.
- 예상되는 형식을 정의합니다(예:텍스트 필드에 저장된 날짜의 경우 "mm/dd/yy",
- 모든 알려진/중요한 값을 나열합니다.예를 들어 상태 컬럼은 다음과 같습니다. "문서 상태:A – 활성, C – 취소됨, D – 삭제됨,
- 데이터 읽기 및 데이터 삽입/업데이트 기능/프로시저에 사용되는 뷰인 테이블에 API가 있는 경우 테이블 설명에 나열합니다.
- 행/열의 값이 어디서 나오는지를 설명합니다(절차, 형식, 인터페이스 등).
- 사용하지 않아야 하는 열에 대해 "비사용" 마크(또는 이와 유사)를 사용합니다(제목 열이 유용합니다. 설명 필드에 대신 사용해야 하는 필드를 설명하십시오).
DB 정의에는 엔터프라이즈 아키텍트를 사용합니다.스토어드 프로시저, 트리거 및 UML에 정의된 모든 테이블 정의를 포함합니다.이 프로그램의 3가지 뛰어난 특징은 다음과 같습니다.
- ODBC 연결에서 UML 다이어그램을 가져옵니다.
- DB 전체의 SQL 스크립트(DDL)를 한 번에 생성
- DB의 맞춤형 템플리트 문서를 생성합니다.
UML 도구 내에서 클래스/테이블 정의를 편집하고 포함된 문서로 완전한 설명을 생성할 수 있습니다.자동 생성된 문서는 MSWord를 포함한 여러 형식으로 만들 수 있습니다.스키마에는 테이블이 100개 미만으로 관리 가능합니다.
개발자로서 10년 이상 살아오면서 다른 툴에 이렇게 감동한 적은 없었습니다.EA는 Oracle, MySQL, SQL Server(복수 버전), PostGreSQL, Interbase, DB2 및 Access를 한 번에 지원합니다.제가 문제가 생겼을 때마다, 그들의 포럼에서 제 문제에 대한 답변을 신속하게 해주었습니다.강력추천!!
DB 변경이 들어오면 EA에서 SQL을 생성하여 버전 관리(svn)에 체크인합니다.Hudson을 사용하여 빌드하고 체크인한 SQL을 수정하면 스크립트에서 데이터베이스를 자동으로 빌드합니다.
이 답변은 키벨리의 위 내용을 확장한 것으로, 제가 상향 투표했습니다.사용 중인 EA 버전이 Object Role Modeling(개념 설계 vs. 논리적 설계 = ERD)을 지원하는 경우, 이를 역엔지니어링한 다음 풍부한 표현력으로 모델을 작성합니다.
저렴하고 가벼운 옵션은 Visiomodeler를 MS에서 무료로 다운로드하는 것입니다.
ORM(ORMDB)은 BL 객체 및 관계에 대한 IS 이외의 이해관계자와의 데이터베이스 설계 대화를 지원하고 장려하는 유일한 도구입니다.
리얼리티 체크 - DDL을 생성하는 동안 풀스톱 ERD 단계를 거칩니다.이 단계에서는 DDL에 문제가 없는지 여부를 확인할 수 있습니다.그렇지 않아요.직접 설계한 ERD의 약점을 알 수 있습니다.
ORMDB는 툴이 개념적일수록 시장이 작아진다는 원칙의 전형적인 사례입니다.여자애들은 그냥 즐기고 싶어하고 프로그래머들은 코드만 쓰고 싶어하죠
Wiki 솔루션은 하이퍼링크 및 협업 편집을 지원하지만 Wiki는 구성되고 최신 상태로 유지되는 사용자만 사용할 수 있습니다.사용하는 도구에 관계없이 문서 프로젝트의 소유권을 가질 누군가가 필요합니다.그 사람은 다른 지식인이 세부사항을 기입하는 데 관여할 수 있지만, 한 사람이 정보를 정리해야 합니다.
툴을 사용하여 리버스 엔지니어링을 통해 ERD를 생성할 수 없는 경우 TAD 또는 VISIO를 사용하여 직접 ERD를 설계해야 합니다.
수백 개의 객체가 있는 ERD는 박스나 행이 너무 많아 읽을 수 없기 때문에 개발자의 가이드로서 도움이 되지 않을 수 있습니다.이렇게 많은 개체가 있는 데이터베이스에는 수십 개의 테이블과 뷰가 각각 있는 "하위 시스템"이 있을 수 있습니다.따라서 이러한 서브시스템의 커스텀 다이어그램을 작성할 필요가 있습니다.툴을 사용하는 것이 아니라, 이러한 서브시스템의 커스텀 다이어그램을 작성할 필요가 있습니다.
또한 의사 ERD를 설계할 수 있습니다.여기서 테이블 그룹은 하나의 다이어그램에서 단일 객체로 표시되고 해당 그룹은 다른 다이어그램에서 확장됩니다.
단일 ERD 또는 ERD 집합은 이러한 복잡한 시스템을 문서화하기에 충분하지 않으며, OO 시스템을 문서화하는데 클래스 다이어그램보다 더 적절할 수 없습니다.ERD를 예로 들어 문서를 작성해야 합니다.각 테이블, 각 열 및 테이블 간의 관계에 대한 텍스트 설명이 필요합니다(특히 이러한 관계가 참조 무결성 제약으로 표시되지 않고 암묵적인 경우).
이 모든 것은 힘든 일이지만 그럴 가치가 있을 것이다.스키마가 문서화되어 있는 명확하고 최신 장소가 있으면 팀 전체가 혜택을 볼 수 있습니다.
같은 처지에 있는 동료 개발자와 함께 작업할 수 있는 여유가 있기 때문에 필요한 정보를 가장 쉽게 전달할 수 있는 방법을 물어보는 것이 좋습니다.우리 회사에는 100개가 넘는 테이블이 있는데, 상사가 모든 테이블이 연결되는 특정 세트 테이블에 대해 ERD를 주었습니다.1개의 대규모 ERD를 여러 개의 작고 관리하기 쉬운 ERD로 분할하는 것이 좋습니다.
그림 한 장이면 천 개의 단어를 알 수 있기 때문에 테이블 간의 관계를 한눈에 볼 수 있는 ER 도표를 만드는 것을 추천합니다.이것은 텍스트만의 설명으로는 하기 어려운 것입니다.
데이터베이스 전체를 하나의 다이어그램으로 구성할 필요는 없습니다. 여러 섹션으로 나눕니다.우리는 직장에서 Visual Paradamy를 사용하고 있지만 EA는 ERWIN과 마찬가지로 좋은 대안이며, 그 밖에도 마찬가지로 좋은 것이 많이 있습니다.
인내심이 있다면 html을 사용하여 표와 열을 문서화하는 것이 문서에 쉽게 액세스할 수 있습니다.
최종 사용자에게 데이터베이스를 설명하는 것이 주요 목표라면 Ooluk Data Dictionary Manager가 도움이 됩니다.웹 기반 다중 사용자 소프트웨어로 테이블 및 열에 설명을 첨부할 수 있으며 이러한 설명에 대한 전체 텍스트 검색을 허용합니다.또한 라벨을 사용하여 테이블을 논리적으로 그룹화하고 라벨을 사용하여 테이블을 참조할 수도 있습니다.테이블과 열을 태그하여 데이터베이스/데이터베이스 전체에서 유사한 데이터 항목을 찾을 수 있습니다.
이 소프트웨어를 사용하면 API를 사용하여 테이블 이름, 열 이름, 열 데이터 유형, 외부 키 등의 메타데이터 정보를 내부 저장소로 가져올 수 있습니다.JDBC 데이터 소스 지원은 내장되어 있으며 API 소스가 ASL 2.0으로 배포되므로 더욱 확장할 수 있습니다.많은 RDBMS에서 코멘트/리마크를 읽도록 코드화되어 있습니다.가져온 정보는 언제든지 수동으로 재정의할 수 있습니다.테이블 및 열에 대해 저장할 수 있는 정보는 사용자 정의 필드를 사용하여 확장할 수 있습니다.
Data Dictionary Manager는 관계형 데이터베이스를 위해 특별히 설계되지 않았기 때문에 테이블과 열 대신 "데이터 개체" 및 "속성" 용어를 사용합니다.
메모들
- 트리거, 인덱스, 통계 등 데이터베이스의 기술적 측면을 설명하는 것이 중요한 경우 이 소프트웨어는 최적의 옵션이 아닙니다.단, 하이퍼링크 커스텀필드를 사용하여 기술 솔루션을 이 소프트웨어와 조합할 수 있습니다.
- 소프트웨어가 ERD를 생성하지 않음
공개:저는 이 제품을 개발하는 회사에서 일하고 있습니다.
언급URL : https://stackoverflow.com/questions/369266/how-to-document-a-database
'programing' 카테고리의 다른 글
| 커스텀 컨트롤과 사용자 컨트롤 (0) | 2023.04.09 |
|---|---|
| WooCommerce 3에서 'woocommerce_grouped_children_args' 필터가 제거되었기 때문에 제품 자식을 그룹화하여 주문할 수 있습니다. (0) | 2023.04.04 |
| 리액트 라우터 네비게이션바 예시 (0) | 2023.04.04 |
| Webpack / Babel / React 빌드 오류: "알 수 없는 옵션: foo/node_modules/react/react.js.아이들" (0) | 2023.04.04 |
| MongoDB 고유의 집약 (0) | 2023.04.04 |