ER 다이어그램의 중요성

저는 학생이며 학계의 일환으로 여러 프로젝트를 개발하고 있습니다.

프로젝트 중 하나에 대한 데이터베이스를 개발하는 동안 우리는 ERD가 필요한지 아닌지에 대한 상황을 발견했습니다. 지금 우리 모두가 ERD를 먼저 개발 한 다음 데이터베이스를 개발하는 데 동의하지는 않습니다.

대부분의 사람들은 종이에 직접 요구되는 시스템에 따라 구두로 데이터베이스를 개발하는 것을 선호합니다.

이제 저는 데이터베이스 원칙을 엄격히 따릅니다. 데이터베이스는 ERD에서만 개발해야한다고 생각합니다. 그래서 나는 단지 다음을 알고 싶습니다.

• 업계가 이러한 원칙을 따르고 있습니까?
• ERD 개발에 시간을 낭비하고 있습니까?
• ERD 개발의 이점은 무엇입니까?

간단하고 간단합니다. ERD가없는 데이터베이스를 건물 계획없이 집을 짓는 것으로 생각하십시오. 단순히 벽돌을 다른 벽돌 위에 놓는 것만으로도 무언가를 짓기에 충분하다고 생각하기 때문에 가능할 수 있지만 재난 가능성이있는 프로젝트를 누군가가 책임지는 순간.

내 경험상 ERD를 CASE 도구 (ERWin, MySQL Workbench 등)와 함께 사용하지 않으면 ERD의 이점을 크게 얻지 못하므로 순방향 및 역방향 엔지니어링과 같은 실제로 유용한 작업을 수행 할 수 있습니다. 이러한 기능이 없어도 완전한 데이터베이스에 대한 중앙 집중식 회로도를 보유한 경우에도 유용합니다. 때로는 데이터베이스 자체에 구현 된 제약 조건이 특정 데이터베이스 엔터티 간의 관계에 대한 전체 내용을 설명하기에 충분하지 않기 때문입니다.

아시다시피 MyISAM 및 InnoDB와 같은 여러 내부 스토리지 엔진을 구현하는 MySQL 관련 예제가 있습니다. MyISAM이 제약 조건을 지원하지 않는 가장 중요한 것 중 하나는 그들 사이에 중요한 차이점이 있습니다. 이러한 사실에도 불구하고 MyISAM은 웹 응용 프로그램에 많이 사용되므로 관계 논리는 비즈니스 논리 (응용 프로그램 코드) 또는 다른 방법으로 구현되어야합니다. 문제는 MyISAM 테이블 (엔티티)을 사용하여 ERD를 포워드 엔지니어링 할 때 MySQL은 ERD에 의해 설정된 제약 조건을 자동으로 무시하고 엔터티 간 관계의 특성을 명확하게 식별하지 못하는 데이터베이스를 갖게됩니다. 다시 말해서 데이터베이스 레이아웃을 개발 한 후 코드 개발자가 ERD없이 적절한 비즈니스 로직을 구현할 수있는 방법이 없습니다.

ERD는 데이터베이스 구조를 명확하게 파악하는 것이 좋습니다. 프로젝트에 중요한 문서 아티팩트 일뿐 아니라 쿼리, 특히 테이블 간 조인을 구현해야 할 때 쉬워집니다. 왼쪽에 ERD가 있고 오른쪽에 쿼리 편집기가있는 듀얼 모니터 구성이 얼마나 좋은지 상상해보십시오. 테이블 간의 관계를 명확하게보고이를 기반으로 쿼리를 작성할 수 있습니다. 데이터베이스 프로젝트가 매우 단순하고 프로젝트에 필요하지 않은 경우 데이터베이스가 없어도 괜찮습니다.

ERD는 생각보다 훨씬 많은 시간을 절약 해줍니다. 즉석에서 모든 작업을 수행하면 접합 테이블을 생성하려고 할 때 멈출 것입니다.

몇 년 후 ERD없이 데이터베이스를 접하게되면 프로젝트에서 무슨 일이 일어나고 있는지 알기 위해 많은 시간을 소비해야합니다.

나는 회사가 있고 우리는 ERD를 디자인하고, ERD가없는 데이터베이스에 대해 생각하지 않습니다. (실제로 이것은 내 자신의 개인적인 실험입니다)

ERD는 얼마 전에 더 주류였습니다. IMO는 이제 다소 선택적입니다.

현재, 일부 성공한 팀은 ERD를 전혀 신경 쓰지 않지만 강력하고 성능이 뛰어나며 장기적으로 유지 관리하기 쉬운 우수한 시스템을 제공합니다. 이것은 최소한의 도구 세트로 소규모로 시작할 때 애자일 개발에서 특히 그렇습니다.

ERD는 물론 의사 소통의 좋은 방법이지만, 모든 상황에서 유일한 방법이거나 최선의 방법은 아닙니다. 일부 팀은 다른 방식의 문서화 및 커뮤니케이션을 선호합니다.

이 산업에는 담요 규칙이 없습니다.

프로덕션 코드를 작성하기 전에 디자인하는 것이 중요합니다. 프로토 타입을 만드는 것도 중요합니다. 데이터베이스 사람들은 SQL을 작성하여 프로토 타입을 개발합니다. (프레드 브룩스가 프로토 타입에 대해 말한 것을 기억하십니까?)

ER이 하나 인 그래픽 언어는 이해하기 쉽고 간단한 방식으로 데이터베이스의 모든 의미를 캡처하는 데 매우 적합하지 않은 것으로 입증되었습니다.

또한 개발자 간을 제외하고는 매우 효과적인 커뮤니케이션 도구로 입증되지 않았습니다. 그러나 데이터베이스를 설계 할 때 개발자 간의 중요한 커뮤니케이션은 아닙니다. 개발자와 도메인 전문가 사이 (개발자와 비즈니스 사람 사이)입니다.

ORM (Object-Role Modeling) 에는 그래픽 언어가 있지만 "사실"(간단한 문장)을 기반으로합니다. 비즈니스 사람들은 사실을 쉽게 확인할 수 있습니다. 비즈니스 사람들 은 ER 다이어그램 또는 ORM 다이어그램을 쉽게 확인할 수 없습니다 .