개체, 애트리뷰트, 개체집합
개체(entity)
실세계에서 다른 객체들로부터 구분될 수 있는 객체를 개체라고 한다.
개체집합(entity set)
같은 종류의 개체들의 모임을 개체 집합이라고 한다.
애트리뷰트(attribute)
개체의 속성을 말한다.
어떤 두 개체에서 애트리뷰트들이 같다는 것은 두 개체가 같은 종류라는 것을 의미한다.
즉, 개체를 구분해주는 것은 속성, 애트리뷰트라는 것이다.
개체 집합과 관련한 각 애트리뷰트에 대해, 값의 범위인 도메인(Domain)을 지정해야 한다.
ex) name 애트리뷰트는 1 ~ 20 개의 문자들로 이루어진 문자열.
키(key)
주어진 집합에 속하는 한 개체를 유일하게 식별하는 값을 갖는 최소 개의 애트리뷰트들로 이루어진 집합을 말한다.
최소성을 충족하지 않아도 식별이 되면 super key라고 한다.
후보(candidate)키는 하나보다 더 많을 수 있다. 그럴 경우 그들 중의 하나를 기본(primary)키로 지정한다.
예제▼
관계와 관계집합
관계
둘 이상의 개체들 사이의 관련성을 말한다. ▼
관계도 기술적인 애트리뷰트를 가질 수 있다.(그림의 since)
관계 집합
같은 종류의 관계들을 하나의 집합으로 모은것을 말한다.
n - 튜플들의 집합으로 생각할 수도 있다.
관계 집합의 인스턴스
관계들의 집합의 실물이라고 생각할 수 있다.
어느 특정 시점에서의 관계 집합의 ‘스냅샷’으로 생각할 수도 있다.▼
삼진 관계 집합
관계가 꼭 두 개체 집합과의 관계일 필요는 없다.
셋의 관계를 묶은 관계 집합도 있으나, 이게 효율적인가에 대해서는 생각을 해봐야 한다.▼
동일한 객체집합에 속하는 두 개체를 포함하는 관계
한 관계집합에 참여하는 개체집합들이 서로 다를 필요는 없다.
고정관념적으로 관계를 맺는 것은 서로 다른 두 개체집합일 것이라고 생각했겠지만, 하나의 관계집합에서의 관계도 있다. ▼
한 객체집합에서의 관계를 표현한 다이어그램.
역할 지시자에 의해 ssn은 supervisor_ssn과 subordinate_ssn이 된다.
한 직원이 다른 직원에게 보고하는 관계이다.
Reports_To의 관계는 (emp1, emp2)로 나타낼 수 있다.
emp1과 emp2는 모두 employees에 속하지만 역할이 다르다.
supervisor와 subordinate는 역할 지시자이다.
역할 지시자는 애트리뷰트 이름과 함께 붙여져서 관계 집합 내의 애트리뷰트에 유일한 이름을 붙여준다.
ER 모델의 특별 기능
키 제약조건(key constraints)
이런 제약조건들 중에서 키에 대한 제약조건을 키 제약조건이라고 하며, 키 제약조건에는 여러가지 제약조건들이 있다.
예제▼
명세 : 각 부서(Departments)에는 많아야 한 명의 관리자가 있을 수 있다.
화살표의 의미
주어진 Departments 개체에서 Manages 관계를 유일하게 결정할 수 있다.
← 일-대-다 (one-to-many)
만약에 Employees에서 Manages로 향하는 화살표도 추가하면 일-대-일(one-to-one)관계가 된다.
제약 조건의 설계(constraints design)
개체무결성 (entity integrity)
기본 키는 각 레코드의 기본이 되는 값이므로 null 값을 가질 수 없다.
참조무결성 (referential integrity)
외래키는 참조하는 테이블에 존재하는 값이어야 한다.
도메인 무결성 (domain integrity)
데이터의 값은 해당 컬럼에서 존재할 수 있는 값을 지녀야 한다.
사용자정의 무결성 (general integrity)
가장 많이 사용되는 무결성 조건이다.
데이터베이스에 특정 이벤트(Create, Delete, Update)가 발생했을 때, 체크를 하게 하여 무결성을 유지하게 한다.
이를 trigger machanism이라고 한다.
참여 제약조건(participation constraints)
전체적(total)
개체 집합의 모든 개체가 관계를 맺고 있는 것을 말한다.
부분적(partial)
전체적인 참여가 아닌 것을 부분적 참여라고 말한다.
전체적과 부분적,
이 둘과 관련된 제약을 거는 것이 참여 제약 조건이다.
예제▼
전체 참여제약조건은 굵은 선으로 표시한다.
Works_In 관계를 보면, Employees와 Department 모두 전체 참여를 하고 있다.
따라서 왼쪽의 ER 관계도도 만족한다.
Manages 관계 집합을 보면 Departments는 모두 관계를 맺고 있으니 전체적이다.
하지만 Employees는 모두 관계를 맺고 있지 않으므로 부분적이다.
약 개체(weak entity)
우리는 지금까지 개체집합이 항상 키를 갖고 있는 예제만 봤지만, 사실 개체 집합이 항상 키를 갖고 있는 것은 아니다.
위의 정보가 잘 와닿지 않을 것이기에 예제를 통해 확인해보자.
예제▼
한 직원이 부양자를 위한 보험증권을 구매할 수 있고, 누구의 보험증권인지에 대해 식별하기 위해 부양자는 pname과 age 애트리뷰트를 가진다.
하지만 문제는 pname과 age 애트리뷰트들은 Dependents의 개체들을 유일하게 식별하지 않는다.
Employees의 key는 ssn이기 때문에 smethurst라는 이름을 갖는 동명이인의 두 직원이 각기 Joe라는 아들을 둘 수 있다.▼
Emplyees는 ssn으로 식별이 된다.
허나 Dependents는 그 자체로는 식별이 되지 않는다.
대신 Dependents는 Employees와 같이 보면 식별이 된다.
약 개체의 조건
약 개체 집합은 다음 사항을 만족해야한다.
- 소유자 개체집합과 약 개체집합은 일-대-다 관계집합으로 참여해야 한다.
- 약 개체집합은 식별 관계집합에 전체적으로 참여해야 한다.
클래스 계층(ISA)
클래스 계층은 상속 관계를 나타낸다.▼
각 개체집합에 속하는 모든 개체들은 Employees 개체들이다.
Hourly_Emps와 Contract_Emps에 의해 Employees의 애트리뷰트들이 상속된다.
클래스 계층의 두 관점
- Employees의 특수화(Specialization)
- Hourly_Emps와 Contract_Emps의 Employees로의 일반화(Generalization)
중첩 제약 조건
두 서브 클래스가 같은 개체를 포함하는 것이 허락되는가를 결정한다.
이 말은 즉, 교집합이 있을 수 있냐는 말과 같다. ▼
Contract_Emps 개체이면서 Senior_Emps 개체일 수 있다면, `Contract_Emps OVERLAPS Senior_Emps` 라고 표시한다.
포괄 제약 조건
모든 서브 클래스에 속해 있는 개체들이 집합적으로 슈퍼 클래스의 모든 개체들을 포함하는가를 결정한다.
이 말은 즉, 전체 집합이 자식 집합으로만 구성되냐는 말과 같다. ▼
모든 Motor_Vehicle 개체는 Motorboats 개체거나 Cars 개체임은 직관적이다.
이런 경우에, `Motorboats AND Cars COVER Motor_Vehicle` 라고 표시한다.
집단화
개체들의 모임과 관계들의 모임간의 관계를 설정해 주기 위한 것이다.
어떤 관계 집합이 다른 관계 집합에 참여하는 것을 나타낼 수 있게 한다.
ER 모델을 이용한 개념적 설계
개체와 애트리뷰트 간의 선택
특정 요소를 개체로 둘 지, 애트리뷰트로 둘 지에 대한 선택은 일반적으로는 아래의 두 상황을 보고 고르면 된다.
- 여러 개를 입력해야 함 - 조건 1
ex) 한 직원에 여러 주소를 입력할 수 있어야 함.
- 구조를 표현해야 함 - 조건 2
ex) 시, 군, 구 와 같은 세부 주소를 넣어야 함.
위 두 상황 중 하나라면, 개체 집합으로 만들어서 관계를 걸어주는 것이 좋을 것이다.▼
| 조건 1 - T | 조건 1 - F | |
| 조건 2 - T | 개체 | 개체/애트리뷰트 |
| 조건 2 - F | 개체 | 애트리뷰트 |
예제▼
① 번의 경우
근무 기간을 기록해야 함.
근무 기간은 from, to로 구조가 나뉨.
한 Employee 당 근무 기간은 하나씩임.
→ 애트리뷰트
② 번의 경우
근무 기간을 기록해야 함.
근무 기간은 from, to로 구조가 나뉨.
한 Employee 당 근무 기간을 여러 개 가질 수 있음.
→ 개체 집합
개체와 관계간의 선택
재량 예산(dbudget)이라는 애트리뷰트가 추가됐다고 생각해보자.
이 재량 예산이 각 부서의 재량 예산이라고 하면 꽤나 타당하다. ▼
하지만 이 재량 예산이 한 관리자가 관리하는 모든 부서의 총 예산이라고 하면 데이터 중복이 일어나게 된다. ▼
51번과 56번의 총 재량 예산을 2345-6789번 Employee가 관리한다고 하면, 각 Department에 대한 재량 예산 정보는 하나만 있어도 되지만, Manages와 Department가 각각 연결이 되어있어서 중복된 정보를 갖게 된다.
중복되면 뭐 어때? 라고 생각할 수 있지만, 이는 꽤나 큰 문제다.
만약 2022/3/1로 기록되어있는 재량 예산이 50000으로 바뀌었는데, 2022/8/29로 기록되어있는 재량 예산을 참조하게 되면 그대로 60000이라는 재량 예산 값을 받게 된다.
데이터 중복이라는 것은 단순 중복의 문제보다 데이터 갱신과 읽기 쓰기의 문제가 굉장히 크다.
이런 문제는 Employees 아래에 ISA를 배치하여 Managers 계층을 만들면 해결이 된다.
이런 식으로 모호하고 부정확하게 ER 다이어그램을 제시하면 문제가 발생할 수 있다.
이진 관계와 삼진 관계간의 선택
아래와 같은 다이어그램의 명세가 있다고 해보자.
❶ 하나의 보험증권은 두 명 이상의 직원에 의해 함께 소요될 수 없다.
❷ 각 보험증권은 반드시 어떤 직원에 의해 소유되어야 한다.
❸ 부양 가족은 약 개체 집합이며, 각 부양가족 개체는 pname과 그 부양가족을 보장하는 보험증권 개체의 policyid와 조합하여 유일하게 식별된다.
위의 다이어그램 명세를 삼진 관계로 짜면 아래의 그림과 같이 나온다.▼
하지만 위와 같이 짜면 각 요구 사항에 문제가 발생하게 된다.
❶번 요구사항 : 한 증권이 한 명의 부양 가족을 보장할 수 있다는 부작용을 낳는다.
❷번 요구사항 : Policies에 전체 참여 제약조건을 부여해야하는데, 각 증권이 적어도 한 명의 부양가족을 보장하는 경우에만 가능한다.
❸번 요구사항 : 이진 식별관계를 도입한다.
종합적으로 봤을 때 삼진관계는 좋지 않기에 아래와 같이 2개의 이진 관계를 사용하는 것이 좋다.▼
