본문 바로가기

분류 전체보기

 (357)
[SQLD : Ⅰ. 데이터 모델링의 이해] 4-2. 식별자관계와 비식별자관계 * 식별자 관계와 비식별자 관계의 결정 - 외부식별자는 다른 엔티티와 관계를 통해 자식 쪽 엔티티에 생성되는 속성 - 관계와 속성을 정의하고 주식별자를 정의하면 논리적 관계에 의해 자연스럽게 외부식별자 도출됨 - 엔티티에 주식별자가 지정되고 엔티티간 관계를 연결하면 부모쪽 주식별자를 자식 엔티티의 속성으로 내보내려함 자식 엔티티에서 부모엔티티로부터 받은 외부식별자를 자신의 주식별자로 이용할지 결정해야 함 * 식별자 관계 - 부모로부터 받은 식별자를 자식 엔티티의 주식별자로 이용하면 NULL값이 있으면 안됨 - 부모로부터 받은 속성을 자식엔티티가 모두 사용하고 주식별자로 사용하면 1:1 관계 부모로부터 받은 + 다른 부모엔티티에서 받은 속성을 포함 OR 스스로 갖는 속성으로 주식별자 구성하면 1:M 관계 ..
[SQLD : Ⅰ. 데이터 모델링의 이해] 4-1. 식별자 * 식별자 - 하나의 엔티티에 구성되는 여러 개의 속성 중에 엔티티를 대표하는 속성 - 하나의 유일한 식별자가 존재 - 식별자는 논리 데이터 모델링 단계에서 사용하고 키는 물리 데이터 모델링 단계에서 사용 * 식별자 특징 - 유일성 : 주식별자에 의해 엔티티내에 모든 인스턴스들을 유일하게 구분 e.g. 사원번호가 모든 직원들에 대해 개인별로 고유하게 부여 - 최소성 : 주식별자를 구성하는 속성의 수는 유일성을 만족하는 최소의 수 e.g. 사원번호만으로도 고유한 구조, 사원분류코드 + 사원번호로 식별자가 구분되면 부적절한 주식별자 구조 - 불변성 : 주식별자가 한 번 특정 엔티티에 지정되면 그 식별자의 값은 변하지 않아야 함 e.g. 사원번호의 값이 변한다는 의미는 이전기록이 말소되고 새로운 기록이 발생된..
[SQLD : Ⅰ. 데이터 모델링의 이해] 3-2. 관계 표기, 관계 정의, 읽는 방법 [관계 표기] * 관계명 - 엔티티가 관계에 참여하는 형태, 각 관계는 두 개의 관계명을 가짐 - 엔티티에서 관계가 시작되는 편을 관계 시작점이라고 부르고 받는 편을 관계 끝점이라고 부름 - 관계 시작점과 끝점 모두 관계 이름을 가져야 함, 능동적이거나 수동적으로 명명 - 애매한 동사는 피함(e.g. 관계된다, 관련있다, 이다, 한다), 현재형으로 표현 * 관계차수 - 관계차수 : 두 엔티티간 관계에서 참여자의 수를 표현하는 것 - 1:1 one to one : 관계에 참여하는 각 엔티티는 관계를 맺는 다른 엔티티의 엔티티에 대해 단지 하나의 관계만 가짐 - 1:M one to many : 각 엔티티는 관계를 맺는 다른 엔티티의 엔티티에 대해 하나나 그 이상의 관계 - M:M many to many : ..
[SQLD : Ⅰ. 데이터 모델링의 이해] 3-1. 관계의 개념, 분류 * 관계의 정의 - 상호 연관성이 있는 상태 - 인스턴스 사이의 논리적인 연관성으로서, 존재 또는 행위로서, 서로에게 연관성이 부여된 상태 - 엔티티 간 연관성을 표현하기 때문에 엔티티 정의에 따라 영향을 받기도 함 - 속성 정의 및 관계 정의에 따라 다양하게 변할 수 있음 * 관계의 패어링 - 패어링 : 엔티티 안에 인스턴스가 개별적으로 관계를 가지는 것 - 개별 인스턴스가 각각 다른 종류의 관계를 갖고 있으면 두 엔티티 사이에 두 개 이상 관계가 형성될 수 있음 - 관계 패어링 : 각 엔티티의 인스턴스들이 자신이 관련된 인스턴스들과 관계의 어커런스로 참여하는 형태 - 최초의 ERD에서 관계는 속성을 가질 수 있었지만 요즘 ERD에서 관계를 위해 속성을 도출하지는 않음 - 관계의 표현에는 이항관계, 삼..
[SQLD : Ⅰ. 데이터 모델링의 이해] 2-3. 도메인, 속성 명명 * 도메인 - 각 속성이 가질 수 있는 값의 범위 - 엔티티 내에서 속성에 대한 데이터타입과 크기 그리고 제약사항을 지정하는 것 * 속성의 명명 - 속성 이름을 정확하게 부여하고 용어의 혼란을 없애기 위해 용어사전이라는 업무 사전을 프로젝트에 사용 - 각 속성이 갖는 값의 종류와 범위를 명확하게 하기 위해 도메인 정의를 미리 하여 용어 사전과 같이 사용 - 속성명 부여 원칙 해당 업무에서 사용하는 이름을 부여 서술식 속성명은 사용하지 않음 약어사용은 가급적 제한 전체 데이터모델에서 유일성 확보하는 것이 좋음
[SQLD : Ⅰ. 데이터 모델링의 이해] 2-2. 속성의 특징, 분류 * 속성의 특징 - 반드시 해당 업무에서 필요하고 관리하고자 하는 정보여야 한다 - 정규화 이론에 근간하여 정해진 주식별자에 함수적 종속을 가져야 한다 - 하나의 속성에는 한 개의 값만 갖는다. 다중값일 경우 별도의 엔티티를 이용하여 분리한다. * 속성의 특성에 따른 분류 - 기본속성basic attirbute : 업무분석을 통해 바로 정의한 속성 업무 분석을 통한 속성이어도 이미 업무상 코드로 정의한 속성이 많음 -> 기본 속성 아님 - 설계속성designed attribute : 업무상 존재하지는 않지만 설계하면서 도출해내는 속성 데이터 모델링을 위해, 업무를 규칙화하기 위해 속성을 만들거나 변형하여 정의 코드성 속성은 변형하여 만든 설계 속성, 일련번호 같은 속성은 단일한 식별자 부여를 위해 정의하..
[SQLD : Ⅰ. 데이터 모델링의 이해] 2-1. 속성 개념, 표기법 * 속성의 개념 - 사물이나 개념이 어떤 것인지를 나타내고 그것을 다른 것과 구별하는 성질 - 데이터 모델링 관점 : 업무상 필요로 하는 인스턴스, 관리하고자하는 의미 상 더 이상 분리되지 않는 최소 데이터 단위 -> 속성의 정의 : 업무에서 필요로 함, 의미상 더 이상 분리되지 않음, 엔티티를 설명함, 인스턴스의 구성요소 e.g. 생년월일을 생년, 생월, 생일로 구분, FP 산정 시 분리된 속성은 하나의 속성으로 계산 이름이나 주소를 "이름주소"로 정의하면 기본 속성으로 성립하지 않음 - > 내역 description * 엔티티, 인스턴스, 속성, 속성 값의 관계 - 엔티티에는 두 개 이상의 인스턴스가 존재 - 각 엔티티에는 고유 성격을 표현하는 속성정보를 두 개 이상 가짐 - 분석 단계 : 엔티티 내..
[SQLD : Ⅰ. 데이터 모델링의 이해] 1-5. 엔티티의 명명 * 가능하면 현업업무에서 사용하는 용어 사용 * 가능하면 약어를 사용하지 않음 * 단수명사 사용 * 모든 엔티티에서 유일하게 이름 부여 * 엔티티 생성의미대로 이름 부여 (중심 엔티티에서 적절하지 못한 엔티티 사용 많이 발생 행위 엔티티에서도 많은 경우 부적절한 엔티티명 사용) e.g. "고객 제품" : 고객이 주문한 제품 or 고객의 제품인지 의미가 애매모호 -> 업무 목적에 따라 생성되는 자연스러운 이름 부여 임의로 이름을 부여하면 프로젝트 커뮤니케이션 오류로 문제 발생 가능

티스토리툴바