영어로, 우리는 Bob과 Tim의 관계에 대해 이야기 할 수 있습니다. 아마도 그들은 사촌 일 것입니다. 이 문맥에서 "관계"라는 용어는 나에게 의미가 있습니다.

관계형 데이터베이스의 맥락에서 나는 그 용어가 무엇을 의미하는지 이해하지만 그것이 왜 사용되는지 이해하지 못합니다. 나는 그것이 왜 사용되는지 이해하면 필드를 더 잘 이해하는 데 도움이 될 것이라고 생각합니다. 그래서 나는 그것이 왜 사용되는지 이해하고 싶습니다.

• 예를 들어 개인이 "관계"로 간주되는 이유는 무엇입니까? 영어로, 관계는 두 엔티티가 어떻게 연관되어 있는지를 설명하는 명사입니다. 엔티티 자체를 나타내는 것은 아닙니다. 관계형 데이터베이스와 관련하여 "관계"는 엔티티 자체를 나타냅니다. 왜?
• 관계형 모델이 계층 적 및 네트워크 모델 (예 : 부모, 이웃)을 따 랐음을 이해합니다. 그러나 이러한 모델에서 개체는 서로 관계가 있습니다. 그렇다면 왜이 모델을 관계형 모델이라고합니까? 더 구체적인 문구 / 용어가 있습니까? 아니면 세 모델이 모두 관계형 모델이지만 계층 적 및 네트워크 모델이 특정 유형의 관계형 모델이라고 말할 수 있습니까?
• 서로 관련이없는 독립형 엔터티가있는 경우 어떻게해야합니까? 말, 사람, 문 및 나무. "관계 (al)"라는 용어가 계속 적용됩니까?

(아마도 여러 개의 질문이 있어야합니다. 답변이 서로 관련이 있다고 생각했습니다. 아마도 하나의 답변 만있을 것입니다. 따라서이 질문이 하나의 질문 인 것이 타당하다고 생각했습니다. 틀렸다면 알려주세요. 대신 별도의 질문을 만들 것입니다.)

편집 :이 다이어그램은 관계가 다른 도메인을 서로 관련시키고 있음을 시각화하는 데 유용 할 수 있습니다.

우선, Edgar Frank Codd 박사 가 1970 년에 일반 대중에게 관계형 프레임 워크를 공개 한 과학 논문 , 즉 대형 공유 데이터 뱅크를위한 데이터의 관계 모델을 적극 추천합니다 . Codd 박사는 1.1 절“소개”에서 다음과 같이 말합니다.

본 논문은 포맷 된 데이터의 큰 뱅크에 대한 공유 액세스를 제공하는 시스템에 기초 관계 이론을 적용하는 것에 관한 것이다.

---

_{© 컴퓨팅 기계 협회. 1970 년 6 월, ACM의 통신 , 제 13 권, 제 6 호 (pp. 377-387).}

그렇습니다. 관계 라는 용어 와 관계형 은 수학적 배경에서 비롯된 것입니다. 학업 및 연구 자격을 제외하고 컴퓨팅 및 정보 처리 분야에서 약 20 년 동안 직접 경험을 쌓은 Dr. Codd는 데이터 관리 분야에서 관계 (추상적 인 구조)를 적용 할 때 얻을 수있는 엄청난 이점을 상상했습니다. .

나는 수학자가 아니지만 기본적으로 말해서 관계는 세트 사이의 연관 이며, 세트는 요소의 모음입니다 ( 이 외부 리소스 는 다른 관점에서 이해하는 데 도움이되는 수학적 관계 의 정의를 제공합니다 ). SQL 데이터베이스 관리 시스템 (간결을위한 DBMS)의 도움으로 작업 할 때, 잘 알려진 근사 관계의은이다 테이블 협회가 사이에 일어나는 경우, 유형 의의 열 . DOMAIN 지원을 제공하는 SQL 플랫폼 (예 : Firebird 및 PostgreSQL )에서 연결은해당 테이블의 열에 고정 된 도메인 ; 자세한 내용은 아래 섹션을 참조하십시오.

이와 관련하여 1.3 절.“데이터의 관계형 관점”에서 Dr. Codd는 다음과 같이 주장합니다.

관계 라는 용어 는 여기에서 허용되는 수학적 의미로 사용됩니다. 세트 S ₁ , S ₂ , ⋯, S _n (필수적으로 구별되는 것은 아님)이 주어지면 , R 이 n 개의 튜플 세트 인 경우 R 은 이들 n 세트 에 대한 관계 이며, 각각의 요소는 S ₁ 의 첫 번째 요소 인 두 번째 요소입니다 S ₂ 등 으로부터 . ^{도 1은} 우리 참조한다 S의 _J 는 AS J 번째 도메인 의 R . 상기 정의 된 바와 같이, R 은 정도 n 을 갖는다 고한다. 도 1의 관계는 종종라고 단항 ,도 2 진 ,도 3 원계 , 및도 n은 n 차 .

_{¹ 더 간결하게, R 은 직교 곱 S 1 × S 2 × S 3 ⋯ × S n 의 부분 집합입니다} .

---

_{© 컴퓨팅 기계 협회. 1970 년 6 월, ACM의 통신 , 제 13 권, 제 6 호 (pp. 377-387).}

Codd 박사가 데이터 관리와 관련하여 최대한 활용하기 위해 수학적 관계에 적응했다는 점을 지적하는 것이 매우 적절하다는 다른 답변에 동의합니다. 이는 이전 및 그의 광범위한 참고 문헌을 통해 .

관계 와 관계

양육 상황 가치는 이러한 주제를 다룰 때 즉, 때문에 용어의 일상 (비 수학, 비 기술) 정의에 대한 존재의 유사성에 혼란이 발생할 수 있습니다 관계 와 관계를 - 어떤, 비 등 영어를 모국어로 사용하는 사람이라면 특히 이해할 수 있습니다.

개체 - 관계보기 와 관계형 모델

내가 혼동을 일으킬 수 있다고 생각하는 다른 요소는 (그리고 위에서 언급 한 두 용어의 기술적 의미와 밀접한 관련이있다), 데이터베이스를 디자인하는 법을 배울 때, 학생이나 개업의는 일반적으로 Dr. Peter Pin-Shan Chen 은 데이터 의 개체 관계 보기 (1976 년에 게시)에서 개념적 스키마 를 묘사하는 두 가지 다른 구현 (즉, 개체 와 관계 )을 제안한 다음 해당 스키마의 정의 후에 만 , 학생 또는 개업의 를 선언 할 때 관계 용어 및 도구 (예 : 관계 )를 소개합니다관련 데이터베이스의 논리적 레이아웃. 개념적 참조 틀 내에서 관계 는 일상적인 단어의 의미에 훨씬 더 가까운 의미를 내포합니다.

그런 다음 이러한 상황은 관계 및 관계 문제 에도 추가 될 수 있습니다. 그러나 먼저 개념 스키마를 정의한 다음 해당 논리 설계를 선언하는 순서는 물론 다음 섹션에서 자세히 설명하는 것처럼 매우 적합합니다.

각 하위 질문에 대한 답변

이 세 가지 하위 질문을 포함시키는 것은 게시물에 대한 더 넓은 컨텍스트를 설정하므로 간과해서는 안되기 때문에 실제로 적절하다고 생각합니다. 이러한 방법으로, 떨어져 독점적 용어 이유 주소에서 관계 와 관계가 (확실히 매우 중요한이며, 어떤 사용되는 제목 게시물의,하지만이 되지 전체 게시물), subquestions 더의 범위를 이해하는 데 도움이 수 있다고 말했다 전체 정보 관리 프로젝트 (데이터베이스 관리에 관한 사이트이므로 매우 관련이 있음)에 관여하고 다른 추상화 수준 에서 작업 할 때 의 관계 및 관계 모델. 이런 식으로, 나는 아래의 특정 사항에 대한 나의 의견을 공유 할 것입니다.

서브 질문 번호 1

예를 들어 개인이 "관계"로 간주되는 이유는 무엇입니까? 영어에서 관계는 두 엔터티가 어떻게 연결되어 있는지를 나타내는 명사입니다. 엔티티 자체를 나타내는 것은 아닙니다. 관계형 데이터베이스와 관련하여 "관계"는 엔티티 자체를 나타냅니다. 왜?

개념적 수준

특정 비즈니스 환경에서 개인 은 비즈니스 전문가 및 데이터베이스 디자이너가 해당 개념을 개념화 하는 방식 에 따라 엔티티 유형 으로 간주 될 수 있습니다 . 예, 비즈니스 환경 에서 Person 엔티티 유형 (예 : Name , BirthDate , Gender 등) 과 관련하여 다른 관심 특성 이있을 수 있습니다 .

또한, 개인 엔티티 유형은 자신 또는 다른 엔티티 유형과 특정 관계 (또는 연관 또는 연결 ) 유형 을 보유 할 수 있습니다. 예를 들어이 사람이 라는 개체 유형과 관련 될 수있다 USERPROFILE 차례로, 우리가 말을하자, 관심 자체의 속성을 가질 수있다, 사용자 이름 및 암호 .

그러나 (a) 항목 유형, (b) 해당 속성, (c) 항목 유형 간의 관계 유형 및 (d) 속성 자체 간의 관계는 특정 비즈니스 환경에 속하는 개념입니다. 중요성으로 간주됩니다. 이들은 설계 단계에서 상황 별 개념 스키마 를 정의하기 위해 비즈니스 전문가와 긴밀히 협력하는 데이터베이스 설계자가 사용하는 장치 입니다.

따라서 개념 수준에서 우리는 기본적으로 실제 관심 분야에서 발생하는 아이디어의 구조, 즉 (1) 사물 프로토 타입 및 (2) 사물 프로토 타입 간의 관계 프로토 타입으로 작업합니다. (3) 관계 — 데이터의 관계 적 프레임 워크의 의미에서이 마지막 용어를 사용하는 것 —

논리적 수준

한 사람은 정확하게 개념적 수준의 엔티티 유형으로 묘사되고, 경우에 하나의 욕구가 관계형 데이터베이스를 구현하기 위해 전달한다의 의미하는 것이 사람 과 그와 관련된 모든 개념, 그 유형의 엔티티에 대한 사실을 미덕으로 관리 할 수 있습니다 논리적 인 수준 에서의 수학적 관계에 대한 설명을하고 , 그 추상적 인 구조에서 수행 될 수있는 과학 기반의 작업을 활용합니다 (즉, 그것을 정의하고 구속하고 조작합니다).

그렇습니다 . 데이터베이스의 논리적 배열을 정의 할 때 특정 관계 Person의 이름을 지정할 수 있지만 Person 의 "실제"개념을 관계로 변환하지는 않으며 정보를 관리 할 때 얻을 수있는 이점 때문에 이와 같이 접근합니다. 예를 들어, 관계형 대수 연산을 적용하여 새로운 관계를 도출합니다 (따라서 "새로운"정보를 도출합니다). 특정 유형의 엔티티가 세트를 구성하고 특정 속성의 값도 세트를 구성한다는 사실을 고려하여 상기 이점이 더욱 명백해진다.

그리고 이전 단락과 다른 답변에서 언급했듯이 관계의 가장 중요한 측면 중 하나 는 도메인 사이에 존재 하는 연결 입니다. 일반적으로이 속성의 일부인 엔터티 또는 연결 유형의 속성을 나타내는 데 사용됩니다. 개념적 스키마. 예를 들어 다음과 같은 (삼항) 관계를 선언했다고 가정 해 보겠습니다.

• Salary (PersonNumber, EffectiveDate, Amount)

… 문제가되는 비즈니스 환경에서 튜플 은 다음과 같이 가정합니다. (i) 특정 엔티티 , 즉 적용 가능한 개념 스키마의 엔티티 유형 인스턴스 , (ii) SQL 상대가 행 —

• Salary (x, y, z)

… 의미를 지닐 것입니다

• " xEffectiveDate에서 PersonNumber로 식별 된 개인에게 지불 된 급여 y는 금액에 해당합니다z . "

따라서 대략적인 방식으로 사물을 설명하기 위해 세 도메인 간의 연결이 가장 중요하며 모두 관련되어 있습니다 (단항 관계에는 하나의 도메인 만 포함됨 ). 특정 도메인의 모든 값 사이의 연결 은 정확한 유형 의 집합 을 구성하기 때문에 매우 중요 합니다 . 또한 Salary관계 의 각 튜플의 내용은 위에 표시된 어설 션 의 구조에 맞아야합니다 .

개념 수준 관계 및 논리 수준 관계

알 수 있듯이, 지금 즉, 추상화, 서로 다른 두 가지 수준에서 데이터베이스 관리 처리 한 개념 및 논리적 - 그리고으로 알려진 아직 낮은 수준이 실제 SQL DBMS를에 일반적으로 포함 하나, 예를 들어, 인덱스, 페이지, 익스텐트, 기타.-.

따라서 앞에서 설명한 개념에 따라 논리적 수준에서 하나는 (a) 수학적 관계에서만 작동합니다. (b) 개념적 관계 또는 연관은 (c) 이러한 수학적 관계의 튜플에 포함 된 값으로 표시 됩니다 . 상기 값은 일반적으로 적용 가능한 관계를 정확하게 나타낼 수 있도록 FOREIGN KEY 제약을 통해 구분된다.

그리고 예, 연관 엔티티, 즉 다 대다 (M : N) 카디널리티 비율을 갖는 관계 유형의 인스턴스는 단일 수학적 관계의 튜플을 통해 전달 될 수 있습니다. 코스-.

서브 질문 번호 2

관계형 모델이 계층 적 및 네트워크 모델을 따 랐음을 이해합니다. 그러나 이러한 모델에서 개체는 서로 관계가 있습니다. 그렇다면 왜이 모델을 관계형 모델이라고합니까? 더 구체적인 문구 / 용어가 있습니까? 아니면 세 모델이 모두 관계형 모델이지만 계층 적 및 네트워크 모델이 특정 유형의 관계형 모델이라고 말할 수 있습니까?

네트워크 및 계층 적 DBMS가 공식적인 이론적 지원에 앞서

계층 적 및 네트워크 접근법에 대한 이론적 지원 은 사실 기존의 DBMS 에 의해 만들어졌으며 , 다른 측면들 중에서도 (1) ​​종류의 건전성을 테스트하고 확립하는 것을 목표로한다. 소프트웨어와 (2) 연결된 데이터 관리 관행 (내 견해로는 거꾸로 된 현상).

관계형 프레임 워크와 비교할 때 불완전

즉, 관계형 모델 이전의 계층 적 및 네트워크 DBMS가 있지만 Codd 박사가 이러한 각 접근 방식을 "모델"이라고 언급 한 경우에도 관계형 프레임 워크와 동일한 방식으로 정의 된 것은 없습니다. 관계형 패러다임은 (i) 정의, (ii) 제한 및 (iii) 데이터 조작에 대한 과학적 구성을 제공하며, 계층 적 및 네트워크 접근 방식은 이전에 언급 한 세 가지 유형의 구성 모두를 포괄 할 수있는 이론적 지원이 부족합니다.

네트워크 및 계층 적 기능

또한 앞에서 언급했듯이 개체 및 관계 유형은 개념 수준의 장치이며 계층 적 또는 네트워크 접근 방식에 속하지 않으며 각 측면은 이러한 측면을 나타내는 특정 메커니즘을 제공합니다.

• 네트워크 패러다임 은 데이터 표현을위한 두 개의 장치, 즉 노드 와 아크 (물론 두 가지 다른 종류의 데이터 조작 작업을 의미 함)를 수반 합니다. 정보 모델에 따라 하나의 구성 만 요구 하는 관계형 모델과 대조되는 경우 (관계), 네트워크 방식으로 작업하는 데 필요한 불필요한 복잡성을 분명히합니다. 예를 들어, 두 개의 표현 도구에 의존하는 경우 네트워크 접근 방식 은 데이터 조작을 방해 하는 비실용적 인 쿼리 바이어스 를 부과합니다 .

• (! 실제) 그 부분을 들어, 계층보기의 방법으로 데이터를 나타내는 제안 파일 로 구성 기록 (다시 구성 필드 A의 조직) 세와 같은 배열; 즉, 데이터 조작과 관련하여 물리적 액세스 경로 를 생성하는 포인터 를 통해 가능한 많은 하위 대응 항목으로 연결된 하나의 상위 레코드 입니다. 이 접근 방식은 개념적 측면과 물리적 측면 사이에 얽힘을 제공하기 때문에 바람직하지 않으므로 물리적 스토리지 배열의 변경에는 데이터 구조의 재구성이 필요하며, 이에 따라 관련 데이터 조작 작업의 변경이 필요합니다.

도시 된 바와 같이, 관계 모델은 연관된 세트에 의하여 자연 구조 매끄럽게 데이터 관리를 제안하는 반면, 계층 및 네트워크 뷰는 데이터에 자신의 구조를 관리 할 부과 사실 (있는 N 세트의 후속 유형에 예상하지 디자인 단계에서 파생 될 수 있습니다!).

관계형 모델에는 하위 모델이 없습니다.

그리고 매우 중요한, 어느 계층 이나 네트워크 뷰는 관계형 모델의 특정 유형은, 그들은 누군가가 (a)는 빌드의 DBMS로와 (b)에 따라 데이터베이스를 만들 수 있지만 마음에 곰을 기쁘게 할 수 단순히 다른 패러다임은 그 계층 네트워크 접근 방식은 현재 수십 년 동안 더 이상 사용되지 않는 것으로 간주됩니다.

서브 질문 번호 삼

서로 관련이없는 독립형 엔터티가있는 경우 어떻게해야합니까? 말, 사람, 문 및 나무. "관계 (al)"라는 용어가 계속 적용됩니까?

예, (1) 적응 된 수학적 관계를 바탕으로 해당 엔티티 유형에 대한 정보를 관리하고 (2) 주어진 관계형 DBMS의 지원으로 관리되는 특정 데이터베이스에서 논리 레벨에서 적용 가능한 관계 연산을 수행하는 경우 완벽하게 적용 가능 .

개념적 수준에서, 상기 엔티티 유형이 다른 엔티티 유형과의 관계 유형을 보유하지 않는 경우 (그리고 엔티티 유형이 1 대 0 대 1 또는 많은 카디널리티 비율의 관계를 가질 수 있음을 주목할 가치가 있음) 그 자체로), 따라서 하나는 고려중인 관계의 튜플 값 사이의 관계를 전달하거나 집행하지 않는다.

'관계형 데이터베이스'의 흥미로운 점은 예상대로 테이블 간의 관계를 (주로) 참조하지 않지만 튜플에서 여러 속성 (열)의 관계를 나타냅니다. 관계형 데이터베이스는 이러한 튜플을 테이블에 행으로 저장합니다.

Alfred Tarski 가 1941 년에 정의한 관계 대수에 기초하고 있다 . 그는 상징적 논리에서 용어와 사용법의 역사를 요약했지만 결국 SQL의 기초가 된 작업을 정의했습니다.

Codd 는 이것을 그의 12 계명 에서 관계형 데이터베이스로 이해 될 수있는 것에 대한 정의로 바꾸었다 .

"관계"라는 용어는 수학에서 비롯되었으며 엔터티 간 관계와 관련이 없습니다. 나는 수학자가 아니고 (Codd는 수학 박사 학위를 가지고 있지만) 정교하지는 않지만 이진 관계 에 대한이 위키 백과 기사를 알려줄 것 입니다. Wikipedia 항목 관련 항목 (데이터베이스) 은 Codd가 수학 개념을 데이터 관리에 적용하는 방법에 대한 추가 정보를 제공합니다. 이 수학적 구조를 관계라고하는 이유는 관계를 구성하는 영역 사이에 "관계"가 있다는 생각과 관련이 있다고 생각합니다. 내가 Codd의 원래 생각을 더 잘 이해하는 가장 좋은 출처는 Fabian Pascal '. Chris Date는 RDM에 광범위하게 글을 썼으며 그의 Third Manifesto 사이트에는 논문과 서적을 나열하는 섹션이 있습니다. 그의 저서 인 컴퓨팅 전문가를위한 관계 이론 (The Relational Theory for Computing Professionals )은 좋은 소개입니다. 이게 도움이 되길 바란다.

자연스러운 키로 생각할 때 직관적 인 이름입니다. 셀 값을 엔티티를 나타내는 것으로 생각할 수 있습니다.

Relation: Employee
|--------+------------+--------|
| name   | job        | boss   |
|--------+------------+--------|
| Mark   | owner      | NULL   |
| Bob    | manager    | Mark   |
| Jane   | supervisor | Bob    |
| Claire | supervisor | Bob    |
| John   | cashier    | Jane   |
| Jesse  | cashier    | Jane   |
| Jason  | cashier    | Claire |
|--------+------------+--------|

• 직원 이름 "Jane"은 "supervisor"작업과 관련이 있습니다.
• 직원 이름 "John"은 보스 "Jane"과 관련이 있습니다.
• "캐셔"작업은 "John", "Jesse"및 "Jason"직원 이름과 관련이 있습니다.
• "캐셔"작업은 보스 "Jane"및 "Claire"와 관련됩니다.

데이터베이스에 대해 많은 말을해야하는 매우 긴 답변을 이미 수락했지만 실제로 요청한 질문에 대답하겠습니다.

왜 "관계형"이라는 용어인가.

테이블은 수학 개체 "관계"의 구체적인 인스턴스이기 때문입니다.

RDBMS가 아닌 수학에서 "관계"라는 용어에 대해 Wikipedia의 의견을 확인한 다음 데이터베이스로 변환 해 보겠습니다 .

공식적으로 관계는 동일한 정도의 n- 튜플 집합입니다. 따라서 이진 관계는 쌍 집합, 삼항 관계, 삼중 집합 등입니다. 세트 이론의 언어에서 두 세트 간의 관계는 카티 전 곱의 하위 세트입니다.

Mathematics             | RDBMS
========================|===============
A relation is           | A table is
a set of                | a bunch of 
n-tuples                | rows
of equal degree.        | with the same cell (a.k.a. column) types and sizes.

그것은 이론을 계속 설정합니다. 이것은 데이터베이스의 것보다 훨씬 더 추상적 인 수학이라는 것을 기억하십시오. 따라서 마지막 문장은

두 세트 간의 관계는 카티 전 곱의 하위 집합입니다.

이것은 두 개의 열 이있는 하나의 테이블로 변환됩니다 .

• 열 A를 "이름"이라고하겠습니다. 수학적 세트 A는 모든 (인간) 이름 세트입니다.
• 열 BI 호출 "도시". 수학적 세트 B는 모든 도시의 세트입니다.
• 르트 A x B(수학)는 모든 쌍 (일명, tupels)으로 포함하는 새로운 세트이다 의 구성원 과 의 일원이다 . 즉, 이름이며 도시입니다. 예는 또는 입니다. 그러나 데카르트 곱은 그중 일부일뿐만 아니라 그 모든 것입니다. 요점을 맞추기위한 관계는 해당 직교 곱의 하위 집합입니다. 즉, 관계는 쌍 금액 (로 정의)되는 이름이며, 도시, 전혀조차 없음입니다.(a, b)aAbBab(Alice, New York)(Bob, Hollywood)(a, b)ab

이제 모든 것이 이해되기를 바랍니다. RDBMS에서 테이블의 행은 단순히 해당 열에서 가능한 모든 조합의 데카르트 곱의 서브 세트를 선택합니다. 즉, RDBMS를 사용할 때 완전히 사소하고 관련이 없습니다.

컴퓨터 과학, 관계형 데이터베이스를 포함하지만 이후 않는 수학에 뿌리를 가지고, 우리는 여기에 "관계"라는 용어를 타고있다. 그것은 완전히 추상적이며 사람들 사이의 관계 또는 당신과의 관계와 관련이 없습니다.

따로, "관계"라는 용어는 때때로 "연관"에도 사용되며, 정확히 동일합니다 (여기서는 관계의 기본 집합이 위에서 설명한 관계 (일명 테이블) 임).

NB : 수학에서 관계는 데이터베이스에 관한 것이 아니라 함수와 같은 것입니다. 좀 더 일반적인 것입니다 (제발, 모든 수학자 여러분, 지금 nitpick을 시작하지 마십시오, 우리는 수학이 아니라 dba.SE에 있습니다. 이것은 잘못된 길입니다 :)). 이와 같은 함수 f(x)=x+1는 튜플 세트로 표현할 수 (1, 2), (2, 3), ...있지만 튜플 의 왼쪽에는 모든 숫자를 한 번만 가질 수 있습니다. 즉, 이것은 유효한 기능이 아닙니다 : (1, 2), (1, 3), .... 그러나 후자 는 유효한 관계 일 것이다. 즉, 당신은 뉴욕에서 밥 가질 수 와 할리우드에서 밥을.

관계형 데이터베이스 는 관계형 EFCodd 모델 을 기반으로합니다 . 관계 대수는 어떻게 쿼리 데이터의 방법을 설명합니다. 관계는 단순히 일부 집합 (도메인)의 교차 산물의 일부입니다.

예

우리는 다음과 같은 세트를 가지고 있습니다 :

DepIds = {1, 2, 3, ...}
EmpIds = {1, 2, 3, ...}
DepNames = {'Engineering', 'Finance', 'Sales', ...}
FirstNames = {'John', 'Walter', 'Mary', 'Roxane', ...}
LastNames = {'Smith', 'Bondy', 'Taylor', ...}
BirthDates = {..., 1950-01-01, 1950-01-02, ...}
Jobs = {'Accountant', 'Programmer', 'Database Administrator', ...}

또한 우리는 튜플 세트를 가지고 있습니다.

departements = { 
    (1, 'Engineering'), 
    (2, 'Finance')}
employees = { 
    (1, 1, 'John', 'Taylor', 1985-03-22, 'Programmer'), 
    (2, 1, 'Walter', 'Bondy', 1997-09-11, 'Database Administrator'), 
    (3, 2, 'Roxane', 'Myers', 1987-12-19, 'Accountant')}

departements 의 하위 집합입니다

    DepIds x DepNames

관계입니다.

employees 의 하위 집합입니다

    EmpIds x DepIds x FirstNames x LastNames x BirthDates x Jobs

관계도 마찬가지입니다.

테이블로 관계를 구현할 수있는 방법이 분명합니다.

수학자들은 왜 튜플 집합을 관계라고 부릅니까?

일반적으로 '3보다 작은 2', '4는 4', '2는 1과 3.4 사이', '-1은 음수'와 같은 속성을 관계라고합니다.

세트 A = {1, 2, 3}에서 '보다 작음'관계는 서브 세트로 정의됩니다.

{(1, 2), (1, 3), (2, 3) }

의

A x A = {1, 2, 3} x {1, 2, 3}=
{ (1, 1), (1, 2), (1, 3), 
  (2, 1), (2, 2), (2, 3), 
  (3, 1), (3, 2), (3, 3) } 

비슷한 방식으로 다른 관계도 교차 산물의 하위 집합으로 볼 수 있습니다. 'x보다 y보다 작음', 'x와 같음 y'는 이진 관계이므로 쌍 세트로 정의됩니다. 'y와 z 사이의 x'는 삼항 관계이므로 삼중 집합으로 정의됩니다. 'x는 음수'는 단항 관계이므로 단일 집합으로 정의됩니다.

위에서 정의한 부서 튜플 세트는 이진 관계이고 직원 관계는 6 진 관계입니다.