상속 및 관계 개념을 연결하는 데 도움이

Question

상속 및 모델을 디자인에서 사용에 대한 내 프로그래머 내 친구와 얘기했다. 그는 큰 지지자이고 나는 조금 더 미지근합니다. 주로 데이터베이스 시스템 -> 응용 프로그램 -> 프리젠 테이션 (솔직히 프론트 엔드 녀석이 아니기 때문에 프레젠테이션을 전적으로 다른 사람에게 맡기고 있습니다. 관계형 데이터베이스 시스템은 다른 테이블과 1 : 1로 많은 관계없이 상속을 지원하지 않는다는 것을 알게되었습니다.

개념적 관점에서 설계한다면 관리자는 사용자입니다. 데이터베이스에서 시작하여 관리자는 UserType = "Administrator"인 사용자입니다. 이러한 접근법을 조정하는 것은 나에게 어려울 것으로 보이며, 따라서 비 지속 대상에서만 상속을 사용합니다.

내 생각에 무슨 문제가 있습니까? 전통적인 관계형 구조와 본질적으로 양립 할 수없는 상속 관계가있는 이유는 무엇입니까? 또는 상속을 관계형 데이터에 올바르게 매핑하지 않는 사람입니까? 이 문제를 해결할 수있는 지침이 있습니까?

궁금한 질문이 있으시면 죄송합니다. 미리 답변 해 주셔서 감사합니다. 응답에 코드를 포함하면 C#이 "모국어"입니다.

Answer 1

이 널리 되나 된 Object-Relational Impedance Mismatch :

스키마 상속 - 대부분의 관계형 데이터베이스 스키마 상속을 지원하지 않습니다. 이러한 기능은 OOP와의 충돌을 줄이기 위해 이론적으로 추가 될 수 있지만 관계형 제안자는 집합 기반 분류 또는 분류 시스템을보다 강력하고 유연하게 보는 경향이 있으므로 계층 적 택 소노 미와 하위 유형화의 유용성을 믿을 가능성이 적습니다. 나무보다. OO 옹호자들은 상속/하위 유형 지정 모델이 트리 (Java와 같은 많은 인기있는 OO 언어의 제한 임에도 불구하고)에 국한 될 필요는 없지만 트리가 아닌 OO 솔루션은 세트 기반 변형보다 공식화하기가 어렵다고 지적합니다. 관계형이 선호하는 테마 관리 기술. 적어도 관계형 대수에서 일반적으로 사용되는 기술과는 다릅니다.

은 참조 : Agile Data, C2 Wiki

Answer 2

C#에서 이러한 종류의 관계를 표현하는 데는 여러 가지 방법이 있습니다. 관계형 데이터베이스는 단순히 제한되어 있습니다 (단점은 물론 장점 일 수 있음). 데이터베이스에 유지 될 객체 계층 구조를 설계 할 때 사실상 모든 데이터베이스 스키마가 객체 관계에 쉽게 매핑 될 수 있기 때문에 데이터베이스 스키마로 시작하는 것이 일반적으로 더 쉽다는 것을 알았지 만 반대는 반드시 경우.

이 경우 관리자로 구성하여 모델링 할 수 있습니다. 관리자 테이블은 추가 관리자 상태와 해당 사용자의 키를 제공합니다. 사용자 FK는 귀하의 Admins PK가됩니다.

Answer 3

상속의 종류는 다양합니다. 개발자는 인터페이스와 행동면에서 생각할 수 있습니다.

전 세계에서 관리자의 "userType"을 갖는 것은 무엇을 의미합니까?

당신이 암시하는 의미는 어딘가에있는 일부 코드가 해당 userType을보고 해당 유형의 사용자에 대한 작업을 승인한다는 것입니다. 관리자가 다른 사용자를 만들 수 있습니까?

는 경우 개발자는 유형 관리자의 객체가 사용자 수있는 모든 곳에서 사용할 수있는 추가 기능

class Administrator() extends User { createUser() {...}; approvePurchase() {...} } 

와 클래스 사용자

class User() { viewData(){ ...} ; signReport() {...} } 

및 클래스 관리자에 게있을 수 있습니다. 이 다형성 행동은 함축 할 때 도움이 될 수 있습니다. 이제 데이터베이스가 그럴듯하게 그럴 수 있습니다. 그러나 관리자가 특정 작업을 수행하기 위해 약간의 추가 데이터 만 필요로 할 때 당신은 무엇을 할 것입니까? 예를 들어, purchaseApproval()은 특정 한도까지이며, 새 필드로 한도가 필요하지만 관리자에게만 적용됩니다.

"유형"개념에서 암시하는 행동 측면은 추가 데이터와 관련이 있다고 생각합니다.

Answer 4

당신은 Patterns of Enterprise Application Architecture 읽어야합니다. 상속 패턴이 관계형 구조를 표현할 수 있고 표현해야하는 방법을 보여줍니다.

기억해야 할 중요한 점은 상속이 개념 모델링이라는 것입니다. 관계형 구조와 객체 지향 코드 (OO code)는 개념 모델의 실체화에 지나지 않으며, 모든 객체 지향으로 간주해서는 안됩니다.

여기에는 tutorial이 있습니다.

Answer 5

관계형 패러다임과 OO 패러다임 사이의 간격이 종종 논의됩니다.

기본적으로 RDBMS와 OO 간의 매핑을 제공하려면 의 일부 기능을 모두 희생해야합니다 ( 시스템). 당신은 당신의 타협이 어느쪽으로 더 많이 비중을 차지하는지를 결정해야합니다.

두 패러다임은 매우 강력하고 유용합니다. 그러나 그것들을 완벽하게 매핑하려고 시도하는 것은 해결되지 않은 문제입니다.

Answer 6

예, 상속은 데이터베이스와 매핑 할 때 적절한 도구가 아닙니다.

상속은 프레임 워크를 만들 때 훨씬 유용합니다. 프레임 워크를 만들 때 다른 유형의 개체가 있지만 동작이 다른 여러 가지 유형의 개체가 있지만 공통된 부분이 있습니다.

예를 들어, 서버간에 다른 "메시지"를 전달할 수 있습니다. 각 메시지에는 고유 한 논리가 있으므로 거대한 switch() 문을 피하기 위해 다른 클래스가 필요하지만 공통 부분이 있습니다. 즉, 모든 메시지가 스트림으로 직렬화/역 직렬화하는 방법을 알아야한다는 것과 같은 공통 부분이 있습니다. Message의 모든 서브 클래스는 오버라이드 (override)되어야한다). 또한 모든 메시지가 Message를 상속 받으면 List를 가지게되고 하나씩 이동하여 Serialize 메서드를 호출합니다.

일반적인 비즈니스/DB 논리 만 수행하면 상속이 가장 잘 일어납니다. 이 기존의 관계형 구조와 이러한 고유의 호환성이있는 경우

Answer 7

왜 OO의 상속 같은 자주 유명한 측면이다?

이것은 호기심이 많은 인용문입니다. 관계형 구조가 "전통적"이라고 말하는 이유는 무엇입니까? 그들은 본질적으로 RDBMS의 표준이지만, DB가 아닌 언어의 맥락에서 관계형 라이브러리는 거의 볼 수 없었습니다.

OO가 인기있는 이유는 지배적 인 절차 모델보다 중요한 개선 이었기 때문입니다. 상속을 사용하면 코드를보다 안정적으로 (유형 검사를 통해) 만들 수 있고, 메소드 전문화를 통해보다 쉽게 ​​수정하고, 행동을 쉽게 대체하여 테스트 할 수 있습니다. 절차 적 모델과 비교했을 때, OO는 이고은 고품질 소프트웨어를 쉽게 개발할 수 있습니다.

물론 OO와 관계형 모델 간의 매핑이 어렵습니다. 이를 "객체 관계형 불일치"라고하며 "the Vietnam of computer science"으로 명명되었습니다. 관계형 데이터베이스에 OO 데이터를 저장하기위한 다양한 전략이 있지만 완벽하지는 않습니다. 현대에서 가장 많이 사용되는 것은 active record pattern을 기반으로하는 프레임 워크입니다.

Answer 8

정규화 된 관계형 데이터베이스 스키마는 DBA 세계에서 일반적으로 "베스트 프랙티스"로 간주되지 않는 한 실제로 다형성을 지원하지 않습니다. 이것은 어떤 의미에서 새로운 쟁점이 아니며 문제 자체는 여러 가지 다른 방식으로 천 번 이상 해결되었습니다.

데이터 작업을 시작할 때 실제 문제가 발생합니다. 데이터 세트로 작업하는 경우 계속해서 다양한 종류의 다형성을 구현하려는 시도가 있습니다. 그러나 도메인 엔티티 세트를 관계형 모델에 맵핑하는 경우, 관계형 데이터베이스 스키마의 한계를 극복하는 데 도움이되는 많은 도구가 있습니다.

C# 개발자이므로 다음 두 프로젝트를 검토하여 시작해야합니다. 그 중 하나는 최신 .NET 서비스 팩과 함께 제공됩니다.

ADO.NET 엔티티 프레임 워크 :

http://msdn.microsoft.com/en-us/library/bb386876.aspx

자 NHibernate :

http://nhforge.org/Default.aspx

Answer 9

Admininstrator는 "관리자"의 UserType을 가진 사용자 인 귀하의 구체적인 예는 좋은 예입니다 "Single Table Inheritance" 패턴의 이것은 몇몇 주요 ORM에서 구현됩니다. 특히 "Rails ActiveRecord"와 최대 절전 모드.

Answer 10

나는 상속 모델에 결함이 있다고 주장 할 것이다. 그것은 너무 리터럴하거나 현실 세계에 기반을두고 있습니다. 네, 저는 현실 세계에서 행정가라고 주장 할 수 있습니다. 따라서 관리자는 은입니다. 그러나 객체 디자인과 상속은 코드 공간에서 표현되고 공유 된 행동을 기반으로해야합니다. 나는 사용자가 역할을하는 경로를 더 많이 갈 것입니다. 관리자는 역할 또는 특정 상태로 설정된 역할의 인스턴스입니다. 사용자가 사람이 아닙니다 (일괄 작업에 사용자 계정이 필요할 수 있음).

나는 오브젝트 디자인을 소개하기 위해 David West의 Object Thinking을 읽는 것이 좋습니다. 그는 Object Relation Mismatch를 다루지 않지만 사람들은 이미 그 주제에 대한 많은 자료를 제공하고 있습니다.

Answer 11

하이버 네이트는 상속을 단순화한다. Example