반응형
Data Modeling
큰그림이 있고 세부적인것을 파고 들어가야..
코끼리면 전체를 보고 세부사항을 접근해야하는데 보통은 세부적인 것만 아는 사람들이 모여서 자신이 아는 것만 주장.
삼각형 법 - 세분화 해서 나누어야 한다.
WBS- 일정표 어느 일정에 어떤 것을 이용할 것인가.
사업수행 계획표 - 어떻게 진행할 것인지.
이 두가지를 잘 이해하고 진행하는 것이 중요.
고객이라는 엔티티가 있으면 이 녀석은 개인, 기업 고객이 있다.
SubType으로 적으면 더 자세히 알 수 있다.
릴레이션을 그을 때 단순히 선을 긋는 것이 아닌 자세히 적어야 한다.
논리 모델은 최대한 자세히 적어여 한다.
단순히 컬럼 정의 하는 것이 아니다.
1.형제형
2.족보형
3.네트워크 형
수평적 사고?
리버스 엔진을 가지고 역 리버스 해서 가지고 가는데 탑 다운으로 가게 되면 엔티티 후보를 도출해야함.
엔티티 도출 시는 릴레이션을 고려치 안고 엔티티를 도출 한 후 추후 릴레이션 정의.
미술 시간에 스케치 먼저하고 서서히 자세히 모델을 만드는 것이다.
일반적으로
고객 - 조직 - 상품
- 계약
을 핵심으로 해서 모델이 발전한다.
점선 : 있어도 되고 없어도 된다.
실선 : 반드시 있어야 한다.
Function Modeling :프로세스만 쫒아가면 되므로 쉽게 가능하나 수정이 빈번하다.
Data Modeling
데이터 모델은 테이블 구조가 아니다.
한 모델에서 여러 테이블이 나올수 있는 것이다.
납부자 -> 이 녀석은 엔티티가 아니다.
왜냐? 고객 -> 납부 -> 청구 이렇게 하면 릴레이션으로 표현이 가능하기 때문.
납부 : 행위 자 : 개체
납부와 아래에 우체국, 보험회사 있으면 수납기관은 엔티티로 표현이 가능하다.
Key Entity - 엔티티 태생의 시초가 되는 엔티티
Main Entity - key에서 파생 , 중간 행위 단계
Action Entity - 행위나 트랜젝션에 의해 생기는 엔티티
고객 m m 조직 m m 상품
mm 관계는 관계가 없는 것과 같지만 여기서 서서히 풀어나가서 1:m 으로 만드는게 모델링의 과정.
테이블이 많으면 운영이 힘들다.
그러므로 가능한 유사한 것과 통합.
하지만 너무 많은 통합은 의미가 희석되어진다.
통합하지 않으면 의미는 분명해 지지만 통합 할 수록 융통성은 증가한다.
배타적 OR
예전엔 file 시스템으로서 화면 당 테이블이 나왔지만 RDB로 오면서 Table의 많은 통합이 이루어짐.
하나의 계약이 여러건?
Entity를 선정후 의미상의 주어인 PK를 찾아야 엔티티에 대한 정의가 분석됨.
보험회사의 경우 보험 설계사 수당을 주는 경우가 있다.
홍길동이 A에서 1억의 실적을 내고 B로 바뀌는 경우.
사원을 따라 가면 사원 실적 1억은 그대로 홍길동이 가지게 되나
A부서의 실적으로 남는다면 주체는 부서가 된다.
ExOR 여러 릴레이션 중에 하나가 들어오면 나머지는 들어오면 안되는 관계
주체가 어디이냐? 의미상의 주어가 무엇이냐에 따른 ExOR관계의 성립으로 의미상의 주어를 찾는것이 가장 중요하고 이것으로 Entity 정의서가 도출된다.
정규화
학생이라 하더라도
강좌에 참석한 사람을 학생으로 보면 구성원 - 강좌 이므로 릴레이션으로 뽑아 낼 수 있다.
(구성원에 학생,교사 이렇게 있으면 추후 교사의 경우로 릴레이션만 그으면 표현 가능)
하지만 신분이 원래 학생인 사람이라면 이것은 엔티티 이다.
Dimension : 차원 구분코드
measure : 구분값
Matrix를 이용한 ERD 작성
Matrix에서 관계를 도출하여 Erd를 작성할 수 있다.
1:m 관계를 도출하려면 구체적인 질문, 유도심문, 등의 질문으로 해야 현업이 예기를 제대로 해 준다.
그냥 고객이 뭐에요? 이런식으로 질문하면 답이 제대로 안나온다.
직렬식 관리. 컬럼이 늘어나는 방법에서
병렬식으로 로우로 늘어지게..
메타모델.
사원이라는 엔티티에서 컬럼은 전화번호 사번 등의 컬럼이 있는데 이걸 자식으로 빼서 연락처 1,2,3으로 빼서 로우로 늘어나게 하는 방식.
Data 압축 컨퍼런스 옵션을 줌으로 압축가능한데 단점이 있다.
압축하면 cpu 자원을 많이 쓰는 단점이 있다. 새벽1시에 압축하게 끔했다.
블럭단위로 압축이 된다. 연속된 값을 압축 하고 나머지는 정보만 가지는데 연속이 되게끔 하기 위해서 sort 하면 압축률이 좋아 짐.
Oracle은 select시는 압축을 풀필요가 없으므로 속도는 그대로 빠른다.
또 적은 블럭을 읽으므로 빨라지는 것임.
반도체 수유율은 저녁에 사람 없을때 Sort 해서 Data 넣도록 했다.
1.원자단위냐?
2. Single Value냐?
3. 추출값이냐?
4. 보다 상세한 관리를 하겠느냐?
YYMM 이렇게 붙여야 할 것을 YY , MM으로 분리해서 쿼리를 어렵게 만들 필요는 없다.
주민번호를 앞과 뒤를 자르는게 좋냐 아니냐의 기준은?
각각이 잘라져서 단일 값으로 이용될 경우는 잘라야 하지만 아니면 붙이는게 맞다.
원자를 어떻게 보느냐에 따라 그때 그때 달라요.
Between Relation
Between으로도 조회된다.
예를 들어 이력 조회시 근무이력으로 조회하는 경우
선분이력
사원번호가 1111인 경우 200701~200706까지 근무
7월 부터는 영업에서 제조로 부서이동
시작과 끝을 가진 이력을 선분이력이라고 함.
부서일자 = between 근무시작 and 근무종료
이통사 달 중간에 요금제 바꿔도 선분이력을 관리하면 쉽게 결과 값을 가져올 수 있다.
수량 * 단가 = 금액 이면 금액을 속성으로 가져갈 필요는 없다.
곱하기 블럭 더 가진 것이므로 속도와는 전혀 무관하다.
PK의 상속
할아버지 PK는 아버지도 가지고 있어야 한다. 아들은 할아버지 아버지의 PK를 모두 가지고 있어야 한다.
계층구조의 배타적 관계 상속 예
아버지 아들 술집을 방문 아버지도 아들도 술집을 갈 수는 있지만 아버지가 갈때 아들은 가지 않고 아들이 갈때 아버지는 가지 않는 관계
type이라는 구분자를 두지 않고 값 자체에서 0으로 구분.
0이면 아버지 0이 아니면 아들로.
하지만 보통 구분자를 두는게 헷갈리지 않는다.
정규화를 하는 이유는?
중복된 값이 퍼져 있지 않도록 하기 위함.
중복이 많아지면 일관성이 깨질 수 있으므로.
랄프 박사가 만듬.
1정규화
> 중복값 제거
> key 값에 Data가 두개 이상인 경우
> 두개 있는 값을 뽑아서 자식으로 나와야 함.
> 고객번호가 key 고객 이름도 key 인 경우 번호에 이름은 종속인데 key 끼리 종속이므로 1
정규화 위반.
2정규화
> 키값의 일부가 다른 값에 종속 되면 안된다.
> key a는 c만 종속이다.(key a,b , 일반 c,d)
> 고객번호가 key 인 경우 속성이 종속인 경우 종속을 풀어야 함
3정규화
>속성 끼리 종속 관계가 있으면 안된다.
>(key a, 일반 c,d,e)
>주문내역 테이블에서 일반엔티티인 고객번호는 고객에 테이블
>고객번호가 일반 속석이고 다른 고객 전화번호가 일반 속성이면 고객 번호와 고객 전화번호는 종속이므로 따로 뺀다.
M:M의 관계는 1:M의 관계로 풀어서 관계를 맺어 주도록 하자.
ExOR관계는 통합하여 1:M의 관계로 통합해야 관계 맺기가 편하다.
BOM 구조
점이력 : 이벤트 발생시 마다 이력 관리 -> 위치 분석이 어렵다.
선분이력
큰그림이 있고 세부적인것을 파고 들어가야..
코끼리면 전체를 보고 세부사항을 접근해야하는데 보통은 세부적인 것만 아는 사람들이 모여서 자신이 아는 것만 주장.
삼각형 법 - 세분화 해서 나누어야 한다.
WBS- 일정표 어느 일정에 어떤 것을 이용할 것인가.
사업수행 계획표 - 어떻게 진행할 것인지.
이 두가지를 잘 이해하고 진행하는 것이 중요.
고객이라는 엔티티가 있으면 이 녀석은 개인, 기업 고객이 있다.
SubType으로 적으면 더 자세히 알 수 있다.
릴레이션을 그을 때 단순히 선을 긋는 것이 아닌 자세히 적어야 한다.
논리 모델은 최대한 자세히 적어여 한다.
단순히 컬럼 정의 하는 것이 아니다.
1.형제형
2.족보형
3.네트워크 형
수평적 사고?
리버스 엔진을 가지고 역 리버스 해서 가지고 가는데 탑 다운으로 가게 되면 엔티티 후보를 도출해야함.
엔티티 도출 시는 릴레이션을 고려치 안고 엔티티를 도출 한 후 추후 릴레이션 정의.
미술 시간에 스케치 먼저하고 서서히 자세히 모델을 만드는 것이다.
일반적으로
고객 - 조직 - 상품
- 계약
을 핵심으로 해서 모델이 발전한다.
점선 : 있어도 되고 없어도 된다.
실선 : 반드시 있어야 한다.
Function Modeling :프로세스만 쫒아가면 되므로 쉽게 가능하나 수정이 빈번하다.
Data Modeling
데이터 모델은 테이블 구조가 아니다.
한 모델에서 여러 테이블이 나올수 있는 것이다.
납부자 -> 이 녀석은 엔티티가 아니다.
왜냐? 고객 -> 납부 -> 청구 이렇게 하면 릴레이션으로 표현이 가능하기 때문.
납부 : 행위 자 : 개체
납부와 아래에 우체국, 보험회사 있으면 수납기관은 엔티티로 표현이 가능하다.
Key Entity - 엔티티 태생의 시초가 되는 엔티티
Main Entity - key에서 파생 , 중간 행위 단계
Action Entity - 행위나 트랜젝션에 의해 생기는 엔티티
고객 m m 조직 m m 상품
mm 관계는 관계가 없는 것과 같지만 여기서 서서히 풀어나가서 1:m 으로 만드는게 모델링의 과정.
테이블이 많으면 운영이 힘들다.
그러므로 가능한 유사한 것과 통합.
하지만 너무 많은 통합은 의미가 희석되어진다.
통합하지 않으면 의미는 분명해 지지만 통합 할 수록 융통성은 증가한다.
배타적 OR
예전엔 file 시스템으로서 화면 당 테이블이 나왔지만 RDB로 오면서 Table의 많은 통합이 이루어짐.
하나의 계약이 여러건?
Entity를 선정후 의미상의 주어인 PK를 찾아야 엔티티에 대한 정의가 분석됨.
보험회사의 경우 보험 설계사 수당을 주는 경우가 있다.
홍길동이 A에서 1억의 실적을 내고 B로 바뀌는 경우.
사원을 따라 가면 사원 실적 1억은 그대로 홍길동이 가지게 되나
A부서의 실적으로 남는다면 주체는 부서가 된다.
ExOR 여러 릴레이션 중에 하나가 들어오면 나머지는 들어오면 안되는 관계
주체가 어디이냐? 의미상의 주어가 무엇이냐에 따른 ExOR관계의 성립으로 의미상의 주어를 찾는것이 가장 중요하고 이것으로 Entity 정의서가 도출된다.
정규화
학생이라 하더라도
강좌에 참석한 사람을 학생으로 보면 구성원 - 강좌 이므로 릴레이션으로 뽑아 낼 수 있다.
(구성원에 학생,교사 이렇게 있으면 추후 교사의 경우로 릴레이션만 그으면 표현 가능)
하지만 신분이 원래 학생인 사람이라면 이것은 엔티티 이다.
Dimension : 차원 구분코드
measure : 구분값
Matrix를 이용한 ERD 작성
Matrix에서 관계를 도출하여 Erd를 작성할 수 있다.
1:m 관계를 도출하려면 구체적인 질문, 유도심문, 등의 질문으로 해야 현업이 예기를 제대로 해 준다.
그냥 고객이 뭐에요? 이런식으로 질문하면 답이 제대로 안나온다.
직렬식 관리. 컬럼이 늘어나는 방법에서
병렬식으로 로우로 늘어지게..
메타모델.
사원이라는 엔티티에서 컬럼은 전화번호 사번 등의 컬럼이 있는데 이걸 자식으로 빼서 연락처 1,2,3으로 빼서 로우로 늘어나게 하는 방식.
Data 압축 컨퍼런스 옵션을 줌으로 압축가능한데 단점이 있다.
압축하면 cpu 자원을 많이 쓰는 단점이 있다. 새벽1시에 압축하게 끔했다.
블럭단위로 압축이 된다. 연속된 값을 압축 하고 나머지는 정보만 가지는데 연속이 되게끔 하기 위해서 sort 하면 압축률이 좋아 짐.
Oracle은 select시는 압축을 풀필요가 없으므로 속도는 그대로 빠른다.
또 적은 블럭을 읽으므로 빨라지는 것임.
반도체 수유율은 저녁에 사람 없을때 Sort 해서 Data 넣도록 했다.
1.원자단위냐?
2. Single Value냐?
3. 추출값이냐?
4. 보다 상세한 관리를 하겠느냐?
YYMM 이렇게 붙여야 할 것을 YY , MM으로 분리해서 쿼리를 어렵게 만들 필요는 없다.
주민번호를 앞과 뒤를 자르는게 좋냐 아니냐의 기준은?
각각이 잘라져서 단일 값으로 이용될 경우는 잘라야 하지만 아니면 붙이는게 맞다.
원자를 어떻게 보느냐에 따라 그때 그때 달라요.
Between Relation
Between으로도 조회된다.
예를 들어 이력 조회시 근무이력으로 조회하는 경우
선분이력
사원번호가 1111인 경우 200701~200706까지 근무
7월 부터는 영업에서 제조로 부서이동
시작과 끝을 가진 이력을 선분이력이라고 함.
부서일자 = between 근무시작 and 근무종료
이통사 달 중간에 요금제 바꿔도 선분이력을 관리하면 쉽게 결과 값을 가져올 수 있다.
수량 * 단가 = 금액 이면 금액을 속성으로 가져갈 필요는 없다.
곱하기 블럭 더 가진 것이므로 속도와는 전혀 무관하다.
PK의 상속
할아버지 PK는 아버지도 가지고 있어야 한다. 아들은 할아버지 아버지의 PK를 모두 가지고 있어야 한다.
계층구조의 배타적 관계 상속 예
아버지 아들 술집을 방문 아버지도 아들도 술집을 갈 수는 있지만 아버지가 갈때 아들은 가지 않고 아들이 갈때 아버지는 가지 않는 관계
type이라는 구분자를 두지 않고 값 자체에서 0으로 구분.
0이면 아버지 0이 아니면 아들로.
하지만 보통 구분자를 두는게 헷갈리지 않는다.
정규화를 하는 이유는?
중복된 값이 퍼져 있지 않도록 하기 위함.
중복이 많아지면 일관성이 깨질 수 있으므로.
랄프 박사가 만듬.
1정규화
> 중복값 제거
> key 값에 Data가 두개 이상인 경우
> 두개 있는 값을 뽑아서 자식으로 나와야 함.
> 고객번호가 key 고객 이름도 key 인 경우 번호에 이름은 종속인데 key 끼리 종속이므로 1
정규화 위반.
2정규화
> 키값의 일부가 다른 값에 종속 되면 안된다.
> key a는 c만 종속이다.(key a,b , 일반 c,d)
> 고객번호가 key 인 경우 속성이 종속인 경우 종속을 풀어야 함
3정규화
>속성 끼리 종속 관계가 있으면 안된다.
>(key a, 일반 c,d,e)
>주문내역 테이블에서 일반엔티티인 고객번호는 고객에 테이블
>고객번호가 일반 속석이고 다른 고객 전화번호가 일반 속성이면 고객 번호와 고객 전화번호는 종속이므로 따로 뺀다.
M:M의 관계는 1:M의 관계로 풀어서 관계를 맺어 주도록 하자.
ExOR관계는 통합하여 1:M의 관계로 통합해야 관계 맺기가 편하다.
BOM 구조
점이력 : 이벤트 발생시 마다 이력 관리 -> 위치 분석이 어렵다.
선분이력
반응형