엔티티-관계 모델

Entity–relationship model

실체-관계모형(또는 ER모형)은 특정 지식영역에서 상호 관련된 관심사항을 기술한다.기본 ER 모형은 (관심사항을 분류하는) 엔티티 유형으로 구성되며 엔티티 유형 간에 존재할 수 있는 관계(그 엔티티 유형의 인스턴스)를 규정한다.

Chen 표기법을 사용한 MMORPG의 엔티티-속성 관계도

소프트웨어 엔지니어링에서 ER 모델은 일반적으로 비즈니스 프로세스를 수행하기 위해 기업이 기억해야 할 사항을 나타내기 위해 형성됩니다.그 결과 ER 모델은 데이터베이스(일반적으로 관계형 데이터베이스)에서 구현할 수 있는 데이터 또는 정보 구조를 정의하는 추상 데이터 모델이 된다.

엔티티-관계 모델링은 데이터베이스와 설계를 위해 피터 첸에 의해 개발되어 1976년 [1]논문에 발표되었으며,[2] 이전에 존재했던 아이디어의 변형과 함께 사용되었다.일부 ER 모델은 일반화 전문화 [3]관계에 의해 연결된 슈퍼 및 서브타입 엔티티를 나타내며, ER 모델은 도메인 고유의 온톨로지 사양에서도 사용할 수 있습니다.

서론

E-R 모델은 일반적으로 비즈니스 영역에서 프로세스에 중요한 것을 정의하고 설명하기 위한 체계적인 분석의 결과입니다.비즈니스 프로세스를 정의하지 않고 비즈니스 데이터 스키마만 그래픽 형태로 표시합니다.일반적으로 도면요소 간의 연관성과 의존성을 나타내는 선(관계)으로 연결된 상자(엔티티)로 그래픽 형태로 그려집니다.ER 모델은 구두 형식으로도 표현할 수 있습니다.예를 들어, 1개의 건물은 0개 이상의 아파트로 분할할 수 있지만, 1개의 아파트는 1개의 건물에만 배치할 수 있습니다.

엔티티는 관계뿐만 아니라 "프라이머리 키"라고 불리는 식별자를 포함하는 추가 속성(속성)으로 특징지을 수 있습니다.실체와 관계뿐만 아니라 속성을 나타내기 위해 만들어진 도표는 실체-관계 모형이라기 보다는 실체-속성-관계도라고 할 수 있다.

ER 모델은 일반적으로 데이터베이스로 구현됩니다.단순한 관계형 데이터베이스 구현에서는 테이블의 각 행은 엔티티 유형의 인스턴스 1개를 나타내며 테이블의 각 필드는 속성 유형을 나타냅니다.관계형 데이터베이스에서 엔티티 간의 관계는 한 엔티티의 프라이머리 키를 포인터 또는 다른 엔티티의 테이블에 저장함으로써 구현된다.

ER/데이터 모델은 두세 가지 추상화 수준에서 구축되는 전통이 있습니다.다음 개념 논리 물리 계층은 다른 종류의 사양에서 사용되며 소프트웨어 엔지니어링에 대한 3가지 스키마 접근법과는 다릅니다.

개념 데이터 모델
이 모델은 가장 세밀한 세부사항을 포함하지만 모델 세트에 포함할 항목의 전체 범위를 설정한다는 점에서 가장 높은 수준의 ER 모델입니다.개념 ER 모델은 일반적으로 조직에서 일반적으로 사용하는 마스터 참조 데이터 엔티티를 정의합니다.전사적 개념 ER 모델을 개발하면 조직의 데이터 아키텍처를 문서화하는 데 도움이 됩니다.
개념 ER 모델은 하나 이상의 논리 데이터 모델의 기반으로 사용할 수 있습니다(아래 참조).개념 ER 모델의 목적은 일련의 논리 ER 모델 간에 마스터 데이터 엔티티에 대한 구조 메타데이터 공통성을 확립하는 것입니다.개념 데이터 모델은 데이터 모델 통합의 기초로서 ER 모델 간의 공통성 관계를 형성하기 위해 사용될 수 있다.
논리 데이터 모델
논리 ER 모델은 개념 ER 모델을 필요로 하지 않습니다.특히 논리 ER 모델의 범위가 개별 정보 시스템의 개발만을 포함하는 경우에는 더욱 그렇습니다.논리 ER 모델에는 개념 ER 모델보다 더 자세한 내용이 포함되어 있습니다.이제 마스터 데이터 엔티티와 더불어 운영 및 트랜잭션 데이터 엔티티가 정의됩니다.각 데이터 엔티티의 세부사항을 개발하고 이러한 데이터 엔티티 간의 관계를 설정합니다.단, 논리 ER 모델은 구현 가능한 특정 데이터베이스 관리 시스템과 독립적으로 개발됩니다.
물리 데이터 모델
각 논리 ER 모델로부터1개 이상의 물리 ER 모델을 개발할 수 있습니다.물리적 ER 모델은 일반적으로 데이터베이스로 인스턴스화되도록 개발됩니다.따라서 각 물리 ER 모델은 데이터베이스를 생성하기에 충분한 상세 정보를 포함해야 하며 각 물리 ER 모델은 데이터베이스 관리 시스템이 다소 다르기 때문에 기술에 의존합니다.
물리 모델은 일반적으로 데이터베이스 관리 시스템의 구조 메타데이터에서 데이터베이스 테이블, 고유 키 인덱스 등의 관계형 데이터베이스 개체 및 외부 키 제약 또는 공통성 제약 등의 데이터베이스 제약으로 인스턴스화됩니다.ER 모델은 일반적으로 관계형 데이터베이스 객체에 대한 변경 설계 및 데이터베이스의 구조 메타데이터 유지 관리에도 사용됩니다.

정보시스템 설계의 첫 번째 단계는 이러한 모델을 요구사항 분석 중에 사용하여 데이터베이스에 저장되는 정보 요구 또는 정보 유형을 기술합니다.데이터 모델링 기법은 특정 관심 영역에 대한 온톨로지(즉, 사용된 용어와 그 관계의 개요와 분류)를 기술하는 데 사용될 수 있다.데이터베이스를 기반으로 한 정보시스템 설계의 경우, 개념 데이터 모델은 나중에 관계형 모델과 같은 논리 데이터 모델에 매핑됩니다(보통 논리 설계라고 불립니다).이러한 데이터는 물리 설계 시에 물리 모델에 매핑됩니다.이 두 단계를 "물리적 설계"라고 부르기도 합니다.

엔티티-관계 모델

2개의 관련 엔티티
속성을 가진 엔티티
속성과의 관계
프라이머리 키

기업은 고유하게 식별될 수 있는 독립적인 존재가 가능한 것으로 정의할 수 있다.엔티티는 도메인의 복잡성으로부터 추상화한 것입니다.우리가 실체에 대해 말할 때, 우리는 보통 현실 [4]세계의 다른 측면과 구별될 수 있는 현실 세계의 몇 가지 측면에 대해 이야기한다.

실체는 물리적 또는 논리적으로 존재하는 것입니다.기업은 주택이나 자동차와 같은 물리적 객체(물리적으로 존재함), 주택 판매나 자동차 서비스 같은 사건 또는 고객 거래나 주문과 같은 개념(논리적으로 존재함)일 수 있다.엔티티라는 용어가 가장 일반적으로 사용되는 용어이지만 Chen에 이어 엔티티와 엔티티 유형을 구분해야 합니다.엔티티 타입은 카테고리입니다.엔티티는 엄밀히 말하면 특정 엔티티 유형의 인스턴스입니다.일반적으로 엔티티 유형의 인스턴스가 많이 있습니다.엔티티 유형이라는 용어는 다소 번거롭기 때문에 대부분의 사람들은 엔티티라는 용어를 이 용어의 동의어로 사용하는 경향이 있다.

실체는 명사로 생각할 수 있다.예: 컴퓨터, 종업원, 노래, 수학 정리 등

관계는 엔티티가 서로 어떻게 관련되어 있는지를 캡처합니다.관계는 두 개 이상의 명사를 연결하는 동사라고 생각할 수 있습니다.예를 들면, 회사와 컴퓨터의 소유 관계, 종업원과 부서의 관계 감독, 아티스트와 노래의 관계, 수학자와 추측의 관계 증명 등.

위에서 설명한 모델의 언어학적 측면은 자연어 구조를 모방한 선언형 데이터베이스 쿼리 언어 EROL에서 활용됩니다.ERROL의 의미론과 구현은 개체-관계 모델에 적합하고 언어적 측면을 포착하는 관계 대수인 재구성된 관계 대수(RRA)에 기초한다.

엔티티와 관계 모두 속성을 가질 수 있습니다.예: 종업원 엔티티는 사회보장번호(SSN) 속성을 가지며, 증명된 관계는 날짜 속성을 가질 수 있습니다.

취약한 엔티티를 제외한 모든 엔티티에는 고유 키/프라이머리 키로 사용할 수 있는 고유 식별 속성 세트가 최소한 있어야 합니다.

ERD(Entity-Relationship Diagram)는 단일 엔티티 또는 단일 인스턴스의 관계를 나타내지 않습니다.오히려, 그들은 실체 집합(같은 실체 유형의 모든 실체)과 관계 집합(같은 관계 유형의 모든 관계)을 보여준다.예: 특정 노래는 엔티티입니다.데이터베이스 내 모든 곡의 컬렉션은 엔티티 세트입니다.자녀와 점심 식사 사이의 먹는 관계는 단일 관계입니다.데이터베이스 내의 모든 자녀-점심 관계 세트는 관계 세트입니다.즉, 수학에서 관계 집합은 관계에 대응하고 관계 집합은 관계의 멤버에 대응합니다.

관계 세트에 대한 특정 카디널리티 제약도 표시될 수 있습니다.

자연어 매핑

Chen은 자연어 기술을 ER 다이어그램에 매핑하기 위한 지침 규칙을 제안했습니다. Peter Chen의 "영어, 중국어 및 ER 다이어그램"입니다.

영문법 구조 ER 구조
보통명사 엔티티 타입
고유명사 독립체
타동사 관계형
자동사 속성 유형
형용사 엔티티 속성
부사. 관계에 대한 속성

실제 보기는 데이터가 실제로 어떻게 저장되는지 보여줍니다.

관계, 역할 및 중요성

Chen의 원본 논문에서 그는 관계와 그 역할에 대한 예를 제시했습니다.그는 "결혼"과 "남편"과 "아내"라는 두 가지 역할에 대해 설명합니다.

결혼생활에서는 한 사람이 남편 역할을 하고, 같은 결혼생활에서는 다른 사람이 아내 역할을 하는 사람이 있다.이 단어들은 명사입니다.그것은 놀랄 일이 아니다; 사물을 명명하는 데는 명사가 필요하다.

Chen의 용어는 이전의 아이디어에도 적용되어 왔다.일부 도표의 선, 화살표, 까마귀발 등은 첸의 관계도보다는 초기 바흐만 도표 덕분이다.

Chen의 모델에 대한 또 다른 일반적인 확장 기능은 동사 또는 구와 같은 관계와 역할에 "이름"을 붙이는 것입니다.

역할 이름 지정

또한 역할의 소유자 및 소유자와 같은 문구로 역할 이름을 지정하는 것이 보편화되었습니다.이 경우 올바른 명사는 소유자와 소유자입니다.그래서 사람이 주인, 자동차가 주인 등의 역할보다 소유의 역할을 한다.

명사의 사용은 의미론 모델에서 물리적 구현을 생성할 때 직접적인 이익을 갖는다.사람이 자동차와 두 가지 관계를 맺을 경우, owner_person이나 driver_person 등의 이름을 생성할 수 있으며,[5] 이는 즉시 의미가 있습니다.

추기경단

원래 사양을 수정하는 것이 유리할 수 있습니다.첸은 여러 추기경에 대해 설명했습니다.한편 Oracle Designer에서 사용되는 Barker-Ellis 표기법에서는 최소 카디널리티(옵션과 유사) 및 역할에는 동일한 면이 사용되지만 최대 카디널리티(까마귀 발)[clarification needed]에는 룩어크로스가 사용됩니다.

Merise,[6] Elmasri & Navathe[7] 등에서는[8] 역할과 최소 및 최대 추기경 모두에 대해 같은 쪽을 선호합니다.최근의 연구자들(Feerer,[9] Dullea 등)[10]은 이것이 2보다 큰 n-ary 관계에 적용되었을 때 더 일관성이 있다는 것을 보여주었다.

둘레아 등지에서.누군가는 "UML에서 사용되는 것과 같은 'look over' 표기법은 정도가 이진수보다 높은 관계에 부과되는 참여 제약의 의미를 효과적으로 나타내지 않는다"고 읽는다.

Fererer에서는, 「UML 어소시에이션에 사용되는 룩 어크로스(look-acsemantics)로 동작하면, 문제가 발생합니다.Hartmann[11]과 어떻게 그리고 왜 다른 변환 우리가 다음의 몇 페이지 보실 fail." 자세한 내용은 비록"reduction"두 도표 3.4, 3.5현실은 같다 언급한)도 비논리적입니다"As,look-across 해석 단순 mech의 확장을 예방하는 여러 어려움을 소개한다가 상황을 조사한다.항문sms를 바이너리 어소시에이션에서 n-ary 어소시에이션으로 변환합니다."

1대 다의 관계를 나타내는 다양한 방법.어느 경우든, 이 다이어그램은 한 사람과 출생지 사이의 관계를 보여준다: 각 사람은 한 곳에서 태어났어야 하고, 한 곳에서만 태어났어야 하지만, 각각의 장소에는 0명 이상의 사람들이 태어났을 수 있다.
까마귀 발 표기법을 사용하여 표시된 두 개의 관련 도면요소.이 예에서는 아티스트와 송 사이에 옵션 관계가 표시됩니다.노래 엔티티에 가장 가까운 심볼은 "제로, 하나 또는 다"를 나타내며, 곡에는 "하나뿐인" 아티스트가 있습니다.따라서 전자는 아티스트가 "제로, 하나 또는 다" 노래를 연주할 수 있는 것으로 읽힌다.

첸의 개체-관계 모델링 표기법은 개체 집합을 나타내기 위해 직사각형을 사용하고, 일급 개체에 적합한 관계를 나타내기 위해 다이아몬드를 사용합니다. 즉, 그들은 그들만의 속성과 관계를 가질 수 있습니다.엔티티 세트가 관계 세트에 참여하는 경우 엔티티 세트는 선으로 연결됩니다.

속성은 타원형으로 그려지며 정확히 하나의 도면요소 또는 관계 세트에 선으로 연결됩니다.

카디널리티 제약 조건은 다음과 같습니다.

  • 이중선은 참여 제약, 전체성 또는 주관성을 나타냅니다. 엔티티 집합의 모든 엔티티는 관계 집합에서 적어도 하나의 관계에 참여해야 합니다.
  • 엔티티 집합에서 관계 집합으로의 화살표는 주요 제약, 즉 주입성을 나타낸다. 엔티티 집합의 각 엔티티는 관계 집합에서 최대 하나의 관계에 참여할 수 있다.
  • 굵은 선은 두 가지 모두를 나타냅니다. 즉, 개체 집합의 각 개체는 정확히 하나의 관계에 관여합니다.
  • 밑줄 친 Atribute의 이름은 Atribute가 키임을 나타냅니다.이 Atribute의 2개의 다른 엔티티 또는 Atribute와의 관계는 항상 이 Atribute의 값이 다릅니다.

속성은 다이어그램을 복잡하게 만들 수 있기 때문에 생략되는 경우가 많습니다.다른 다이어그램 기법에서는 도면요소 세트에 대해 그려진 직사각형 내에 도면요소 속성을 나열하는 경우가 많습니다.

관련 다이어그램 표기법:

까마귀발 표기법

크로우의 발 표기법은 고든 에베레스트(1976)의 기사로 [12]거슬러 올라가며 바커의 표기법, 구조화 시스템 분석 및 설계 방법(SSADM) 및 정보기술 공학에 사용된다.Crow의 발 다이어그램은 도면요소를 상자로 나타내고 관계를 상자 사이의 선으로 나타냅니다.이들 선의 끝에 있는 다른 모양은 관계의 상대적인 카디널리티를 나타냅니다.

Crow's foot 표기법은 CACI 컨설턴트 실습에서 사용되었습니다.그 후 CACI의 컨설턴트(Richard Barker 포함)의 상당수는 Oracle UK로 이동하여 Oracle의 CASE 툴의 초기 버전을 개발하여 더 많은 독자에게 이 표기법을 소개했습니다.

이 표기법에서는 관계에 속성을 지정할 수 없습니다.필요에 따라서, 예를 들면, 아티스트가 곡을 어디에서 언제 연주했는지 파악할 필요가 있는 경우, 새로운 엔티티 「퍼포먼스」를 도입해(시기와 장소를 반영한 속성으로), 아티스트와 곡의 관계는 퍼포먼스를 통해서 간접적인 관계가 된다.(퍼포먼스, 퍼포먼스, 퍼포먼스)

카디널리티를 나타내기 위해 세 가지 기호가 사용됩니다.

  • 링은 "0"을 나타냅니다.
  • 대시는 "1"을 나타냅니다.
  • 까마귀의 발은 "많이" 또는 "많이"를 나타낸다

이러한 기호는 쌍으로 기업이 관계에서 가질 수 있는 네 가지 유형의 카디널리티를 나타내기 위해 사용된다.표기법의 내부 구성요소는 최소값을 나타내고 외부 구성요소는 최대값을 나타냅니다.

  • 링 및 대시 → 최소 0, 최대 1(옵션)
  • 대시 및 대시 → 최소 1개, 최대 1개(표준)
  • 링 및 까마귀 발 → 최소 0, 최대 다(옵션)
  • 대시 및 까마귀 발 → 최소 1개, 최대 수(최소 수)

모델 조작성 문제

모델링된 데이터베이스를 사용하면 반환된 결과가 쿼리 작성자가 가정한 결과와는 다른 의미를 갖는 두 가지 잘 알려진 문제가 발생할 수 있습니다.

첫 번째는 '팬 트랩'이다.1 대 다의 관계에서 여러 테이블에 링크하는 (마스터) 테이블에서 발생합니다.이 회계논제의 이름은 모형을 주표에서 '팬아웃(fan out)'한 형태에서 파생되었다.이 모델 유형은 데이터 웨어하우스에 사용되는 모델 유형인 스타 스키마와 유사합니다.마스터 테이블에서 표준 SQL을 사용하여 집계 합계를 계산하려고 하면 예기치 않은(잘못된) 결과가 발생할 수 있습니다.해결책은 모델 또는 SQL을 조정하는 것입니다.이 문제는 주로 의사결정 지원 시스템용 데이터베이스에서 발생하며, 이러한 시스템을 쿼리하는 소프트웨어에는 이 문제를 처리하기 위한 특정 방법이 포함되어 있을 수 있습니다.

두 번째 이슈는 '균열의 함정'이다.간극 트랩은 모델이 엔티티 유형 간의 관계의 존재를 제안하지만 특정 엔티티 발생 사이에 경로가 존재하지 않을 때 발생합니다.예를 들어, 건물에 하나 이상의 회의실이 있으며, 이 회의실은 0대 이상의 컴퓨터를 수용합니다.모델을 조회하여 빌딩의 모든 컴퓨터를 볼 수 있습니다.그러나 현재 회의실에 할당되지 않은 컴퓨터(복구 중이거나 다른 위치이기 때문에)는 목록에 표시되지 않습니다.빌딩과 컴퓨터 사이의 또 다른 관계는 빌딩 내의 모든 컴퓨터를 캡처하기 위해 필요합니다.이 마지막 모델링 문제는 실제 세계에 존재하는 모든 관계를 모델에서 포착하지 못한 결과이다.자세한 내용은 Entity-Relationship Modeling 2를 참조하십시오.

엔티티 - 관계 및 의미 모델링

의미론 모델

의미 모델은 개념의 모델이며, 때때로 "플랫폼 독립 모델"이라고 불립니다.집중형 모델입니다.적어도 Carnap 이후, 다음과 같이 [13]잘 알려져 있다.

"개념의 완전한 의미는 그 의도와 확장의 두 가지 측면에 의해 구성됩니다.첫 번째 부분은 개념의 세계 전체에 개념의 포함, 즉 다른 개념에 대한 모든 관계의 전체로 구성됩니다.두 번째 부분은 개념의 참조적 의미, 즉 현실 세계 또는 가능한 세계에서의 상대적인 의미를 설정한다."

확장 모델

확장 모델은 특정 방법 또는 기술의 요소에 매핑되는 모델이며, 따라서 "플랫폼 고유 모델"입니다.UML 규격은 클래스 모델의 연관성은 확장적이며, 이는 이전 후보 "의미 모델링 언어"에 의해 제공되는 것보다 규격에 의해 제공되는 광범위한 "장식"을 고려함으로써 사실상 자명하다.데이터 모델링 표기법으로서의 UML, 파트 2"

엔티티-관계 기원

ER 모델링의 아버지인 Peter Chen은 자신의 논문으로 다음과 같이 말했습니다.

"실체-관계 모델은 실체가 실체와 관계로 구성된다는 보다 자연스러운 관점을 채택합니다. 그것은 현실 세계에 대한 중요한 의미 정보의 일부를 포함하고 있습니다."

Chen은 1976년 원본 기사에서 엔티티-관계도를 레코드 모델링 기법과 명시적으로 대조했다.

"데이터 구조 다이어그램은 기록의 구성을 나타내는 것으로 실체와 관계를 정확하게 나타내는 것은 아닙니다."

다른 작가들도 [14]Chen의 프로그램을 지원하고 있습니다.

철학적 정렬

첸은 고대 그리스 철학자 플라톤과 [19]아리스토텔레스 시대의 철학적 전통과 일치한다.플라톤 자신은 지식을 불변의 형태(즉, 많은 종류의 사물, 그리고 속성의 원형 또는 추상적 표현)와 그들의 관계에 대한 이해와 연관짓는다.

제한 사항

  • ER 모델은 주로 개념적인 것으로 지식의 영역에서 술어를 표현하는 온톨로지입니다.
  • ER 모델은 관계형 데이터베이스 구조(Codd 및 Date 이후)를 나타내는 데 쉽게 사용되지만 다른 종류의 데이터 구조(데이터 웨어하우스, 문서 저장소 등)를 나타내는 데는 그다지 자주 사용되지 않습니다.
  • 일부 ER 모델 표기법에는 슈퍼 서브형 관계 및 관계 간의 상호 배제를 나타내는 기호가 포함되지만, 그렇지 않은 기호는 포함되지 않습니다.
  • ER 모델은 기업의 수명 이력을 보여주지 않습니다(시간 경과에 따라 사건에 대응하여 속성 및/또는 관계가 어떻게 변화하는지).많은 시스템에서 이러한 상태 변경은 중요하지 않으며 명시적 사양을 보장할 수 있을 만큼 중요합니다.
  • 일부에서는[who?] 상태 변경을 나타내는 구조를 사용한 확장 ER 모델링이 있습니다.이것은 원래 작성자가 지원하는 [20]접근법입니다.예를 들어 앵커 모델링입니다.
  • 상태 전이도 또는 기타 프로세스 모델링 기법을 사용하여 상태 변화를 별도로 모델링하는 경우도 있습니다.
  • UML이 [21]제공하는 14가지 다이어그램 유형을 포함하여 시스템의 다른 측면을 모델링하기 위해 많은 종류의 다이어그램이 그려집니다.
  • 오늘날에는 ER 모델링이 유용할 수 있는 곳에서도 많은 사람들이 비슷한 종류의 모델, 특히 OO 프로그래밍을 위한 클래스 다이어그램과 관계형 데이터베이스 관리 시스템을 위한 데이터 모델을 지원하는 도구를 사용하기 때문에 흔치 않습니다.이러한 도구 중 일부는 다이어그램에서 코드를 생성하고 코드에서 역엔지니어 다이어그램을 생성할 수 있습니다.
  • 한 조사에서 Brodie와[22] Liu는 Fortune 100대 기업 10곳의 표본에서 기업 관계 모델링의 단 한 사례도 찾을 수 없었습니다.Badia와 Lemire는[23] 이러한 사용 부족의 원인을 가이던스의 부족뿐만 아니라 데이터 통합에 대한 지원 부족 등의 이점도 있다고 지적하고 있습니다.
  • 향상된 엔티티-관계 모델(EER 모델링)은 ER 모델링이 아닌 여러 가지 개념을 도입하지만 is-a 관계와 같은 객체 지향 설계와 밀접하게 관련되어 있습니다.
  • 시간 데이터베이스 모델링의 경우 수많은 ER 확장이 고려되었다.[24]마찬가지로 ER 모델은 다차원 데이터베이스(OLAP 어플리케이션에서 사용)에 적합하지 않은 것으로 판명되었습니다.일반적으로 OLAP 큐브(필드 [25]내에서는 데이터 큐브라고도 함) 개념을 중심으로 진행되지만 이 필드에서는 아직 지배적인 개념 모델이 등장하지 않았습니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ a b Chen, Peter (March 1976). "The Entity-Relationship Model - Toward a Unified View of Data". ACM Transactions on Database Systems. 1 (1): 9–36. CiteSeerX 10.1.1.523.6679. doi:10.1145/320434.320440. S2CID 52801746.
  2. ^ A.P.G. Brown, Douque and Nijssen(에드), North-Holland, 1975, ISBN 0-7204-2833-5, "실제 시스템을 모델링하고 이를 나타내는 스키마를 설계한다."
  3. ^ "Lesson 5: Supertypes and Subtypes". docs.microsoft.com.
  4. ^ Beynon-Davies, Paul (2004). Database Systems. Basingstoke, UK: Palgrave: Houndmills. ISBN 978-1403916013.
  5. ^ "The Pangrammaticon: Emotion and Society". January 3, 2013.
  6. ^ 휴버트 타디외, 아놀드 로흐펠트, 르네 콜레티 라 메토드 MERISE: 프린키페스와 아웃필스 (Paperback - 1983년)
  7. ^ 엘마스리, 라메즈, BShamkant, Navathe, Fundamentals of Database Systems, 제3판, Addison-Wesley, Menlo Park, CA, USA, 2000.
  8. ^ ER 2004 : 23rd International Conference on Conceptual Modeling, Shanghai, China, November 8-12, 2004. 2004-10-27. ISBN 9783540237235.
  9. ^ "A Formal Treatment of UML Class Diagrams as an Efficient Method for Configuration Management 2007" (PDF).
  10. ^ "James Dullea, Il-Yeol Song, Ioanna Lamprou - An analysis of structural validity in entity-relationship modeling 2002" (PDF).
  11. ^ 하르트만, 스벤"참가 제약과 Chen의 제약에 대한 이유 2013-05-10년 웨이백 머신에 아카이브"제14회 호주 데이터베이스 회의 진행 제17권.오스트레일리아 컴퓨터 협회, 2003년
  12. ^ G. Everest, Computing Systems 1976, Proceedings 제5회 텍사스 컴퓨팅 시스템 컨퍼런스, Austin, TX, 1976년 10월 18-19일자 39-46쪽, "일반적인 예와 함께 설명되는 기본 데이터 구조 모델" (롱비치, CA: IEEE 컴퓨터 협회 출판물 사무소)
  13. ^ "The Role of Intensional and Extensional Interpretation in Semantic Representations".
  14. ^ "데이터와 현실"의 켄트:
    "모델링을 시작할 때 우리가 머릿속에 분명히 새겨야 할 한 가지는 우리가 "현실"의 일부(일부 인간 기업)를 묘사하려는 것인지 아니면 데이터 처리 활동을 묘사하려는 것인지입니다."
  15. ^ 「데이터 의미론」의 Abrial : 「 「논리적인」의 정의와 데이터의 조작은, 지금도(때로는 무의식적으로) 컴퓨터 시스템에서 이용 가능한 「물리적」스토리지와 검색 메카니즘의 영향을 받고 있습니다.
  16. ^ Stamper: "실체 유형을 설명하는 척하지만 데이터 처리(필드, 데이터 항목, 값)에서 나온 용어입니다.이름 짓기 규칙은 사람과 물건의 이름을 짓기 위해 사용하는 규칙을 반영하지 않습니다. 대신 파일에서 레코드를 찾는 기술을 반영합니다.
  17. ^ 잭슨의 말을 빌리자면, "개발자는 시스템이 관련된 현실의 모델을 만드는 것부터 시작합니다. 시스템의 주제를 제공하는 현실..."
  18. ^ Navathe의 Elmasri: "ER 모델의 개념은 데이터에 대한 사용자의 인식에 더 가깝도록 설계되었으며, 데이터가 컴퓨터에 저장되는 방식을 설명하는 것이 아닙니다."
  19. ^ Paolo Rocchi, Janus-Face Probability, Springer, 2014, 페이지 62.
  20. ^ P. Chen.새로운 개척지에 대한 권장 연구 방향: 액티브한 개념 모델링.ER 2006, 컴퓨터 과학 강의 노트 제4215권, 1~4페이지.Springer Berlin / 하이델베르크, 2006.
  21. ^ Carte, Traci A., Jasperson, Jon (Sean) 및 Cornelius, Mark E. (20) "데이터 모델링 교육 시 ERD 및 UML 개념 통합", 정보 시스템 교육 저널: Vol. 17: Iss 1, 9.
  22. ^ 정보 시대의 관계형 기술의 힘과 한계 2016-09-17년 Wayback Machine 아카이브On The Move Federated Conference, 2010.
  23. ^ A. Badia와 D.레미어무기의 호소: 데이터베이스 설계 재검토.씨티서스
  24. ^ Gregersen, Heidi; Jensen, Christian S. (1999). "Temporal Entity-Relationship models—a survey". IEEE Transactions on Knowledge and Data Engineering. 11 (3): 464–497. CiteSeerX 10.1.1.1.2497. doi:10.1109/69.774104.
  25. ^ RICCARDO TORLONE (2003). "Conceptual Multidimensional Models" (PDF). In Maurizio Rafanelli (ed.). Multidimensional Databases: Problems and Solutions. Idea Group Inc (IGI). ISBN 978-1-59140-053-0.

추가 정보

외부 링크

Wikimedia Commons에는 엔티티 관계 모델과 관련된 미디어가 있습니다.