배경

저는 CS 학생입니다. 아빠의 소기업을 위해 아르바이트를하고 있습니다. 실제 응용 프로그램 개발 경험이 없습니다. 저는 파이썬으로 스크립트를 작성했고 C에서는 몇 가지 코스워크를 작성했지만 이와 같은 것은 없습니다.

아빠는 소규모 교육 사업을하고 있으며 현재 모든 수업은 외부 웹 응용 프로그램을 통해 예약, 기록 및 추적됩니다. 내보내기 / "보고서"기능이 있지만 매우 일반적이며 특정 보고서가 필요합니다. 쿼리를 실행하기 위해 실제 데이터베이스에 액세스 할 수 없습니다. 맞춤 보고서 시스템을 설정하라는 요청을 받았습니다.

내 생각은 일반적인 CSV 내보내기를 만들고 매일 밤 사무실에서 호스팅되는 MySQL 데이터베이스로 가져 와서 필요한 특정 쿼리를 실행할 수있는 것입니다. 데이터베이스에 대한 경험은 없지만 기본 사항을 이해합니다. 데이터베이스 작성 및 일반 양식에 대해 조금 읽었습니다.

우리는 곧 해외 고객을 확보하기 시작할 수 있으므로 데이터베이스가 폭발 할 경우 폭발하지 않기를 바랍니다. 우리는 또한 현재 여러 부서 (예 : ACME 모회사, ACME 건강 관리 부서, ACME 보디 케어 부서)를 가진 대기업을 고객으로두고 있습니다.

내가 생각해 낸 스키마는 다음과 같습니다.

1. 클라이언트 관점에서 :
   • 고객이 메인 테이블입니다
   • 고객은 근무하는 부서에 연결되어 있습니다.
     • 런던 HR, 스완 지 마케팅 등 전국에 부서가 흩어져있을 수 있습니다.
     • 부서는 회사의 부서와 연결되어 있습니다
   • 부서가 모회사와 연결됨
2. 수업 관점에서 :
   • 세션은 메인 테이블입니다
     • 선생님은 각 세션에 연결되어 있습니다
     • 각 세션에 statusid가 제공됩니다. 예 : 0-완료, 1-취소
     • 세션은 임의 크기의 "팩"으로 그룹화됩니다.
   • 각 팩은 클라이언트에게 할당됩니다

나는 종이에 스키마를 "디자인 (더 이상 낙서처럼)"하여 3 차 형식으로 정규화하려고 노력했다. 그런 다음 MySQL Workbench에 연결하여 모두 나에게 좋게 만들었습니다 :
( 대형 그래픽을 보려면 여기를 클릭하십시오 )

_{(출처 : maian.org )}

내가 실행할 예제 쿼리

• 신용이 남아있는 고객 중 아직 활동이없는 고객 (향후 수업이없는 고객)
• 고객 / 부서 / 구간당 참석률은 얼마입니까 (각 세션의 상태 ID로 측정)
• 한 달에 교사의 수업 수
• 출석률이 낮은 고객에게 신고
• 부서에있는 사람들의 출석률이있는 HR 부서에 대한 사용자 정의 보고서

질문

• 이것이 과도하게 설계되었거나 올바른 방향으로 가고 있습니까?
• 대부분의 쿼리에 여러 테이블을 조인해야 성능이 크게 향상됩니까?
• 아마도 일반적인 쿼리 일 것이므로 클라이언트에 'lastsession'열을 추가했습니다. 이것이 좋은 생각입니까, 아니면 데이터베이스를 엄격하게 정규화해야합니까?

시간 내 줘서 고마워

귀하의 질문에 대한 추가 답변 :

1) 이와 같은 문제에 처음으로 접근하는 사람에게는 거의 목표가 있습니다. 나는이 질문에 대한 다른 사람들의 포인터가 지금까지 거의 그것을 덮고 있다고 생각합니다. 잘 했어!

2 & 3) 당신이 취할 수있는 성능은 특정 쿼리 / 프로 시저에 대한 올바른 인덱스와 더 중요한 레코드의 양을 갖고 최적화하는 데 크게 좌우됩니다. 주 테이블에서 백만 개가 넘는 레코드에 대해 이야기하지 않는 한 합리적인 하드웨어에서는 성능이 문제가되지 않는 주류 디자인을 충분히 갖추는 것 같습니다.

즉, 이것은 질문 3과 관련이 있습니다. 처음부터 정규화 정통에 대한 성능이나 과민증에 대해 너무 걱정하지 않아도됩니다. 이것은 트랜잭션 기반 응용 프로그램 백엔드가 아니라 구축중인보고 서버이며 성능 또는 정규화의 중요성과 관련하여 프로필이 매우 다릅니다. 실시간 가입 및 예약 응용 프로그램을 백업하는 데이터베이스는 데이터를 반환하는 데 몇 초가 걸리는 쿼리를 염두에 두어야합니다. 보고서 서버 기능은 복잡하고 긴 쿼리에 대한 내결함성이 높을뿐만 아니라 성능 향상 전략이 크게 다릅니다.

예를 들어, 트랜잭션 기반 응용 프로그램 환경에서 성능 향상 옵션에는 저장 프로 시저 및 테이블 구조를 n 도로 리팩토링하거나 소량의 일반적으로 요청되는 데이터에 대한 캐싱 전략 개발이 포함될 수 있습니다. 보고 환경에서는 확실히이 작업을 수행 할 수 있지만 예약 된 프로세스가 실행되고 사전 구성된 보고서를 저장하고 사용자가 DB 계층에 대한 스트레스없이 스냅 샷 데이터에 액세스하는 스냅 샷 메커니즘을 도입하여 성능에 훨씬 큰 영향을 줄 수 있습니다. 요청 기준.

이 모든 것은 당신이 사용하는 디자인 역할과 트릭이 당신이 만들고있는 db의 역할에 따라 다를 수 있음을 보여주기 위해 오래 지속되었습니다. 도움이 되길 바랍니다.

당신은 올바른 생각을 가지고 있습니다. 그러나이를 정리하고 일부 맵핑 (has *) 테이블을 제거 할 수 있습니다.

할 수있는 일은 Departments 테이블에서 CityId 및 DivisionId를 추가하는 것입니다.

그 외에도 모든 것이 괜찮다고 생각합니다 ...

내가 할 유일한 변경 사항은 다음과 같습니다.
1- VARCHAR을 NVARCHAR로 변경하십시오. 해외로 갈 경우 유니 코드가 필요할 수 있습니다.

2- 가능하면 int ID를 GUID (유일 식별자)로 변경하십시오 (개인 선호 일 수도 있습니다). 결국 여러 환경 (dev / test / staging / prod)이있는 지점에 도달했다고 가정하면 데이터를 서로 마이그레이션 할 수 있습니다. GUID ID를 사용하면이 작업이 훨씬 쉬워집니다.

3- 회사-> 부서-> 부서 구조에 대한 세 개의 레이어로는 충분하지 않을 수 있습니다. 이제 이것은 과도하게 엔지니어링 될 수 있지만 n 레벨의 깊이를 지원할 수 있도록 해당 계층을 일반화 할 수 있습니다. 이렇게하면 일부 쿼리가 더 복잡 해져서 그만한 가치가 없을 수 있습니다. 또한 더 많은 계층을 가진 클라이언트가이 모델에 쉽게 "채울 수있는"것일 수 있습니다.

4- 또한 VARCHAR이며 상태 테이블에 대한 링크가없는 클라이언트 테이블에 상태가 있습니다. 고객 상태가 무엇을 나타내는 지 좀 더 명확하게 기대합니다.

아니요. 세부적인 수준으로 디자인 한 것 같습니다.

국가 및 회사는 도시 및 부서와 마찬가지로 디자인에서 실제로 동일한 엔티티라고 생각합니다. 국가 및 도시 테이블 (및 Cities_Has_Departments)을 제거하고 필요한 경우 부울 플래그 IsPublicSector를 회사 테이블 (또는 단순히 개인 부문 / 공공 부문보다 더 많은 선택 사항이있는 경우 CompanyType 열)에 추가하십시오.

또한 Departments 테이블 사용에 오류가 있다고 생각합니다. Departments 테이블은 각 고객 부서가 가질 수있는 다양한 종류의 부서에 대한 참조 역할을하는 것으로 보입니다. 그렇다면 DepartmentTypes라고합니다. 그러나 고객 (참가자라고 가정)은 부서 유형에 속하지 않으며 회사의 실제 부서 인스턴스에 속합니다. 이제는 고객이 특정 고객이 HR 부서에 속해 있지만 어느 부서가 아닌지 알 수 있습니다.

즉, 고객은 Divisions_Has_Departments라고하는 테이블에 연결되어 있어야합니다 (단, 단순히 Departments라고합니다). 이 경우 데이터베이스에서 표준 참조 무결성을 사용하려면 위에서 설명한대로 도시를 부서로 축소해야합니다.

그건 그렇고, 이미 CSV를 생성하고 CSV를 mySQL 데이터베이스에로드하려면 LOAD DATA LOCAL INFILE이 가장 친한 친구입니다 .http : //dev.mysql.com/doc/refman/5.1/ 엔 /로드 data.html . Mysqlimport도 살펴볼 가치가 있으며 기본적으로 데이터로드 파일을 둘러싼 멋진 래퍼 인 명령 줄 도구입니다.

대부분의 내용은 이미 언급되었지만 한 가지만 추가 할 수 있다고 생각합니다. 젊은 개발자가 성능에 대해 약간의 선행 문제에 대해 걱정하는 것이 일반적이며 테이블 조인에 대한 질문이 그 방향으로 가고있는 것 같습니다. 이것은 ' Premature Optimization ' 이라는 소프트웨어 개발 안티 패턴 입니다. 당신의 마음에서 그 반사를 추방하려고합니다 :)

한가지 더 : 당신은 정말 '도시'와 '국가'테이블이 필요하다고 생각하십니까? Departments 테이블에 'city'및 'country'열이 사용 사례에 충분하지 않습니까? 예를 들어 응용 프로그램에서 도시 및 도시별로 부서를 국가별로 나열해야합니까?

비즈니스 인텔리전스 /보고 전문가 및 전략 / 계획 관리자의 역할에 따라 다음과 같은 의견이 있습니다.

1. 위의 래리의 지시에 동의합니다. IMHO, 그것은 너무 과도하게 설계되지 않았으며, 일부는 조금 벗어난 것처럼 보입니다. 간단하게하기 위해 고객을 회사 ID, 부서 설명, 부서 설명, 부서 유형 ID, 부서 유형 ID로 직접 태그합니다. 장기 일관성을 위해 조회 테이블 및 내부보고 / 분석 필드에 대한 참조로 부서 유형 ID 및 부서 유형 ID를 사용하십시오.

2. Packs 테이블에는 "Credit"열이 포함되어 있는데, 실제로는 클라이언트 기본 테이블에 묶여서는 안되므로 팩이 많으면 향후 수업에 얼마의 크레딧이 남아 있는지 확인할 수 있습니까? 응용 프로그램은 계산을 처리하고 Client 테이블에 중앙에 저장할 수 있습니다.

3. 회사 정보는 명백한 주소 / 전화 등을 포함하여 더 많은 필드를 사용할 수 있습니다. 정보. 또한 D & B "DUNs"열 (사이트 / 지점 / 궁극)에 추가 할 준비가되었으므로 Dun and Bradstreet (D & B)에는 거대한 회사 카탈로그가 있으며 나중에 정보가 매우 도움이 될 것입니다. 보고 / 분석. 이것은 당신이 언급 한 다중 부서 문제를 처리하고 하위 / 부서 / 분기 등을 위해 계층 구조를 롤업 할 수있게합니다. 큰 군단의.

4. 사전에 패키지화 된 "보고"소프트웨어를 사용하여 더 빠르고 훨씬 적은 수의 두통을 겪을 수있는 대규모 개발 계획을 세울 수있는 레코드 수에 대해서는 언급하지 않았습니다. 큰 데이터베이스 (<65000) 행을 처리하지 않는 경우 MS-Access, OpenOffice (Base) 또는 관련 보고서 / 앱 개발 솔루션이 트릭을 수행 할 수 없는지 확인하십시오. Oracle의 무료 APEX 소프트웨어를 꽤 많이 사용합니다. Oracle XE는 무료 데이터베이스와 함께 사이트에서 다운로드합니다.

5. 참고-통찰력보고 : 큰 데이터베이스의 경우 일반적으로 두 개의 데이터베이스 인스턴스가 있습니다. a) 각 세부 레코드를 기록하기위한 트랜잭션 데이터베이스. b) 별도의 머신에 저장된보고 데이터베이스 (데이터 마트 / 데이터웨어 하우스). 자세한 내용을 보려면 스타 스키마와 눈송이 스키마를 모두 검색하십시오.

문안 인사.

여러 테이블에 조인하면 성능이 저하되는 문제 만 해결하고 싶습니다. 조인을해야하므로 정규화하는 것을 두려워하지 마십시오. 조인은 관계형 데이터베이스에서 정상적이고 예상되며 잘 처리하도록 설계되었습니다. PK / FK 관계를 설정해야합니다 (데이터 무결성을 위해서는 설계시 고려해야합니다). 많은 데이터베이스에서 FK는 자동으로 색인화되지 않습니다. 조인에 사용되므로 FKS를 인덱싱하여 시작하고 싶을 것입니다. PK는 일반적으로 고유해야하기 때문에 작성시 색인을 얻습니다. 데이터웨어 하우스 디자인은 조인 수를 줄이는 것이 사실이지만 일반적으로 하나의 보고서에서 수백만 개의 레코드에 액세스해야 할 때까지 데이터웨어 하우징 지점에 도달하지 않습니다. 그럼에도 불구하고 거의 모든 데이터웨어 하우스는 트랜잭션 데이터베이스로 시작하여 실시간으로 데이터를 수집 한 다음 일정에 따라 (야간 또는 월간 또는 비즈니스 요구 사항에 따라)웨어 하우스로 데이터를 이동합니다. 따라서 보고서 성능을 향상시키기 위해 나중에 데이터웨어 하우스를 설계해야하는 경우에도 좋은 시작입니다.

CS 학생의 첫해에 당신의 디자인이 인상적이라고 말해야합니다.

과도하게 설계되지 않았으므로 이것이 내가 문제에 접근하는 방법입니다. 조인해도 좋습니다. 성능에 큰 영향을 미치지는 않습니다 (권장하지 않는 데이터베이스를 비정규 화하지 않으면 완전히 필요합니다!). 상태는 열거 형 데이터 유형을 사용하여 해당 테이블을 최적화 할 수 있는지 확인하십시오.

나는 훈련 / 학교 영역에서 일했고 나는 당신이 "세션"(주어진 코스의 인스턴스)과 코스 자체 사이에 일반적으로 M : 1 관계가 있다고 지적했다. 다시 말해, 카탈로그에서 코스 ( "스페인어 101"등)를 제공하지만 한 학기 (Smith가 가르치는 Tu-Th, Jones가 가르치는 Wed-Fri) 중에 두 가지 다른 인스턴스가있을 수 있습니다.

그 외에는 좋은 출발처럼 보입니다. 클라이언트 도메인 ( "클라이언트"로 이어지는 그래프)이 모델링 한 것보다 더 복잡하다는 것을 알 수 있지만 실제 데이터를 얻을 때까지 그 영역을 넘어 가지 마십시오.

몇 가지 사항이 생각났습니다.

1. 이 테이블은보고를위한 것으로 보이지만 실제로 비즈니스를 운영하지는 않습니다. 고객이 가입 할 때 본질적으로 세션 목록에 참석하는 고객을위한 주문이 있고이 주문은 한 회사의 여러 직원을위한 것일 수 있다고 생각합니다. "주문"테이블이 실제로 시스템의 중심에 있고 데이터 캡처 및 최종보고를 주도하는 것처럼 보입니다. (논리적으로 일치하는지 확인하기 위해 데이터베이스 디자인으로 비즈니스를 운영하는 데 사용한 종이 문서를 비교하십시오.)

2. 회사에는 종종 부서가 없습니다. 직원들은 때때로 부서 / 부서를 변경하거나 심지어 세션 중일 수도 있습니다. 회사는 때때로 부서 / 부서를 추가 / 삭제 / 이름 바꾸기합니다. 가능한 실시간 테이블 변경 내용으로 인해 후속보고 / 그룹화가 어렵지 않도록하십시오. 연락처 테이블이 너무 많아 테이블이 너무 많으면 보고서를 의미 있고 포괄적으로 유지하기 위해 매우 엄격한 데이터 입력 유효성 검사를 시행해야 할 수도 있습니다. 예를 들어, 새 고객을 추가 할 때 회사 / 부서 / 부서 / 도시가 동료와 동일한 값과 일치하는지 확인하십시오.

3. "팩"개념은 전혀 명확하지 않습니다.

4. 소규모 비즈니스임을 나타내므로 현재 머신의 속도와 용량을 고려할 때 성능이 문제가 될 수 있습니다.