가자미의 개발이야기

parser and translator 작성된 쿼리에 문제가 없는지 검사하고 파싱 relational-algebra expression 파싱된 쿼리를 관계대수 표현으로 변환 #이때 쿼리는 진행순서가 있지만 관계대수는 진행순서를 고려한다. #이런 차이 때문에 변환과정에서 다르지만 같은 결과가 나오는 여러 관계대수로 변환될 수 있다. #이렇게 드러난 여러 관계대수 중 cost가 가장 적게 드는 플랜을 선택해 실행한다. 데이터베이스의 비용. 응답시간을 cost로 하면 이상적이지만, 쿼리말고 다양한 요인에 의해 달라질 수 있으므로 측정이 힘들다. cpu cost는 데이터베이스에는 많은 영향을 주지 않는 편이다. (병렬쿼리는 제외) disk access가 데이터베이스에 많은 영향을 미친다. disk cost를 하..

정규화 데이터의 중복 제거, 데이터 무결성을 지키기 위해. 무결성 -엔티티 무결성 : 기본키는 튜플들을 식별할 수 있게 해야하고(unique), null이 되어서는 안된다. -참조 무결성 : 참조한 게 실제로 있어야 한다. (참조 값이 null이 가능해야 한다.) 참조 무결성은 두 가지 중 하나를 준수하면 만족한다. (1) 외래 키의 값은 참조 릴레이션의 어떤 투플의 기본 값과 같다. (2) 외래 키가 자신을 포함하고 있는 릴레이션의 기본 키를 구성하고 있지 않으면 널값을 가진다. -도매인 무결성 : 특정 속성의 값이 그 속성이 정의된 도메인에 속한 값이어야 한다 decomposition(분해) 큰 테이블을 두개로 쪼개는 것 하지만 lossy decomposition을 주의해야 한다.(나눈 걸 다시 합쳤..

1. many to one(혹은 one to many)일 때 many side에 중복 속성(one side에도 있는 속성)이 있을 경우 잘못된 설계이다. 2. multivalued 속성의 가능성을 고려하지 않은 경우 다음과 같은 관계에서 만약 한 학생이 과제가 여러개를 가지고 있으면 어떻게 저장 가능하겠는가?(당연히 오류다) 다음과 같이 고쳐서 사용해야 한다. 3. 엔티티냐 속성이냐 3-1 엔티티 집합을 만들까 vs 기존의 엔티티 세트에 속성을 추가할까 3-2 관계집합을 별도의 엔티티 집합으로 만들까? 해당 관계가 many to many면 만들자. 관계에 속성이 많이 필요하면 엔티티 집합을 고려한다.(관계 집합에 속성 추가하는 방식도 괜찮다.) 양 쪽과 total 연결이 되어야 한다.(이 연결은 many..

전문화 엔티티 집합을 잘 이해하기 위해 하위 계층으로 상속하여 구체화. 즉 Top-Down design. 하위 계층의 엔티티 집합은 자신이 상속받은 엔티티 집합의 속성을 모두 상속받음 disjoint 전문화를 하나의 엔티티 세트로 함. (instructor와 secretary. 한 entity가 여러 entity집합에 속할 수 없다. 교수이면서 비서인 경우는 없다는 의미) overlapping 전문화를 여러개의 엔티티 세트로 함 (employee, student. 한 entity가 여러 entity집합에 속할 수 있다. 학생이면서 직원일 수 있다.) 스키마로 전문화를 표현 1번째 방법 : 최상위 계층은 모든 속성 표현하고, 하위는 꼭 필요한 것(최상위의 기본키, 자신의 로컬키)만 표현하기 1번째 방법은 ..

entity set, relation set => relation schema로 표현 가능 강한 entity set => 그냥 있는 그대로 스키마 생성 약한 entity set => 식별해주는 entity(identity entity)도 포함해서 기본키로 스키마 생성 composite attribute(복합 속성, 계층적)은 가장 하위 항목들만 저장 derived attribute(추론 가능한 속성, 나이와 생년월일)은 둘 중 하나만 저장 multi valued attribute(여러개의 값을 가질 수 있는 속성. 핸드폰 번호(여러개를 가진 사람 존재할 경우))은 새로운 스키마 생성. ID,phone_number로 스키마 생성하고 각 아이디가 가진 번호를 하나씩 모두 나열 이럴 경우 name은 first..

ER 모델 엔티티 : 속성의 집합 (홍길동(사람 속성의 집합), 개똥이(강아지 속성의 집합) ) 엔티티 집합 : 엔티티의 집합 (사람, 강아지) 관계 : 엔티티 간의 연관 (홍길동 -(반려관계)-개똥이) 관계 집합 : 관계의 집합.((홍길동,개똥이), (김철수, 멍돌이)....) 엔티티 집합에서의 기본키 정의 상 각 엔티티는 정의 상 유일하다. 이 엔티티들을 구분하는 속성을 기본키라 부름. 하나의 속성으로 구분하기 힘들 경우, 여러개의 속성이 기본키가 되기도 함. 관계 집합에서의 기본키 관계에 연관되는 엔티티 집합의 기본키 이름이 같다면, 그 엔티티 집합의 이름을 앞에 붙여서 표현 (홍길동.식별번호) 즉 관계를 나타낼 때 엔티티 집합의 기본키만으로도 파악이 가능하다. Binary relationship에..

1. 데이터베이스 모델링 과정 ㄱ. 요구사항 수집 및 분석 ㄴ. 개념적 모델링 ㄷ. 논리적 모델링 ㄹ. 물리적 모델링 ㅁ. 데이터베이스 구현 요구사항 수집 및 분석 - 현실 세계를 파악하고 수용자의 요구사항을 수집 및 분석. 개념적 모델링 - 업무의 핵심적인 개념을 구분하고 전체적인 뼈대를 만듬 - 개체(엔티티)를 추출하고 각 개체들 간의 관계를 정의하는 과정. - ER 다이어그램을 활용. 논리적 모델링 - ER 다이어그램을 DBMS에 맞게 사상(매핑)하여 구현 가능한 모델을 만드는 과정. - 개념적 모델링과는 달리, 상세 속성들을 모두 추출 - 중복 저장을 막는 정규화와 표준화를 수행 물리적 모델링 - 실제 컴퓨터의 저장 장치에 저장하기 위한 물리적 구조를 정의하고 구현하는 과정.

인덱스는 클러스터 인덱스와 보조 인덱스로 나뉨. 모두 B-tree 인덱스를 기반으로 함. 1. 클러스터 인덱스 -연속된 키 값의 레코드를 묶어서 같은 블록에 저장. -테이블 당 하나만 생성. -리프 노드들이 정렬된 테이블 자체. -기본키 생성 시 자동 생성. 2. 보조 인덱스 -리프 노드에 실제 데이터값이 아닌 위치를 저장. -정렬되지 않은 무작위여도 찾을 수 있음(검색 속도가 느릴 수 있음) 3. 인덱스 생성 인덱스는 WHERE 절에 자주 사용되는 속성이어야 한다 조인에 자주 사용되는 속성이어야 한다. 단일 테이블에 인덱스가 많으면 속도가 느려진다.(테이블 당 4~5) 속성이 가공되는 경우 사용하지 않는다. 속성의 선택도가 낮을 때 유리하다. *선택도 = 1/서로 다른 값의 개수 CREATE [UNIQ..

-뷰 : 질의의 결과 만들어지는 가상의 테이블로 실제 테이블처럼 사용 *실제 데이터를 디스크에 저장되는게 아니라 DBMS가 SELECT문의 정의를 저장함 *INSERT, UPDATE, DELETE 같은 DML 작업은 뷰에서 수행하지 않는다. 1. 뷰 생성 CREATE VIEW 뷰이름 [(열이름....)] AS SELECT 문... ================================ 열이름은 뷰에서 사용할 열의 이름. 열이름과 SELECT에서 추출하는 속성은 일대일 대응 CREATE VIEW vw_Orders (orderid, custid, name, bookid, bookname, saleprice, orderdate) AS SELECT od.orderid, od.custid, cs.name, o..

부속질의 : 하나의 SQL 문 안에 다른 SQL 문이 중첩된 질의 1. 스칼라 부속질의 - SELECT 부속질의 -SELECT 절에서 이뤄지고, 단일 값을 반환 SELECT custid, (SELECT name FROM Customer cs WHERE cs.custid=od.custid) 'name', SUM(saleprice) 'total' FROM orders od GROUP BY custid; *name 속성은 부속질의로 구현 ALTER TABLE Orders ADD bname VARCHAR(40); UPDATE Orders SET bname=(SELECT bookname FROM Book where Book.bookid=Orders.bookid); SELECT * FROM Orders; *bnam..