일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- 자바 공부
- react firebase
- 리액트
- design pattern
- 자바
- 프로그래밍 언어론
- 리액트 훅
- 프로그래머스 자바
- 프로그래머스 완전탐색
- 디자인 패턴
- 프로그래머스
- NextJS
- 백준
- 코딩테스트 고득점 Kit
- useState
- react
- JavaScript
- react hook
- 자바스크립트
- codesandbox
- Java
- 장고
- 컴퓨터 네트워크
- 코틀린
- 코딩테스트 고득점 Kit 완전탐색
- vanillaJS
- 데이터모델링과마이닝
- websocket
- React JS
- useEffect
- Today
- Total
목록4-1 (8)
기록하는 개발자
[ OLTP와 OLAP ] · OLTP(On-Line Transaction Processing) - 그때그때 할 수 있는 일상적인 업무 처리 측면 · OLAP(On-Line Analytical Processing) - 실시간 처리로 정확도보다는 대체적이고 빠르게 - 운영자가 추세적으로 알고 싶을 때 사용 - 그룹짓기(Group By), 집계(Aggregate 함수)등이 중심 [ Data Warehouse ] - 장기간에 걸쳐 여러 data source로부터 모은 data와 그 요약 정보 - 추출 → 양식변환 → 적재 → 리프레시 # warehousing issue - 원천들이 이질적이다. 다양한 포맷과 repository의 데이터를 받아야한다. - semantic integration(의미 측면 통합)이..
[ 이상(anomaly) ] · DML 연산 시 이상(anomaly)이 발생할 수 있다. · anomaly는 데이터의 종속성과 중복성에 의해 발생 한다. · 해결 : attribute 간의 종속 관계를 분석하여 여러 개의 relation으로 분해(decomposition) → 정규화 * 단, decomposition이 정규화는 아니다. * decomposition을 통해 문제가 해결되어야 정규화라고 할 수 있다. [ 중복성에 따른 여러 문제 ] · 중복성은 관계 스키마에서 발생하는 여러 문제의 근본적인 원인이다. · 무결성 제약 조건, 특히, 함수 종속성(Functional Dependency)를 분석하면 문제가 있는 스키마을 파악할 수 있다. · 주된 정제 기법 : 분해(decomposition) ex..
1) 논리 설계 개념 ·논리 설계 개념설계의 결과 검증, 승인 → 목표DBMS 결정 → 해당DBMS의 논리적 모델에 맞춰 스키마 변환 · 보통 Relational DBMS 사용 → Relational Data Model로 ER스키마 변환 2) Relational Data Model · 릴레이션 - 행의 수 : 카디널리티(cardinality) → 데이터 개수 - 열의 수 : 차수(degree) → 속성의 개수 - schema : 릴레이션 이름 + 각 필드의 이름과 타입 · 무결성 제약 조건((Integrity Constraints) - DB가 어떤 인스턴스가 되든 꼭 지켜져야 하는 조건 관계 모델의 두 가지 본질적 제약조건 (1) 기본키 제약조건 (2) 외래키 제약조건 3) 논리적 스키마 변환 ·SQL ..
· 개념 설계는 추상화 작업 - 현실 관찰로 개념 정리 → 홍길동이 컴퓨터 과학과에 다닌다 : value(실제 값) → ‘어느 학생이 어느 학과에 다니는가’의 정보가 필요하다. : schema *모델링 · value → 관찰, 생각, 의사결정, 검증, 공식화 → schema 설계 상의 선택들 1) 개체인가 애트리뷰트인가 Ex) 주소를 ‘직원’의 애트리뷰트로 할지, 독립된 개체로 만들어 관계를 통해 ‘직원’과 연결할 것인가? - 한 직원이 여러 주소가 가능한 경우에는 주소를 개체로 둔다. ex) 다수의 배송지 관리 - 주소의 구조(시,구,동)가 중요한 경우 '주소'를 개체로 둔다. 2) 개체인가 관계인가 - 관계라고 생각했던 정보가 개체인 경우 3) 이진 관계인가 삼진 관계인가 4) 집단화인가 삼진관계인가
# mapping cardinality 표기 없는 것은 n:m [ 3진 관계 ] 예시 : 직원별, 부서별로 사용 가능한 법인 카드가 다르다. [ 키 제약 조건 ] → 최대를 정의 [ 참여 제약 조건 ] → 최소를 정의 [ 약 개체 ] Weak Entity - 약 개체는 소유자 개체의 기본키까지 보아야 유일하게 식별할 수 있다. - 약 개체는 자신의 식별자를 가지고 있지 않고 다른 개체 인스턴스에 종속 되어야 만 존재할 수 있다. - 소유자 개체 집합과 약 개체 집합은 1대 다 관계 집합으로 연결된다. - 약 개체 집합은 이 식별 관계 집합에 전체적으로 참여(참여 제약 조건)한다. 식별 관계 집합(identifying relationship) 1) identifying owner..
· Entity(개체) - unique하게 식별되는 독립적 존재 - 그것 스스로 존재하는 정보로 다른 것과 구별됨 · Relationship(관계) - entity 간의 관계 → 논리 모델링의 릴레이션(table)도 관계라고 한다. 헷갈리지 않기. · Attribute(속성) * 현실 : 값, 인스턴스, 실체 * 모델링 : 개념, 타입, 스키마 [ 관계 타입의 유형 ] 사상 원소수(mapping cardinality) · 1 : 1 (one to one) · 1 : n (one to many) · n : m (many to many) - one to one에서 제약이 가장 많다. - mapping cardinality는 최대를 제시한다 → n:n의 경우, 이는 최대를 제시하므로 1:n, 1:1도 가능 [..
* 업무 중심 데이터 관리에서 정보 중심으로 인식 전환 · 데이터 모델은 SOC로 구성된다. - data Structure(data로 표현하는 구조 자체를 정의) - Operation(연산) - Constraints(제약 사항) * 모델이란 현실 세계의 추상화 된 반영 - 추상화, 단순화, 명확화(누가 봐도 동일하게 해석 해야함 ) · 데이터 모델링 접근 방법 (1) 데이터 중심 데이터 모델링 (2) 기능/업무/처리 중심 데이터 모델링 (3) (1)+(2)인 하이브리드 · database 의 생명주기 - 요구조건 분석 → 모델링(설계) → 구현 → 운영 → 감시 및 개선 - 무결성, 일관성(동일 요청에 동일 응답), ..
데이터(정보)의 위치 · 정보화시대의 핵심 자산 : 정보 - 소프트웨어는 대체가 가능하지만 data는 대체 불가능하다. · 정보 자산의 특징 - 비소모성, 정보성, 비이전성, 무한 가치성, 전유불가능성, 무한 재생산성, 누적 효과성 데이터 베이스 개요 · 정보 시스템 - 한 기관을 위해 데이터를 수집, 조작, 저장하고 정보를 생성, 분배하는 수단 · Database - 한 조직의 여러 응용 시스템이 공용하기 위해 통합, 저장한 운영 데이터의 집합 → 통합된 대규모의 데이터 집단으로 실세계의 조직체 모델링 · DBMS - DB를 저장하고 관리하는 소프트웨어 패키지 → data 중복과 의존성 해결 - 필수 기능 : 정의(DDL), 조작(DML), 제어(DCL) 기능 · 3-level D..