오래 못 할 짓 하지 않기

이런 테이블이 있다고 생각해보자. - dept_name 마다 할당받은 building이 있다. - dept_name 마다 정해진 budget이 있다. 위 테이블을 보면 dept_name - building - budget을 하나의 세트로 본다면 중복되는 데이터들이 너무 많다. 만약 저 중복되어있는 데이터들을 Delete , Update 하려고 하거나 새로운 Data를 넣으려고 할 때 수고로움과 누락될 수 있는 것들을 생각하면 바람직한 구조는 아닌 것 같다. 이러한 정보의 반복을 피하는 방법 : 정규화 각각의 Relation 끼리 연관된 Data들끼리 쪼개자 목적 : 중복을 피하기

Entity - Relationship Model : Entity들 사이의 관계를 나타내는 모식도라고 생각하면 된다. Entity들끼리 Mapping 되는 Cardinalitie는 위와 같다. ERD에서 볼 때, - 방향 O 선 = One - 방향 X 선 = Many ERD에서의 Primary Key Relationship set " Advisior "의 Primary key 는 그걸 이루고 있는 두 개의 Entity의 primary key로 구성된다. ● One to One : 참여하고 있는 Entity sets 중에 아무 primary key를 가져오면 된다 ● One to Many : Many쪽의 primary key를 가져오면 된다 ● Many to One : Many쪽의 primary key를 ..

With : 임시적으로 만드는 Relation table 여기에서 VNDR_CODE가 1001이나 1002인것들만 추출한다고 해보자 위 테이블을 보면 2개의 Select 덩어리가 있다. 두 개의 덩어리는 다 같은 내용에다가 마지막 where절 부분만 다르다. Select + From + Join 만 같고 Where만 다르다면, Where 전 부분을 한 덩어리로 치환할 수 있지 않을까? 라는 생각에서 시작한다. 이렇게 완성 가능하다. 그냥 긴 구문을 하나의 변수에 담아둔다고 생각하면 편하다. 그걸 Table로 사용할 수 있기 때문에 From에 넣어도 된다. IN / NOT IN 다음과 같이 2017 2학기, 2018 1학기에 열린 수업을 조회한다고 했을 때 Outer 쿼리에는 2017 2학기 수업들을 골라..

SELECT { Attribute } FROM { Table } Where { Condition } 쿼리의 구조는 다음과 같다. Select나 가장 처음에 오는 부분에는 Attribute나 세부적인 데이터가 들어간다. FROM 뒤에는 사용/참조할 Table을 적고 Where 뒤에는 조건을 적는다. 이에 실행 순서들을 보면 From → Where → SELECT순서로 실행시킨다. From 에 있는 Table에서 ▶ Where Condition에 맞는 Tuple의 ▶ Attribute를 Select 해서 보여준다. Select 특) ● 정렬 안 함 ( Order by로 가능 ) ● 중복허용 ( DISTINCT 로 중복 제거 가능 ) 출력될 때 내가 원하는 Column 이름으로 바꿀 수 있음 Where a> ..

Network Data Model은 이렇게 만들 수 있다. DB 사용 초기에는 이런 방식으로 했는데, 화살표는 포인터로 구현되었다. 하지만 이렇게 하기에는 무엇보다 포인터가 너무 많아져서 사용하면서 꼬이는 게 많았다. 데이터 Entity의 계층구조를 이용하여 Pointer 개수를 줄여 사용한다. Schema와 그 안에 들어가는 Attribute들을 나타낸다. Relatioanl Data Model에서는 위와 같이 나타낸다. Table간의 관계를 먼저 나타내고, 아래에서 Attribute들의 관계를 나타낸다. 이 단계에서부터는 화살표가 pointer를 의미하지 않는다. Object - Oriented Data Model 자바에서 했던 거 생각하면 된다. Entity class를 만들어서 그와 관련된 Att..

DBMS : DataBase Management System ● 목적 - 데이터 정의 및 생성 - 쿼리 날리기 - 정보 업데이트 및 관리 ● Software는 Application이 DB에 정보를 저장하고 분석할 수 있게 도와준다. ( File I/O 단계의 세부적인 건 고려하지 않고 접근 가능 ) 2가지 Interface가 있다. - DDL : Data Definition Language - DML : Data Manipulation Language ▶ SQL : Structured query language 는 DDL과 DML에서 다 쓰인다. Data Model : 정보에 대한 설명을 담고있는 객체(?) 주로 DBMS들이라서 우리는 이 과목에서 이걸 배움 ● 구성요소 3가지 - Structure - ..

특정 컬럼에 대한 데이터를 찾으려고 할 때 ● [ 해당 컬럼에 Index가 걸려있지 않다면 ] 테이블에 있는 모든 정보를 돌아보며 찾아야 한다. 이렇게 테이블을 전체 도는 것을 full scan이라고 한다. = O ( N ) ● [ 해당 컬럼에 Index가 걸려있다면 ] B-tree index 로 되어있다면 = O ( log N ) = Index를 쓰는 이유 1) 조건을 만족하는 튜플을 빠르게 조회하기 위해 2) 빠르게 정렬 / 그룹핑 하기 위해 3) Join 조건도 빠르게 찾기 위해 ▶ CREATE INDEX player_name_idx On player (name); 로 play에 대한 index를 걸어준다. 형태 : CREATE Index ( idx 를 카운트하려는 변수명 ) On ( 원하는 테이블..

저번 시간... 2NF를 만족시키기 위해 모든 Non-prime attribute가 모든 Key에 대해 Fully functionally dependent 하도록 만들었다. 3NF 이제 card_id 에 대해서는 정규화를 했다. - card_id의 문제점은 한 튜플에서 한 Attribute에 두 개의 값이 들어갔다는 것이다. > 이번에는 empl_name을 보자. 중복되는 이름이 많다. 현재 테이블에 관한 Functional Dependency를 보면 아래와 같다. 이 때, empl_name은 empl_id에 따라 값이 바뀌는 걸 알 수 있다. 즉, empl_id가 empl_name을 unique하게 결정한다. = {empl_id} → {empl_name} 또한 empl_id는 account_id에 따라..

DB 정규화 : [ 데이터 중복 ] + [ Insertion , Update , Deletion anomaly ] 를 최소화하기 위해 일련의 Normal Form(NF)에 따라 Releational DB를 구성하는 과정 * Normal form 정규화 되기 위해 준수해야하는 규칙 우리는 1NF부터 BCNF까지만 배울 예정 예제1) ● KEY ● FD 특정 Attribute를 통해 Table의 Tuple을 Unique하게 식별할 수 있다면 그게 FD가 될 수 있다. FD가 될 수 있는 것 - account_id - bank_name & account_num + empl_id 이 같으면 empl_name도 같다. + class가 같으면 bank_name도 같다. 정규화 ● 1NF - 규칙 : Attribut..

Functional Dependency : 한 테이블에 있는 두 개의 Attributes 집합 사이의 제약 Employee table에 6개의 Attribute가 있다고 해보자. 이걸 2개의 집합으로 나눠보자 특징 : 두 Tuple의 X값이 같다면, Y값도 같다. (당연함) 이렇게 X값에 따라 Y의 값이 유일 (Unique) 하게 결정될 때 = [ X가 Y를 함수적으로 결정한다. ] (functionally determin) = [ Y가 X를 함수적으로 의존한다. ] (functionally dependent) 이러한 제약 관계를 Functional dependency 라고 한다. 이름 → 생일 이렇게 둘 다 서로에게 고유한 값을 갖는다고 FD라고 생각하면 안된다. 동명이인이 올 수 있기 때문이다. 따라..