고정된 길이라면 임의의 n번째 데이터의 시작점을 알기 쉽다 데이터가 삭제되었을 때 어떤 레코드나 그 위치로 대체될 수 있다 히프 화일, 순차 화일을 실제 DB에 사용하기에는 무리가 있다 실제로는 인덱스를 활용함 중복되는 키를 가지고 인덱스를 만들 수 있음 기본 키에 대해 화일이 정렬되어있다면 각 데이터 블록에서의 대표 키 값만 가지고도 인덱스를 만들 수 있다 희소(일부만 가지고 만듦) ↔ 밀집(모든 것을 가지고 만듦) 같은 탐색 키를 갖는 것들은 모여있기 때문에 해당 키로 검색된 데이터 주변에 범위 질의하기 유용하다 탐색 키 값에 따라 정렬되어 있지 않기 때문에 반드시 밀집 인덱스 형태로 만들어야 함 인덱스 엔트리가 많아지므로 접근 횟수가 증가해 느림 희소 인덱스 형태보다 느리다 출처: http://ww..
seek time이 주요함 한 릴레이션을 같은 실린더에 저장하면 효율이 좋음 성능을 위해 DBMS만의 버퍼와 버퍼 교체 알고리즘을 따로 두어 관리하기도 함 대부분 헤더에 제어정보 입력 고정 길이일 때 관리하기 편함 실제 디스크에는 연속적으로 저장되어있지 않다 (빈 디스크에 저장하는 경우 제외) 연결리스트를 활용해 연결된 모습 레코드에 데이터가 정렬되어 저장되어있는 경우 채우기 인수(fill factor)가 적은 경우가 유리하다 출처: http://www.kocw.net/home/cview.do?lid=1294cedf7b88abf5
한계: 단순 애트리뷰트들의 상위 애트리뷰트가 존재하는지, 존재한다면 무엇인지 알 수 없음 E2에서 밑줄 친 두 애트리뷰트가 함께 기본 키 엔티티 하나를 정해서 다른 엔티티의 기본 키를 외래 키로 설정 한계: 외래 키로 설정된 애트리뷰트가 관계를 표현하기 위함인지 원래 속해있는 것인지 알기 어려움, 어떤 엔티티를 정하냐에 따라 접근 방향에 따른 성능 차이가 발생 방법 3 한계: 릴레이션이 추가되기 때문에 join할 작업이 많아짐 방법 4 한계: 식별가능한 엔티티들을 하나로 합쳤기 때문에 어떤 엔티티가 어떤 애트리뷰트를 가지는지 구별 불가능 일반적으로 방법1, 2 사용 애트리뷰트 값은 집합이 될 수 없음, 단일값 출처: http://www.kocw.net/home/cview.do?lid=2927bbacc7d..
부분 키인 Depname은 소유 엔티티 타입인 EMPLOYEE의 기본 키인 Empno와 같이 있어야 식별됨 통상 명사(엔티티), 형용사(애트리뷰트), 동사(관계) 엔티티 사이의 관계가 여러 종류가 있을 수 있으므로 그 타입을 다이아몬드 안에 표시함 관계 타입은 키 애트리뷰트를 가지는 것이 의미가 없음 데이터베이스 설계에 따라 참여 여부도 규제할 수 있음 관계 데이터 모델에서는 그 관계의 형태에 따라 릴레이션을 만드는 방법이 다르기 때문에 중요함 거래 가격을 결정하는데 있어서 복잡한 과정을 거친다면 엔티티로 취급하는 것이 나을 수 있음 출처: http://www.kocw.net/home/cview.do?lid=92b050137dd28549
커서: 프로그래밍 언어에서 작업 중인 투플의 위치를 가리키는 역할 fetch loop으로 검색 select title만 했으므로 into 다음에 속성이 title 하나만 있음 where current of: 커서가 현재 가리키는 투플 이렇게 독립적으로 update 문을 사용할 수도 있고, 위의 fetch loop에서 돌면서 수정할 수도 있음 SQLCODE에는 가장 최근에 DBMS에 요청한 쿼리가 잘 작동되었는지 여부가 들어있음 데이터베이스 설계와 ER모델 개념적 설계: 엔티티 정의, 엔티티 간의 관계 정의 + 프로세스 설계, 제약 논리적 데이터 모델: 관계 데이터 모델(사실상 표준), 계층 데이터 모델, 네트워크 데이터 모델 물리적 설계: 인덱스 만들기가 대표적 클라이언트의 요구사항을 잘 조사해야 애초부..
예) Table A의 data: val1, val1, val2, val3, val4, val5 Table B의 data: val1, val2, val2, val3 SQL 1: SELECT data FROM Table A EXCEPT SELECT data FROM Table B val4, val5 SQL 2: SELECT data FROM Table A EXCEPT ALL SELECT data FROM Table B val1, val4, val5 subquery끼리의 연산 결과로 나오는 새로운 릴레이션 select한 속성 앞에 릴레이션 이름이 없는 이유는 EMPNAME과 DEPTNAME이 각각의 릴레이션에 고유한 속성이기 때문 정렬 우선순위: DEPNAME(오름차순) -> SALARY(내림차순) 일반적으로..
연구된 SQL 이론에 비해 실용화 된 것은 극히 적다 update, delete, insert는 한 릴레이션 대상, select는 여러 릴레이션 대상이며 새로운 릴레이션 생성 alter는 보통 릴레이션에 attribute 추가 할 때 restrict: 제거할 스키마에 파일이 있다면 삭제 불가, cascade: 무조건 삭제 릴레이션 이름 정의, 그 밑에 각 attribute의 이름과 특성(도메인: 데이터 타입과 길이) 정의 primary key는 unique, 인덱스 부여하기도 함 foreign key(외래키) 그것이 참조하는 부분을 명시함 -> 참조 무결성 보장 자주 사용하는 attribute에 인덱스 부여해 쿼리 프로세스를 더 빠르게 함 -> self maintenance 기능 check 이후 내용을 ..
calculus: what, algebra: what + how 원하는 릴레이션이 나올 때까지 연산 수행 유도된 연산자는 필수 연산자로 표현 가능 릴레이션은 튜플들의 집합이므로 집합 연산도 가능 단항: 피연산자 1개, 이항: 피연산자 2개 bag: 중복을 허용하는 집합 프로젝션 연산에서 중복 제거에 시간이 너무 많이 소요되므로 중복 제거하지 않기로 타협 중복 제거 요청이 있을 경우에만 수행 join하기 위한 전단계로 생각 일반적으로 공통 attribute를 가지고 묶는다 B#에 해당하는 요소를 모두 가지는 A# 내의 요소 리턴 프로젝션 먼저 수행 후 셀렉션하면 오류 발생 다차원 분석에서 차원 = attribute (예: 부서, 연도, 지역, 등) 출처: http://www.kocw.net/home/cvi..
https://school.programmers.co.kr/learn/courses/30/lessons/92342 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr * 풀이 못 함 from itertools import combinations_with_replacement as cr def solution(n, info): # 중복조합으로 모든 경우 탐색하면서 정답 갱신 # 최대로 점수 차이가 클 때의 점수 분포 + 그 때의 점수 차이 값(max[-1]) max = [-1] * 12 for comb in cr(range(11), n): cur = [0] * ..
https://school.programmers.co.kr/learn/courses/30/lessons/92341 프로그래머스 코드 중심의 개발자 채용. 스택 기반의 포지션 매칭. 프로그래머스의 개발자 맞춤형 프로필을 등록하고, 나와 기술 궁합이 잘 맞는 기업들을 매칭 받으세요. programmers.co.kr * 내 풀이: from math import ceil from collections import defaultdict def solution(fees, records): table = defaultdict(lambda : [0]) # 각 차량의 입출차 기록 딕셔너리에 저장 및 첫 정보는 각 차량별 기록 갯수 for record in records: time, num, inout = record.s..
