2. 데이터 모델링에 대한 설명으로 가장 적절하지 않은 것은?
1️⃣ 업무 정보를 구성하는 기초가 되는 정보들을 일정한 표기법으로 표현한다.
2️⃣ 분석된 모델로 데이터베이스를 생성하여 개발 및 데이터관리에 사용한다.
3️⃣ 데이터베이스를 구축하는 목적으로 데이터 모델링을 수행하며 업무에 대한 설명은 별도의 표기법을 이용한다.
4️⃣ 데이터 모델링 자체로서 업무의 흐름을 설명하고 분석하는 부분에 의미를 가지고 있다.
📌 개념
데이터 모델링의 목적 : 1. 업무 내용 분석, 2. 데이터베이스 구축 및 관리
✅ 해설
1️⃣ 업무 정보를 표현 -> 업무 내용 분석
2️⃣ 데이터베이스를 생성하여 개발 및 데이터관리 -> 데이터베이스 구축 및 관리
3️⃣ (오답) 데이터베이스를 구축하는 목적 뿐은 아님 (업무 분석 등), 따라서 별도의 표기법을 이용해야 하는 것은 아님
4️⃣업무의 흐름을 설명하고 분석 -> 업무 내용 분석
3. 데이터 모델링을 할 때 유의해야 할 사항으로 적절하지 않은 것은?
1️⃣ 여러 장소의 데이터베이스에 같은 정보를 저장하지 않도록 하여 중복성을 최소화한다.
2️⃣ 데이터의 정의를 데이터의 사용 프로세스와 분리하여 유연성을 높인다.
3️⃣ 사용자가 처리하는 프로세스나 장표 등에 따라 매핑이 될 수 있도록 프로그램과 테이블 간의 연계성을 높인다.
4️⃣ 데이터 간의 상호 연관관계를 명확하게 정의하여 일관성 있게 데이터가 유지되도록 한다.
📌 개념
데이터 모델링의 유의사항 : 중복, 비유연성, 비일관성
- 중복 : 데이터 중복 저장
- 비유연성 : 데이터와 프로세스가 분리되지 않음 -> 유지보수성이 떨어짐
- 비일관성 : 데이터의 모순 발생 (데이터들이 갖는 관계에서 발생하는 모순)
✅ 해설
1️⃣ 중복성을 최소화 -> 중복 방지
2️⃣ 데이터의 정의와 사용 프로세스의 분리 -> 비유연성 방지
3️⃣ (오답) 프로그램과 테이블 간의 연계성을 높인다 -> 비유연성 발생
4️⃣ 연관관계를 명확하게 정의, 일관성 있게 데이터가 유지 -> 비일관성 방지
6. 아래에서 설명하는 스키마 구조로 가장 적절한 것은?
- 모든 사용자 관점을 통합한 조직 전체 관점의 통합적 표현
- 모든 응용시스템들이나 사용자들이 필요로 하는 데이터를 통합시킨 조직
전체의 DB를 기술한 것으로 DB에 저장되는 데이터와 그들 간의 관계를 표현하는 스키마1️⃣ 외부 스키마
2️⃣ 개념 스키마
3️⃣ 내부 스키마
4️⃣ 논리 스키마
📌 개념
스키마의 3단계 구조
- 외부 스키마 : 사용자 관점, 업무적 관점서 필요한 데이터 명세
- 개념 스키마 : 전체적인 논리 구조를 정의 (개체, 속성, 관계, 타입 ...)
- 내부 스키마 : 물리적인 저장 방식을 정의 (저장 구조, 컬럼, 인덱스 ...)
cf. 논리 스키마는 스키마의 3단계 구조에 포함되지 않음!
✅ 해설
2️⃣ (정답) 개념 스키마(통합 관점에서의 스키마 구조) <- 모든 "사용자 관점"을 "통합"한 조직 "전체 관점", DB에 저장되는 데이터와 그들 간의 관계
10. 엔터티의 특징으로 가장 적절하지 않은 것은?
1️⃣ 속성이 없는 엔터티는 있을 수 없다.
2️⃣ 엔터티는 다른 엔터티와 관계가 있어야 한다. 단, 통계성 엔터티나, 코드성 엔터티의 경우 관계를 생략할 수 있다.
3️⃣ 객체 지향의 디자인 패턴에는 싱글턴패턴이 있어 하나의 인스턴스를 가지는 클래스가 존재한다. 이와 유사하게 엔터티는 한 개의 인스턴스를 가지는 것만으로도 충분한 의미를 부여할 수 있다.
4️⃣ 데이터로서 존재하지만 업무에서 필요로 하지 않으면 해당 업무의 엔터티로 성립될 수 없다.
📌 개념
엔터티의 특징
1. 해당 업무에서 필요하고 관리하고자 하는 정보이어야 한다.
2. 유일한 식별자에 의해 식별이 가능해야 한다.
3. 영속적으로 존재하는 (2개 이상의) 인스턴스 집합이어야 한다.
4. 엔터티는 업무 프로세스에 의해 이용되어야 한다.
5. 엔터티는 반드시 속성이 있어야 한다.
6. 엔터티는 다른 엔터티와 최소 한 개 이상의 관계가 있어야 한다.
✅ 해설
1️⃣ 엔터티의 특징 5번에 부합
2️⃣ 엔터티의 특징 6번에 부합
3️⃣ (정답) 엔터티의 특징 3번에 위배
4️⃣ 엔터티의 특징 1번에 부합
12. 발생 시점에 따라 구분할 수 있는 엔터티의 유형으로 적절하지 않은 것은?
1️⃣ 관계 엔터티 (Relation Entity)
2️⃣ 행위 엔터티 (Active Entity)
3️⃣ 중심 엔터티 (Main Entity)
4️⃣ 기본 엔터티 (Fundamental Entity)
📌 개념
엔터티의 발생 시점에 따른 분류
- 기본 엔터티 : 원래 존재하는 정보, 독자적으로 생성
- 중심 엔터티 : 기본 엔터티로부터 발생, 업무에서 중심적인 역할
- 행위 엔터티 : 중심 엔터티의 확장
✅ 해설
1️⃣ (정답) 관계 엔터티는 발생 시점에 따른 구분이 아님
cf. 관계 엔터티 : N:M 관계를 해소하기 위한 엔터티 (M:N -> M : 1 + 1 : M, 여기서 1을 담당하는 것)
15. 속성에 대한 설명으로 가장 적절하지 않은 것은?
1️⃣ 엔터티에 대한 자세하고 구체적인 정보를 나타낸다.
2️⃣ 하나의 엔터티는 두 개 이상의 속성을 갖는다.
3️⃣ 하나의 인스턴스에서 각각의 속성은 하나 이상의 속성값을 가질 수 있다.
4️⃣ 속성도 집합이다.
📌 개념
✅ 해설
3️⃣ (정답) 하나의, 인스턴스에서, 하나의 인스턴스에서는 하나의 속성값만 가짐
cf. 4️⃣ 속성도 집합의 성질을 띔 (도메인)
ex) SqldStudy DB >> 스터디원 테이블 >> 성별 속성이 있다면 도메인은 { "남", "여" }로 표현 가능
16. 아래에서 수행한 정규화 작업으로 가장 적절한 것은? (단, 이후에 필요한 정규화 작업은 계속 수행될 예정)
1️⃣ 1차 정규화
2️⃣ 2차 정규화
3️⃣ 3차 정규화
4️⃣ 4차 정규화
📌 개념
정규화
- 1NF : 원자성 (원자값을 갖도록 = 여러 값을 갖지 않도록)
- 2NF : 완전 함수 종속성 ("기본키의 전체"에 종속되도록 <-> 부분 함수 종속성)
- 3NF : 이행적 종속성 제거 ((A->B, B->C)라면 (A->B)와 (B->C로 분리))
cf. 4NF & 5NF : 다치종속 & 조인종속 제거 )-> 라고 하네요~
✅ 해설
2️⃣ 2차 정규화
- PK는
주문 번호와주문상품코드 - 그러나
주문상품칼럼은주문상품코드에 종속될 수 있음 - 따라서
주문상품테이블에서상품을 분리
=> 테이블의 모든 속성은 기본키 전체에 종속됨
20. 데이터 모델링의 관계에 대한 설명으로 가장 적절하지 않은 것은?
1️⃣ 관계는 존재에 의한 관계와 행위에 의한 관계로 구분될 수 있으나 ERD에서는 관계를 연결할 때, 존재와 행위를 구분하지 않고 단일화된 표기법을 사용한다.
2️⃣ UML(Unified Modeling Language)에는 클래스다이어그램의 관계 중 연관관계(Association)와 의존관계(Dependency)가 있고 이것은 실선과 점선으로 다르게 표현된다.
3️⃣ 연관관계는 항상 이용하는 관계로 존재적 관계에 해당하고, 의존관계는 상대방 클래스의 행위에 의해 관계가 형성되는 행위적 관계에 해당한다.
4️⃣ 연관관계는 오퍼레이션에서 파라미터 등으로 이용할 수 있고, 의존관계는 소스코드에서 멤버변수로 선언하여 사용할 수 있다.
📌 개념
연관관계
- 항상 존재하는 관계
- 객체가 지속적으로 참조됨 -> 멤버 변수로 선언됨
- UML에서 실선으로 표현됨
의존관계 - 일시적으로 의존하는 관계
- 객체가 지속적으로 유지되지 않음 -> 메서드 내에서 일시적으로 사용
- UML에서 점선으로 표현됨
✅ 해설
1️⃣ ERD에서는 관계를 구분하지 않음 (UML에서는 나눔)
2️⃣ 맞음
3️⃣ 존재 관계 = 엔터티간의 상태 = 지속적으로 유지 => 연관관계
행위관계 = 엔터티의 행위 = 일시적으로 발생 => 의존관계
4️⃣ (정답) 연관관계 <- 멤버 변수, 상관관계 <- 파라미터 등이 맞음 (반대되는 설명)
21. 데이터 모델링의 관계에 대한 설명으로 가장 적절하지 않은 것은?
1️⃣ 관계는 존재적 관계와 행위에 의한 관계로 나누어볼 수 있다.
2️⃣ 관계의 표기법은 관계명, 관계차수, 식별성의 3가지 개념을 사용한다.
3️⃣ 부서와 사원 엔터티 간의 '소속' 관계는 존재적 관계의 사례이다.
4️⃣ 주문과 배송 엔터티 간의 '배송근거' 관계는 행위적 관계에 해당한다.
📌 개념
관계의 분류
- 존재적 관계 : 한 존재가 다른 존재 여부에 영향을 주는 관계
- 행위적 관계 : 특정한 행위에 의해 형성되는 관계 (행위가 없으면 관계가 형성되지 않을 수 있음)
✅ 해설
1️⃣ 관계의 분류 : 존재적 관계, 행위적 관계
2️⃣ (정답) 관계의 표기법에서는 관계명, 관계차수, 선택성 개념을 사용
3️⃣ 사원은 부서에 소속됨 = 부서가 없으면 사원도 없음 -> 존재적 관계
4️⃣ 주문이 배송을 결정 = 주문이라는 행위에 의해 배송이 발생 -> 행위적 관계
25. 두 개의 엔터티 사이에서 관계를 도출할 때 확인해야 할 사항을 모두 고른 것은?
(가) 두 개의 엔터티 사이에 관심 있는 연관규칙이 존재하는가?
(나) 두 개의 엔터티 사이에 정보의 조합이 발생되는가?
(다) 업무기술서, 장표에 관계연결에 대한 규칙이 서술되어 있는가?
(라) 업무기술서, 장표에 관계연결을 가능하게 하는 동사(Verb)가 있는가?1️⃣ (가), (나), (다)
2️⃣ (가), (나), (라)
3️⃣ (가), (다), (라)
4️⃣ (가), (나), (다), (라)
📌 개념
관계 도출 시 고려해야할 요소
- 두 엔터티 사이에 의미 있는 관계가 존재하는가
- 관계가 설정되었을 때 의미있는 정보 조합이 발생하는가
- 업무 상에서 명확한 관계 규칙이 존재하는가
- 관계의 연관성을 표현하는 동사로 표현해야 함
- 관계의 방향과 차수 (1:1, 1:N, N:M)를 결정해야 함
- 관계의 식별성, 선택성을 규정해야 함
✅ 해설
4️⃣ (정답) 모두 옳은 설명
27. 아래에서 사원 엔터티의 특성에 해당하지 않는 것은?
1️⃣ 주식별자
2️⃣ 단일식별자
3️⃣ 내부식별자
4️⃣ 인조식별자
📌 개념
식별자의 분류
- 대표성 여부에 따른 분류 : 주식별자(대표성 有) vs 보조 식별자(대표성 無) / 둘 모두 유일성, 최소성 만족
- 생성 여부에 따른 분류 : 내부 식별자(참조 없이 생성) vs 외부 식별자 (관계에 의해 생성)
- 속성 수에 따른 분류 : 단일 식별자(하나의 속성으로 구성) vs 복합 식별자 (2개 이상의 속성으로 구성)
- 대체 여부에 따른 분류 : 본질 식별자(업무 프로세스에서 차용) vs 인조 식별자(인위적으로 만듦)
✅ 해설
사원의 식별자는 사번
1️⃣ 사번은 대표성을 가짐
2️⃣ 사번 하나로 구성
3️⃣ 스스로 생성됨 (참조에 의해 생성되지 않음)
4️⃣ (정답) 사원은 업무 프로세스에 존재함, 따라서 인조 식별자가 아닌 본질 식별자에 해당함
30. 데이터 모델링에서 비식별자 관계로 연결하는 경우로 가장 적절하지 않은 것은?
1️⃣ 엔터티와 엔터티가 1:M 관계의 부모와 자식관계에서 데이터가 부모 없이 자식쪽 엔터티의 인스턴스가 먼저 생성될 수 있을 경우 비식별자 관계로 연결해야 한다.
2️⃣ 부모 엔터티의 인스턴스가 자식 엔터티의 인스턴스보다 먼저 소멸하는 경우 비식별자 관계로 연결해야 한다.
3️⃣ SQL 문의 조인 관계를 최소화하는 경우 비식별자 관계로 연결해야 한다.
4️⃣ 자식 엔터티의 식별자가 부모 엔터티의 주식별자를 상속받아 생성하는 것보다 별도의 주식별자를 생성하는 것이 더 유리하다고 판단되는 경우 비식별자 관계로 연결해야 한다.
📌 개념
식별관계 : 하나의 엔터티의 기본키를 다른 기본키로 공유하는 경우
비식별관계 : 강한 개체의 기본키를 다른 엔터티의 일반 속성으로 관계를 가짐
식별관계 vs 비식별관계
- 목적 : 강한 연결관계를 표현 vs 약한 연결관계를 표현
- 자식 주식별자 영향 : 자식 주식별자의 구성에 포함 vs 자식 일반 속성에 포함
- 표기법 : 실선 표현 vs 점선 표현
- 연결 고려사항
- 식별관계
- 반드시 부모 엔터티에 종속
- 자식 주식별자 구성에 부모 주식별자 포함 필요
- 상속받은 주식별자 속성을 타 엔터티에 이전 필요
- 비식별관계
- 약한 종속관계
- 자식 주식별자 구성을 독립적으로 구성
- 상속받은 주식별자 속성을 타 엔터티에 차단 필요
- 부모의 관계참여가 선택관계
✅ 해설
3️⃣ (정답) 조인 관계를 최소화하려면 식별관계로 연결해야 함
33. 아래 빈칸 ㄱ, ㄴ, ㄷ에 해당하는 것은?
업무분석을 통해 바로 정의한 속성을 ( ㄱ ), 원래 업무상 존재하지는 않지만 설계를 하면서 도출해 내는 속성을 ( ㄴ ), 다른 속성으로부터 계산이나 변형이 되어 생성되는 속성을 ( ㄷ )이라고 한다. 1️⃣ ( ㄱ ) : 기본 속성, ( ㄴ ) : 설계 속성, ( ㄷ ) : 파생 속성
2️⃣ ( ㄱ ) : 기본 속성, ( ㄴ ) : 일반 속성, ( ㄷ ) : 설계 속성
3️⃣ ( ㄱ ) : 일반 속성, ( ㄴ ) : 기본 속성, ( ㄷ ) : 파생 속성
4️⃣ ( ㄱ ) : 일반 속성, ( ㄴ ) : 설계 속성, ( ㄷ ) : 파생 속성
📌 개념
속성의 특성에 따른 분류
- 기본 속성 : 업무로 부터 추출된 모든 속성 (사실상 가장 많음)
- 설계 속성 : 업무를 규칙화할 때 새로 만들어지는 속성 (ex. 상품코드, 지점코드)
- 파생 속성 : 기본/설계 속성에서 파생되는 속성 (일반적으로 계산된 값, ex. 합계, 평균, 이자 ...)
cf.
엔터티 구성방식에 따른 분류 - PK(Primary Key, 기본키, 주식별자) : 인스턴스를 식별할 수 있는 속성
- FK(Foreign Key, 외래키) : 다른 엔터티와의 관계에서 포함된 속성
- 일반 속성 : 그 외
분해 여부에 따른 속성 - 단일 속성 : 하나의 의미로 구성 (ex. 회원ID, 이름)
- 복합 속성 : 여러개의 의미로 구성 (ex. 주소 - 시, 구, 동 등으로 분해 가능)
- 다중값 속성 : 여러개의 값을 가질 수 있음 (ex. 구매한 상품 <- 하나의 고객이 여러개를 가지겠지)
✅ 해설
1️⃣ (정답) ㄱ : 업무분석을 통해 바로 정의한 속성 <- 업무로부터 추출
ㄴ : 설계를 하면서 도출해 내는 속성 <- 설계 속성의 개념
ㄷ : 다른 속성(기본/설계 속성) 으로부터, 계산이나 변형이 되어 생성되는 속성 <- 파생 속성의 개념
