Extended E-R model - 편집 역사

Ahn9807: 봇: 자동으로 텍스트 교체 (-\[\[분류:데이터베이스 시스템(\|[^\]]+)?\]\] +분류:데이터베이스\1)

2026-01-15T12:49:43Z

봇: 자동으로 텍스트 교체 (-\[\[분류:데이터베이스 시스템(\|[^\]]+)?\]\] +분류:데이터베이스\1)

← 이전 판		2026년 1월 15일 (목) 12:49 판
106번째 줄:		106번째 줄:

	==각주==		==각주==
	[[분류:데이터베이스 ~~시스템~~]]		[[분류:데이터베이스]]

Pinkgo: /* Representing Secialization via Schema */

2025-04-20T05:37:45Z

Representing Secialization via Schema

← 이전 판		2025년 4월 20일 (일) 05:37 판
27번째 줄:		27번째 줄:
	# 상위 엔터티와 하위 엔터티 각각 스키마 분리		# 상위 엔터티와 하위 엔터티 각각 스키마 분리
	## 상위 entity set에 대해 하나의 schema를 만든다.		## 상위 entity set에 대해 하나의 schema를 만든다.
	##* person(ID, name, street, city)		##* person(<u>ID</u>, name, street, city)
	## 하위 entity set마다 별도의 schema를 만들고, 상위 entity set의 primary key와 local attribute를 포함시킨다.		## 하위 entity set마다 별도의 schema를 만들고, 상위 entity set의 primary key와 local attribute를 포함시킨다.
	##* student(ID, tot_cred), employee(ID, salary)		##* student(<u>ID</u>, tot_cred), employee(<u>ID</u>, salary)
	#* 장점: data redundancy가 없다.		#* 장점: data redundancy가 없다.
	#* 단점: specialized된 entity set을 조회하기 위해서는 상위 entity set의 속성까지 참조해야 하므로 복잡성과 조회 시간이 증가한다. <br>예를 들어, employee에 대한 정보를 조회할 때, person과 employee 두 테이블을 조인해야 한다.		#* 단점: specialized된 entity set을 조회하기 위해서는 상위 entity set의 속성까지 참조해야 하므로 복잡성과 조회 시간이 증가한다. <br>예를 들어, employee에 대한 정보를 조회할 때, person과 employee 두 테이블을 조인해야 한다.
	# 모든 entity마다 완전한 schema를 만든다.		# 모든 entity마다 완전한 schema를 만든다.
	## 각 entity set마다 스키마를 만들고, 상속된 속성까지 포함시킨다.		## 각 entity set마다 스키마를 만들고, 상속된 속성까지 포함시킨다.
	##* person(ID, name, street, city)<br>student(ID, name, street, city, tot_cred)<br>employee(ID, name, street, city, salary)		##* person(<u>ID</u>, name, street, city)<br>student(<u>ID</u>, name, street, city, tot_cred)<br>employee(<u>ID</u>, name, street, city, salary)
	#* 장점: specialized된 entity set을 조회할 때에도 해당 entity set의 schema만을 조회하면 된다.		#* 장점: specialized된 entity set을 조회할 때에도 해당 entity set의 schema만을 조회하면 된다.
	#* 단점: data redundancy가 발생한다. 예를 들어, student이자 employee인 경우 name, street, city가 중복 저장된다.		#* 단점: data redundancy가 발생한다. 예를 들어, student이자 employee인 경우 name, street, city가 중복 저장된다.

Pinkgo: /* Generalization의 표현 */

2025-04-20T05:25:02Z

Generalization의 표현

← 이전 판		2025년 4월 20일 (일) 05:25 판
84번째 줄:		84번째 줄:

	첫번째 방법은 상위 수준의 entity set을 위한 schema를 생성하고, 각각의 secialized된 entity set마다 해당 집합의 모든 attribute와 상위 수준 entity set의 primary key를 포함하는 schema를 생성하는 것이다. 이를 person과 student, employee에 적용하면 다음과 같다.		첫번째 방법은 상위 수준의 entity set을 위한 schema를 생성하고, 각각의 secialized된 entity set마다 해당 집합의 모든 attribute와 상위 수준 entity set의 primary key를 포함하는 schema를 생성하는 것이다. 이를 person과 student, employee에 적용하면 다음과 같다.
	person(~~__ID__~~, name, street, city)		person(<ins>ID</ins>, name, street, city)
	employee(~~__ID__~~, salary)		employee(<ins>ID</ins>, salary)
	student(~~__ID__~~, tot_cred)		student(<ins>ID</ins>, tot_cred)
	이때 상위 수준 entity set의 primary key(ID)는 하위 수준 entity set에 대해서도 primary key가 된다. 또한 specialized된 entity set에 대해 [[Relational Model#Keys\|foreign-key constraint]]를 설정한다. 즉, specialized된 entity schema의 ID는 상위 schema의 primary key(person.ID)를 참조하게 된다. <br>		이때 상위 수준 entity set의 primary key(ID)는 하위 수준 entity set에 대해서도 primary key가 된다. 또한 specialized된 entity set에 대해 [[Relational Model#Keys\|foreign-key constraint]]를 설정한다. 즉, specialized된 entity schema의 ID는 상위 schema의 primary key(person.ID)를 참조하게 된다. <br>

Pinkgo: /* Aggregaion의 표현 */

2025-03-29T14:58:23Z

Aggregaion의 표현

← 이전 판		2025년 3월 29일 (토) 14:58 판
95번째 줄:		95번째 줄:
	===Aggregaion의 표현===		===Aggregaion의 표현===
	Aggreation을 포함한 E-R 다이어그램의 스키마를 설계하는 것은 직관적이다. aggreation을 설명할 때 사용했던 예시를 바탕으로 설명을 하면, 집합화된 관계 proj_guide와 evaluation 사이의 관계 집합 eval_for를 위한 스키마는 다음을 포함한다:		Aggreation을 포함한 E-R 다이어그램의 스키마를 설계하는 것은 직관적이다. aggreation을 설명할 때 사용했던 예시를 바탕으로 설명을 하면, 집합화된 관계 proj_guide와 evaluation 사이의 관계 집합 eval_for를 위한 스키마는 다음을 포함한다:
	* evaluation 엔터티의 primary key 속성들		* 집합화된 관계의 Primary Key
	* 관계 집합 proj_guide의 기본 키 속성들		** evaluation 엔터티의 primary key 속성들(evaluaiotn_id)
			* 관련 엔터티의 Primary Key
			** 관계 집합 proj_guide의 기본 키 속성들
	* 관계 eval_for의 decriptive attributes (존재한다면)		* 관계 eval_for의 decriptive attributes (존재한다면)
			이에 따라 eval_for는 아래와 같이 schema화 된다.
			eval_for (s_ID, project_id, i_ID, evaluation_id)
			그런 다음 집합화된 엔티티 집합(proj_guide) 내의 관계와 엔티티 집합들은 기존 규칙들에 따라 변환된다. <br>
			하지만 주의할 점이 있는데, aggregation으로 인해 추상화되어 만들어진 proj_quide에 대한 별도의 상위 수준의 엔티티 집합 schema는 만들 필요가 없다. proj_guide는 실제로는 관계 집합이고, 집합화가 된다고 해서 진짜 테이블처럼 분리할 필요는 없다는 의미이다. 이미 eval_for에서 proj_guide의 primary key들을 포함하고 있기 때문이다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Reduction to Relation Schemas */

2025-03-29T14:48:58Z

Reduction to Relation Schemas

← 이전 판		2025년 3월 29일 (토) 14:48 판
87번째 줄:		87번째 줄:
	employee(__ID__, salary)		employee(__ID__, salary)
	student(__ID__, tot_cred)		student(__ID__, tot_cred)
	이때 상위 수준 entity set의 primary key(ID)는 하위 수준 entity set에 대해서도 primary key가 된다. 또한 specialized된 entity set에 대해 [[Relational Model#Keys\|foreign-key constraint]]를 설정한다. 즉, ~~하위 스키마의~~ ID는 상위 ~~스키마의 기본 키~~(person.ID)를 참조하게 된다.		이때 상위 수준 entity set의 primary key(ID)는 하위 수준 entity set에 대해서도 primary key가 된다. 또한 specialized된 entity set에 대해 [[Relational Model#Keys\|foreign-key constraint]]를 설정한다. 즉, specialized된 entity schema의 ID는 상위 schema의 primary key(person.ID)를 참조하게 된다. <br>

			두번째 방법은 generalization이 disjoint이고 complete일 경우에 사용된다.<ref>어떤 엔터티도 두 개의 하위 집합에 동시에 속하지 않고, 상위 집합의 모든 엔터티가 반드시 하나의 하위 집합에 속하는 경우이다.</ref> 이 경우에는 상위 수준의 entity set에 대한 schema를 제공하지 않고 각 하위 수준의 entity set마다 해당 집합과 상위 entity set의 모든 속성들을 포함하는 schema를 생성한다. 예를 들면 다음과 같다.
			employee(ID, name, street, city, salary)
			student(ID, name, street, city, tot_cred)

			===Aggregaion의 표현===
			Aggreation을 포함한 E-R 다이어그램의 스키마를 설계하는 것은 직관적이다. aggreation을 설명할 때 사용했던 예시를 바탕으로 설명을 하면, 집합화된 관계 proj_guide와 evaluation 사이의 관계 집합 eval_for를 위한 스키마는 다음을 포함한다:
			* evaluation 엔터티의 primary key 속성들
			* 관계 집합 proj_guide의 기본 키 속성들
			* 관계 eval_for의 decriptive attributes (존재한다면)

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

Pinkgo: /* Reduction to Relation Schemas */

2025-03-29T14:34:56Z

Reduction to Relation Schemas

← 이전 판		2025년 3월 29일 (토) 14:34 판
84번째 줄:		84번째 줄:

	첫번째 방법은 상위 수준의 entity set을 위한 schema를 생성하고, 각각의 secialized된 entity set마다 해당 집합의 모든 attribute와 상위 수준 entity set의 primary key를 포함하는 schema를 생성하는 것이다. 이를 person과 student, employee에 적용하면 다음과 같다.		첫번째 방법은 상위 수준의 entity set을 위한 schema를 생성하고, 각각의 secialized된 entity set마다 해당 집합의 모든 attribute와 상위 수준 entity set의 primary key를 포함하는 schema를 생성하는 것이다. 이를 person과 student, employee에 적용하면 다음과 같다.
	person(ID, name, street, city)		person(__ID__, name, street, city)
	employee(ID, salary)		employee(__ID__, salary)
	student(ID, tot_cred)		student(__ID__, tot_cred)
			이때 상위 수준 entity set의 primary key(ID)는 하위 수준 entity set에 대해서도 primary key가 된다. 또한 specialized된 entity set에 대해 [[Relational Model#Keys\|foreign-key constraint]]를 설정한다. 즉, 하위 스키마의 ID는 상위 스키마의 기본 키(person.ID)를 참조하게 된다.

	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

2025년 3월 29일 (토) 14:30에 Pinkgo님의 편집

2025-03-29T14:30:18Z

← 이전 판		2025년 3월 29일 (토) 14:30 판
78번째 줄:		78번째 줄:

	aggregation의 장점은 proj_guide에 대한 rudundancy 없이 evaluation entity와의 관계를 형성할 수 없다는 것이다. 또한 evaluation이 secretary entity들과도 추가적으로 연결될 수 있다는 점에서 유연성이 증가된다. 마지막으로 evaluaiton이 어떤 지도 활동에 대한 것인지 명확하게 표현된다는 점에서 모델링의 명확성 또한 올라간다는 장점을 지닌다.		aggregation의 장점은 proj_guide에 대한 rudundancy 없이 evaluation entity와의 관계를 형성할 수 없다는 것이다. 또한 evaluation이 secretary entity들과도 추가적으로 연결될 수 있다는 점에서 유연성이 증가된다. 마지막으로 evaluaiton이 어떤 지도 활동에 대한 것인지 명확하게 표현된다는 점에서 모델링의 명확성 또한 올라간다는 장점을 지닌다.

			==Reduction to Relation Schemas==
			===Generalization의 표현===
			Generalization이 포함되는 E-R 다이어그램을 위한 relation schema를 설계하는 두가지 방법이 존재한다. 이를 설명하기 위해 specialization에서 설명된 person entity set과 specialized된 entity set student와 employee를 예를 들어 설명할 것이다. 이때 person의 primary key는 ID이다.

			첫번째 방법은 상위 수준의 entity set을 위한 schema를 생성하고, 각각의 secialized된 entity set마다 해당 집합의 모든 attribute와 상위 수준 entity set의 primary key를 포함하는 schema를 생성하는 것이다. 이를 person과 student, employee에 적용하면 다음과 같다.
			person(ID, name, street, city)
			employee(ID, salary)
			student(ID, tot_cred)


	==각주==		==각주==
	[[분류:데이터베이스 시스템]]		[[분류:데이터베이스 시스템]]

2025년 3월 29일 (토) 14:17에 Pinkgo님의 편집

2025-03-29T14:17:51Z

@@ 63번째 줄: / 63번째 줄: @@
 * total-overlapping
 * total-disjoint
 ==각주==
 [[분류:데이터베이스 시스템]]

Pinkgo: /* Completeness constraint */

2025-03-29T13:41:25Z

Completeness constraint

← 이전 판		2025년 3월 29일 (토) 13:41 판
46번째 줄:		46번째 줄:

	==Completeness constraint==		==Completeness constraint==
	~~[[파일:Total(disjoint) generation.jpg\|섬네일\|300x300픽셀\|Total(disjoint) generation]]~~
	데이터베이스를 더 정확하게 모델링하기 위해, 데이터베이스 설계자는 특정한 specialization/generlization에 대한 일정한 제약 조건을 설정할 수 있다.		데이터베이스를 더 정확하게 모델링하기 위해, 데이터베이스 설계자는 특정한 specialization/generlization에 대한 일정한 제약 조건을 설정할 수 있다.
	우리가 앞서 본 specialization 제약 조건의 한 종류는, specialization가 disjoint인지 또는 overlapping인지 여부를 명시하는 '''disjointness constraint'''이다. 또 다른 유형의 제약 조건은 '''completeness constraint'''으로, 이는 specialization/generlization 내에서 상위 entity set의 entity가 반드시 하나 이상의 하위 entity set에 속해야 하는지 여부를 지정한다.		우리가 앞서 본 specialization 제약 조건의 한 종류는, specialization가 disjoint인지 또는 overlapping인지 여부를 명시하는 '''disjointness constraint'''이다. 또 다른 유형의 제약 조건은 '''completeness constraint'''으로, 이는 specialization/generlization 내에서 상위 entity set의 entity가 반드시 하나 이상의 하위 entity set에 속해야 하는지 여부를 지정한다.
53번째 줄:		52번째 줄:
	* Total specialization/generalization: 모든 상위 entity는 반드시 하나의 하위 entity set에 속해야 한다.		* Total specialization/generalization: 모든 상위 entity는 반드시 하나의 하위 entity set에 속해야 한다.
	* Partial specialization/generalization: 일부 상위 entity는 어떤 하위 entity set에 속하지 않을 수 있다.		* Partial specialization/generalization: 일부 상위 entity는 어떤 하위 entity set에 속하지 않을 수 있다.
			[[파일:Total(disjoint) generation.jpg\|섬네일\|200x200px\|Total(disjoint) generation]]
	예를 들어, person을 student 또는 employee로 특수화하는 경우, 만약 학교가 student도 아니고 employee도 아닌 person을 표현할 필요가 없다면, total specialization에 속한다. 그러나 만약 어디에도 속하지 않는 person을 표현할 필요가 있다면, partial specialization에 속한다. <br>		예를 들어, person을 student 또는 employee로 특수화하는 경우, 만약 학교가 student도 아니고 employee도 아닌 person을 표현할 필요가 없다면, total specialization에 속한다. 그러나 만약 어디에도 속하지 않는 person을 표현할 필요가 있다면, partial specialization에 속한다. <br>
	이때 partial specialization이 기본 상태이다. total specialization을 따로 표시하기 위해서는 오른쪽 그림과 같이 다이어그램에 “total”이라는 키워드를 추가하고, 해당 키워드에서 점선을 적용되는 hollow arrowhead 또는 여러 개의 화살표 집합<ref>overlapping의 경우</ref>으로 연결한다.		이때 partial specialization이 기본 상태이다. total specialization을 따로 표시하기 위해서는 오른쪽 그림과 같이 다이어그램에 “total”이라는 키워드를 추가하고, 해당 키워드에서 점선을 적용되는 hollow arrowhead 또는 여러 개의 화살표 집합<ref>overlapping의 경우</ref>으로 연결한다.

Pinkgo: /* Completeness constraint */

2025-03-29T13:40:52Z

Completeness constraint

← 이전 판		2025년 3월 29일 (토) 13:40 판
46번째 줄:		46번째 줄:

	==Completeness constraint==		==Completeness constraint==
			[[파일:Total(disjoint) generation.jpg\|섬네일\|300x300픽셀\|Total(disjoint) generation]]
	데이터베이스를 더 정확하게 모델링하기 위해, 데이터베이스 설계자는 특정한 specialization/generlization에 대한 일정한 제약 조건을 설정할 수 있다.		데이터베이스를 더 정확하게 모델링하기 위해, 데이터베이스 설계자는 특정한 specialization/generlization에 대한 일정한 제약 조건을 설정할 수 있다.
	우리가 앞서 본 specialization 제약 조건의 한 종류는, specialization가 disjoint인지 또는 overlapping인지 여부를 명시하는 '''disjointness constraint'''이다. 또 다른 유형의 제약 조건은 '''completeness constraint'''으로, 이는 specialization/generlization 내에서 상위 entity set의 entity가 반드시 하나 이상의 하위 entity set에 속해야 하는지 여부를 지정한다.		우리가 앞서 본 specialization 제약 조건의 한 종류는, specialization가 disjoint인지 또는 overlapping인지 여부를 명시하는 '''disjointness constraint'''이다. 또 다른 유형의 제약 조건은 '''completeness constraint'''으로, 이는 specialization/generlization 내에서 상위 entity set의 entity가 반드시 하나 이상의 하위 entity set에 속해야 하는지 여부를 지정한다.