Physical Database Design

Slides:



Advertisements
Similar presentations
1 SQL 정보보호학과 양 계 탁. 2 SQL 개요 SQL 개요 3 Database u 연관된 데이터들의 집합 u 데이터를 쉽게 관리하는 프로그램 종 류종 류 관계형 데이터베이스 객체지향형 데이터베이스 계층형 데이터베이스 네트워크 데이터베이스 데이터를 2 차원적인 테.
Advertisements

의료자원 규제현황과 개선방향 자원평가실. 의료자원 관리 개요 규제개혁 토론과제.
전남행복수업 design 독서ㆍ토론 수업 지원 자료 활용 목포유달초등학교 김미향.
전남행복수업 design, 독서·토론수업 연구의 개요를 말씀드리겠습니다..
연 합 남 전 도 회 월 례 회 1부 예배- 찬 송 장 다같이 2011년 1월 2일 1부 예배- 찬 송 장 다같이 기 도
사 업 계 획 2011년 제1호 - 2월 1일 2011 주 안에서 소통하며 화합하고 참여하며 헌신하는 남신도회
소프트웨어시스템 실험 Software Systems Lab. (2012년 2학기) 강의 소개
12 프로젝트 실습.
실전 데이터모델링 & 데이터베이스 설계와 구축
SAP QUERY SAP R/3 4.6C.
제약 조건 부모 테이블 자식 테이블 입 력 수 정 삭 제  관계형성을 통한 참조 무결성
Chapter 02. 데이터 모델링.
질의어와 SQL 기본 SQL 고급 SQL 데이타의 수정 데이타 정의 언어 내장 SQL
관계 대수와 SQL.
SQL Server Migration Assistant For Oracle
Chapter 5 SQL: 확장된 질의, 주장, 트리거, 뷰.
제 5 장 인덱스 생성 및 관리.
효과적인 DB암호화 구축을 위한 애슬론 v1.5 제안
4장. 관계 대수와 SQL SQL 관계 데이터 모델에서 지원되는 두 가지 정형적인 언어
SQL-99: 스키마 정의, 기본제약조건, 질의어 충북대학교 구조시스템공학과 시스템공학연구실
7장 조인.
Apache Hive 빅데이터 분산 컴퓨팅 박영택.
SQL 개요 SQL 개요 - SQL은 현재 DBMS 시장에서 관계 DBMS가 압도적인 우위를 차지하는 데 중요한 요인의 하나
17장. 데이터를 안전하게 보관하자. (백업, 복원, 스냅숏)
Information Technology
12. 데이터베이스 설계.
Chapter 01 데이터베이스 시스템.
관계 데이터 모델과 제약조건 개념, 특성, 키, 무결성 제약조건.
11장. 데이터베이스 서버 구축과 운영.
강남/죽전/사당/잠실/성남/야탑/분당
SQL 함수 SQL 함수.
Data Modeling Database 활용을 위한 기초 이론 Database의 개요 Data Modeling
4.2 SQL 개요 SQL 개요 SQL은 IBM 연구소에서 1974년에 System R이라는 관계 DBMS 시제품을 연구할 때 관계 대수와 관계 해석을 기반으로, 집단 함수, 그룹화, 갱신 연산 등을 추가하여 개발된 언어 1986년에 ANSI(미국 표준 기구)에서 SQL.
ER-Win 사용 방법.
2장. 관계 데이터 모델과 제약조건 관계 데이터 모델은 지금까지 제안된 데이터 모델들 중에서 가장 개념이 단순한 데이터 모델의 하나 IBM 연구소에 근무하던 E.F. Codd가 1970년에 관계 데이터 모델을 제안함 관계 데이터 모델을 최초로 구현한 가장 중요한 관계 DBMS.
이산수학(Discrete Mathematics) 수학적 귀납법 (Mathematical Induction)
16장. 테이블의 변경 새로운 행 삽입 테이블에서 테이블로 행을 복사 행 값의 변경 테이블에서 행 삭제
DP-ORA 쿼리 최적화 가이드 쿼리 최적화 방법 2014년 7월.
01 데이터베이스 개론 데이터베이스의 등장 배경 데이터베이스의 발전 과정 데이터베이스의 정의 데이터베이스의 특징
문양세 (1st version: 문성우) (revised by 손시운)
Chapter 3: Introduction to SQL
정보처리기사 8조 신원철 양진원 유민호 이기목 김다연 윤현경 임수빈 조현진.
JSP 게시판 구현.
II. XML과 Database 연동 [Beginning XML, 제13장]
4. 관계 데이터베이스 (Relational Database)- 7, 8장
제 8 장 객체지향 데이타베이스와 데이타베이스의 새로운 응용 분야
View(뷰) 1 가상 테이블(Virtual Relation)
2장. 관계 데이터 모델과 제약조건 관계 데이터 모델은 지금까지 제안된 데이터 모델들 중에서 가장 개념이 단순한 데이터 모델의 하나 IBM 연구소에 근무하던 E.F. Codd가 1970년에 관계 데이터 모델을 제안함 관계 데이터 모델을 최초로 구현한 가장 중요한 관계 DBMS.
Copyright © 2012 Pearson Education, Inc. Publishing as Prentice Hall
데이터베이스 (Database) SQL 추가 기능: 주장, 뷰, 프로그래밍 기법 문양세 강원대학교 IT대학 컴퓨터과학전공.
4 장. 관계 데이터 모델과 관계 데이터베이스 제약조건
Database 중고차 매매 DB 비즈니스IT 윤동섭.
기본적인 SELECT문 작성.
4. 관계 데이터 모델.
McGraw-Hill Technology Education
관계 데이타 모델과 관계 데이타베이스 제약조건 충북대학교 구조시스템공학과 시스템공학연구실
SQL INJECTION MADE BY 김 현중.
06. SQL 명지대학교 ICT 융합대학 김정호.
제안 목적 고객성향 분석으로 매출 증대 유사업체 분석으로 신상품 홍보 원가요소 분석 및 피드백으로 원가율 관리
청각기관의 구조와 기능2 옥정달.
제 8장 데이터베이스.
Data Warehouse 구축 (설계 위주)
제 8 장 ER-관계 사상에 의한 관계 데이타베이스 설계
1. 관계 데이터 모델 (1) 관계 데이터 모델 정의 ① 논리적인 데이터 모델에서 데이터간의 관계를 기본키(primary key) 와 이를 참조하는 외래키(foreign key)로 표현하는 데이터 모델 ② 개체 집합에 대한 속성 관계를 표현하기 위해 개체를 테이블(table)
(제작자: 임현수)모둠:임현수,유시연,유한민
컴퓨터 프로그래밍 기초 - 11th : 파일 입출력 및 구조체 -
Database as Enterprise Models
ER-관계 사상에 의한 관계 데이터베이스 설계
제 5 장 MariaDB인덱스 생성 및 관리.
CHAPTER 4 관계 데이터 모델과 관계 데이터베이스 제약조건. CHAPTER 4 관계 데이터 모델과 관계 데이터베이스 제약조건.
Presentation transcript:

Physical Database Design

Sally Enterprise Logical Design 요약 RECIPE (Name, Sugar, Lemon, Water, Where_used) Key: Name Note: Where_used는 이 RECIPE를 사용한 PITCHER tuple 이다; multi valued PITCHER (Number, Date, Recipe_used, Where_sold) Key: Number Note: 1. Where_sold는 이 PITCHER를 주문한 ORDER tuple이다; multi valued 2. Current_Pitcher와 Amount_left는 class 속성이다. SALESPERSON (Name, Past_amount_sold) Key: Name Note: Past_amount_sold는 ORDER클래스의 Amount속성값이다; Multi valued CUSTOMER (F_name, L_name, Family, Past_amount_purchased, Total_amount) Key: (F_name, L_name) Note: Family는 같은 L_name을 갖는 CUSTOMER tuple이다; multi valued Past_amount_purchased는 ORDER의 amount 속성값이다; multi valued Total_amount는 SUM(Past_amount_purchased)로 계산되는 값이다. ORDER (Customer, Pitcher, SalesPerson, Date, Time, Amount) Key: (Customer, Pitcher, Time) Note: 1. Customer는 F_name과 L_name으로 이루어진다. 2. ORDER는 두개의 PITCHER로부터 이루어질 수 있으며 이 경우 multi valued이다 BIG_BUYER (attributes of CUSTOMER, Nickname, Sport) Key: (F_name, L_name Note: Sport 는 3개까지 허용되는 multi valued이다

RECIPE 의 Where_used 속성은 PITCHER tuple이고 여러 개의 PTICHER에 사용될 수 있으므로 여러 번 반복될 수 있다(multi valued로 표현되어 있음). PITCHER 에는 ORDER tuple인 Where_sold와 , RECIPE tuple인 Recipe_used를 가지고 있다. 또한 PITCHER에는 세 개의 클래스 속성(Total_produced, Active_Pitcher, Amount_left)가 있다.(앞 페이지에서는 생략됨) SALESPERSON 에는 ORDER tuple의 Amount속성이 있다. 같은 SALESPERSON이 여러 개의 ORDER를 처리할 수 있으므로 이 또한 multi valued이다. CUSTOMER 의 Family_members 속성은 그 자체가 다른 CUSTOMER tuple이고 multi valued이다. 또한 Past_amount_purchased는 Amount 속성을 가지고 있는 ORDER의 반복이고 Totalamount는 ORDER의 Amount 속성의 총 합과 같다. ORDER는 다른 클래스의 tuple을 포함하고 있지 않다. 그러나 반복적인 요소는 있다. 하나의 ORDER가 두 개의 PITCHER에서 이루어 졌을 경우(남은 양이 모자라서 새로 제조한 경우) Pitcher가 두 번 반복될 수 있다. BIG_BUYER 는 CUSTOMER의 확장으로서 Nick_name과 Favorite_sport가 최대 세 번 반복될 수 있다.

포함된 다른 Tuple과 반복속성의 제거 RECI_PITCH 관계 DB(Relational DB)에서는 Multi valued 속성이 Tuple(행)에 허용되지 않는다. 또한 하나의 Tuple에 다른 Tuple을 포함하는 것이 허용된다면 두 개의 Tuple이 서로를 재귀적으로 포함하게 될 것이므로 이것도 물리적인 DB에서는 허용될 수 없다. 이 문제를 해결하기 위하여 RECIPE와 PITCHER를 다음과 같이 하나의 Relation으로 join하여 나타낼 수 있다. (Where_sold 속성은 테이블의 크기를 줄이기 위하여 생략됨) RECI_PITCH Name Sugar Lemon Water Where_used Number Date Recipe_used A 2 4 3 101 101 190731 A A 2 4 3 104 104 190801 A A 2 4 3 107 107 190804 A B 3 3 2 102 107 190802 B B 3 3 2 105 105 190803 B Equi Join형태의 테이블

RECI_PITCH PITCHER RECIPE 앞 페이지의 테이블에서 중복된 데이터를 제거한 형태의 단순화된 테이블은 아래와 같다. Name Sugar Lemon Water Number Date A 2 4 3 101 180731 A 2 4 3 104 180801 A 2 4 3 107 180804 B 3 3 2 107 180802 B 3 3 2 105 180803 RECI_PITCH Natural Join형태의 테이블 이 테이블이 필요하기는 하지만 정규화된 형태의 작은 테이블로 나누고 필요한 시점에 Join연산을 하용하여 다시 구성할 수 있도록 하는 것이 더 바람직하다. 아래는 위의 테이블을 두 개의 작은 테이블로 나뉜 것을 보여주고 있다. Number Date Recipe_used 101 180731 A 104 180801 A 107 180804 A 102 180802 B 105 180803 B PITCHER Name Lemon Sugar Water A 2 4 3 B 3 3 2 RECIPE

SELECT PITCHER.Number, PITCHER,Date FROM PITCHER, RECIPE 논리적 설계로부터 얻은 첫 번 째 테이블(RECI_PITCH)은 다음 DML(SQL)을 통하여 두 개의 테이블을 Join하면 다시 재 구성할 수 있다. SELECT PITCHER.Number, PITCHER,Date FROM PITCHER, RECIPE WHERE PITCHER.Recipe_used = RECIPE.Name 예를 들어서 레몬이 3개 들어간 레시피를 사용한 Pitcher의 번호와 제조 날짜를 추출하려면 다음 SQL을 사용할 수 있다. SELECT * FROM PITCHER, RECIPE WHERE PITCHER.Recipe_used = RECIPE.Name AND RECIPE.Lemon = 3 102 180802 105 180803 Tuple 다른 tuple이 반복되는 것을 제거하는 방법을 요약하면 다음과 같다. ① 1 대 다 관계에서 자식의 입장에 있는 클래스의 tuple에서 부모 tuple을 부모 tuple의 Key로 대체한다. ② 부모 클래스의 tuple에서 반복되는 자식 tuple을 모두 제거한다. ③ 두 클래스의 관계에 따른 tuple을 얻기 위하여서는 부모의 키 값을 사용하여 Join한다.

앞에서 설명한 방법은 RECIPE와 PITCHER 사이에서 뿐 아니라. PITCHER와 ORDER, SALESPERSON과 ORDER, CUSTOMER와 ORDER 사이에서도 사용될 수 있다. 이 들이 모두 1대 다 관계이기 때문이다. 이와 같이 테이블을 정리해 나가는 과정에서 항상 두 Relation의 속성 값의 제약(Interrelation constraints)을 생각해 보아야 한다. 예를 들어서 PITCHER의 Where_used속성 값은 RECIPE에 존재하지 않는 Name을 사용할 수 있는가? 혹은 RECIPE에는 PITCHER에서 한번도 사용하지 않은 tuple도 존재할 수 있는가? 등이다. PITCHER의 Where_used에 존재하지 않는 RECIPE의 Name이 사용될 수 없는 것이 당연하므로 다음과 같은(혹은 다른 표현을 사용하여) 이 제약을 기록해 두어야 한다. PITCHER[Recipe_used] SUBSET OF RECIPE[Name]

아래는 지금까지 설명한 방법을 적용하여 정리된 물리적인 DB의 테이블과 속성필드명이다) RECIPE (Name, Sugar, Lemon, Water) Key: Name PITCHER (Number, Date, Recipe_used) Key: Number SALESPERSON (Name) CUSTOMER (F_Name, L_Name) Key: (F_name, L_name) ORDER (Cust_f_name, Cust_l_name, Pitcher, Salesperson, Date, Tie, Amount) Key: Cust_f_name, Cust_l_name, Pitcher, Time) NICKNAME (Cust_f_name, Cust_l_name, Nickname) Key: (Cust_f_name, Cust_l_name) CUST_SPORT (Cust_f_name, Cust_l_name, Favorite_sport) Key: (Cust_f_name, Cust_l_name, Favorite_sport) CLASS_ATTRIBUTE (Relation_name, Attribute_name, Value) Key: (Relation_name, Attribute_name) Relation of Sally Enterprises Schema 3

PITCHER [Recipe_used] SUBSET OF RECIPE [Name] ORDER [Pitcher] SUBSET OF PITCHER [Number] ORDER [Cust_f_name, Cust_l_name] SUBSET OF CUSTOMER [F_name, L_name] ORDER [Salesperson] SUBSET OF SLAESPERSON[Name] NICKNAME [Cust_f_name, Cust_l_name] SUBSET OF CUSTOMER [F_name, L_name] CUST_SPORT[Cust_f_name, Cust_l_name] SUBSET OF CUSTOMER [F_name, L_name] Relation간의 제약사항 기술 Domain Name Format and meaning CUPS 숫자 99.99; 설탕의 양 DATES 숫자문자 YYMMDD LEMON_COUNT 10 미만의 양의 정수 F_NAMES CHAR(10); 고객의 이름 L_NAMES CHAR(20); 고객의 성 S_NAMES CHAR(20); 영업사원의 이름 N_NAMES CHAR(20); 고객의 별칭 PITCHER_NUMBERS 500미만의 양의 정수 QUARTS 숫자 9.99; 물과 제조된 레모네이드의 양 RECIPE_NAMES CHAR(10) SPORTS_NAMES ‘축구’, ‘미식축구’, ‘테니스’, ‘농구’, ‘스키’ 중 하나 TIMES HH.MM HH는 0~23 사이의 정수문자, MM은 0~59사이의 정수 문자. Domains

Attributes Domain RECIPE.Name RECIPE_NAMES RECIPE.Sugar CUPS RECIPE.Lemon LEMON_COUNT RECIPE.Water QUARTS PITCHER.Number PITCHER_NUMBERS PITCHER.Date DATES PITCHER.Recipe_used RECIPE_NAMES SLAESPERSON.Name S_NAMES CUSTOMER.F_name F_NAMES CUSTOMER.L_name L_NAMES ORDER.Cust_f_name F_NAMES ORDER.Cust_l_name L_NAMES ORDER.Pitcher PITCHER_NUMBERS ORDER.SalesPerson S_NAMES ORDER.Date DATES ORDER.Time TIMES ORDER.Amont QUARTS NICKNAME.Cust_f_name F_NAMES NICKNAME.Cust_l_name L_NAMES NICKNAME.Nickname N_NAMES CUST_SPORT.Cust_f_name F_NAMES CUST_SPORT.Cust_l_name L_NAMES CUST_SPORT.Favorite_sport SPORT_NAMES 속성과 속성의 Domain