All Days 무한도전

트랜잭션이란? 

데이터베이스의 논리적인 작업의 처리 단위이다.

여기서 작업이라 함은 일반적으로 데이터베이스에서의 데이터 입력，수정，

삭제 등을 말하는 것으로 데이터베이스에 변경사항을 유빌하는 행위를 말한다.

그리고 하나의 입력, 수정, 삭제 직업이 개별적인 트랜잭션으로 처리될 수도 있지만,

하나의 트랜잭션 내에서 여러 작업이 포함될 수도 있다.

그래서 트랜잭션읕 물리적이 아닌 논리적인 작업의 처리단위라고 하는 것이다.

그리고 트랜잭션의 기본 개념은 All or Nothing 이다.

 # 트랜잭션

-- 명시적 트랜잭션   : Begin(O),Commit(O)

-- 암시적 트랜잭션   : Begin(X),commit(O) ==> 오라클

-- 자동커밋 트랜잭션 : Begin(X),commit(X) ==> MS SQL Server

-- set implicit_transactions on

-- AA 창 --

select * from TC

begin tran

 update TC set id = 11 where id = 10

 update TC set id = 22 where id = 20

 update TC set id = 33 where id = 30

commit tran

select @@TRANCOUNT

-- BB 창 --

 use master

 Alter database sqlDB set allow_snapshot_isolation on

 set Transaction isolation level snapshot

  -- 잠금에 걸린 Tabble이라도 메모리(캐시)가 아닌 

-- 데이터 파일의 내용을 무조건 읽어올수 있도록 만들어 줌

select * from TC

# 체크포인트

체크 포인트(Check Point) 프로세스는 현재까지 메모리에서 진행된 모든 내용을 데이터 파 일과 로그 파일에 기록하는 프로세스로이다. 마치 워드나 엑셀 같은 프로그램에서 저장버튼 을 누르는 것과 같은 역할을 수행한다. 미러한 체크 포인트는 기본적으로 SQL Server가 1분마다 상황을 체크해서 많은 작업(많은 작업에 대한 판단은 SQL Server가 한다)이 있었던 경우 발생하기 때문에 궁극적으로 비주 기적으로 발생된다고 할 수 있다. 다시 말해서 데이터베이스에서 많은 작업이 일어나면 체 크 포인트가 발생하는 주기는 1분이 될 것이며, 데이터베이스에서 일어나는 작업이 많지 않 으면 체크 포인트가 발생하는 주기를 예측할 수 없다는 말이 된다.

# 레이지 라이터 & 로그라이터

 - 레이지 라이터(Lazy Writer)

레이지 라이터(Lazy Writer)라는 프로세스는 메모리 상의 프로시저 캐시에서 시용 빈도가

낮은 실행 계획을 메모리에서 제거하고 버퍼 캐시에 있는 더티 페이지(Dirty Page)들을 디

스크에 기록함으로써 메모리상에 빈 공간을 확보하기 위해서 동작하며, 이 역시 백그라운드

프로세 스로 주기적으로 동작한다.

 - 로그 라이터(Log Writer)라는 프로세스는 트랜잭션이 완료(Commit, 커밋)되면 자동으로

커밋된 트랜잭션에 대한 로그를 트랜잭션 로그 파일에 기록하는 프로세스이다.

### 참조 제약 조건

create table byTbl

(no <-- 숫자 증가값

 name --> uTbl(userid)

 prodname

 groupname

 price

 amount

 ------------------------------------------

  create Table byTbl

(num int Identity Not Null Primary Key,

 userid nchar(8) Not Null 

Foreign Key References uTbl(userid),

 prodName nchar(6) Not Null,

 groupName nchar(4),

 price int Not Null,

 amount smallint Not Null

)

go

### JOIN 사용

-- userTbl,buyTbl에서 하세요

--1) 키가 180 이상인 사람의 userid, 이름, 거주지는?

select userID, name, addr

from userTbl

where height >= 180

--2) 핸드폰 번호가 011,018 인 사람의 userid, 이름, 거주지는?

select userID,name,addr,mobile1

from userTbl

where mobile1 in ('011','018')

--3) 이름이 박주영인 사람의 구매한 목록, 즉

-- 이름,userid, 상품명, 가격, 수량을 구하시요.

select u.name, u.userID, b.prodName, b.price, b.amount

from userTbl u, buyTbl b

where u.userID = b.userid

  and u.name = '박주영'

SELECT     userTbl.userID, userTbl.name, buyTbl.prodName, buyTbl.price, buyTbl.amount

FROM         buyTbl INNER JOIN

             userTbl ON buyTbl.userid = userTbl.userID

WHERE     (userTbl.name = N'박주영')

--4) 키가 182 이상인 사람들의 이름,키,userid, 

-- 상품명,가격,수량은?

select u.name, u.height, u.userID, b.prodName, b.price, b.amount

from userTbl u, buyTbl b

where u.userID = b.userid

and u.height >= 182

--5) 키가 182 이상인 사람별 이름, 총구매금액 중 1000이상인

-- 것만 나타내시오

select u.name, sum(b.price*b.amount) as 총구매금액

from userTbl u, buyTbl b

where u.userID = b.userid

and u.height >= 182

group by u.name

having sum(b.price*b.amount) >= 1000

--6) 안정환보다 키가 큰 사람의 이름,birthyear,addr,height ?

--1> 안정환의 키?

select height

from userTbl

where name = '안정환' --> 182

--2> 그 키보다 큰사람의 ~~~~

select name,birthYear,addr,height

from userTbl

where height > 182

--3> 문장 합치기

select name,birthYear,addr,height

from userTbl

where height > (select height

from userTbl

where name = '안정환')

--7) 김남일보다 키가 큰 사람의 이름과 거주지,키

--   구매상품명,가격,수량은?

--1> 김남일의 키는?

select height

from userTbl

where name = '김남일' -- 183

--2> 그 키보다 큰 사람의 ~~~?

select u.name,u.addr,u.height,b.prodName,b.price,b.amount

from userTbl u, buyTbl b

where u.userID = b.userid

and u.height > 183

--3> 문장합치기

select u.name,u.addr,u.height,b.prodName,b.price,b.amount

from userTbl u, buyTbl b

where u.userID = b.userid

and u.height > (select height

from userTbl

where name = '김남일')

### VIEW 설명

 # 뷰(View)

 1) 정의 : Select 문장의 덩어리 

(가상의 논리적 테이블)

 2) 목적 : 편의성, 보안성, 성능향상

 3) 종류 :

- 일반 View

- Index View

- Partition View

drop view v_userTbl

create view v_userTbl

as

 select userid,name,addr from userTbl

select * from v_userTbl 

where name='이천수'

select * from userTbl

update v_userTbl set addr='ZZ' where name = '이천수'

update v_userTbl set height=100 where name = '이천수'

insert into v_userTbl values ('KKK','김금갑','PP')

insert into v_userTbl (userid,name,addr) 

values ('KKK','kkKim','PP')

create View v_userTbl3

 as

 select userid,name,birthyear,addr from userTbl

insert into v_userTbl3 values ('KKK','kkKim','1977','PP')

select * from v_userTbl3

delete v_userTbl3 where userid='KKK'

select * from userTbl

create View v_userTbl4

 as

 select * from userTbl where height >= 180

select * from v_userTbl4

delete v_userTbl4 where height < 180 

select * from userTbl

update v_userTbl4 set birthyear ='1111' 

where height < 180

insert into v_userTbl4 

values ('TTT','ggHong','4444','GG',010,0101,190)

insert into v_userTbl4 

values ('ZZZ','ggHong','4444','GG',010,0101,100)

select * from userTbl

alter view v_userTbl4

as

 select * from userTbl where height >= 180

 with check option

select * from sys.views

Exec sp_helptext 'v_userTbl4'

alter View v_userTbl4

 with Encryption

as

 select * from userTbl where height >= 180

with check option

use sqldb

select * from userTbl --> userTbl2

select * into userTbl2 from userTbl

select * from userTbl2

-- view를 생성 

-- (userid, name, birthyear, addr, height)

create view v_uTbl2

as

select userid,name,birthyear,addr,height

from userTbl2

select * from v_uTbl2

-- userTbl2 에서 height 컬럼을 제거해보세요

alter table usertbl2

drop column height

go

select * from userTbl2

select * from v_uTbl2 <-- 실행되는지요?

drop view v_uTbl3

create view v_uTbl3

with schemabinding

as

select userid,name,birthyear,addr,mobile2

from dbo.userTbl2 --> table명 앞에 dbo 스키마를 선언

go

select * from v_uTbl3

alter table usertbl2

drop column mobile2

go

## SQL Injection

 ID     [  admin' or 1=1 !--  ] 

 PWD    [  1234  ]  

select * from where id ='swhong' or 1=1 

   select * from where id='admin' or 1=1 1!--' and pwd = '1234'

  Exec sp_userid('jane','1234')

 ### 저장프로시저 (Stored Procedure)

 1) 정의 : - Transact-SQL 문장의 집합 

 2) 용도 :

- 어떠한 동작을 절차적 일괄처리 작업하는데 사용

- SQL Server에서 사용하는 프로그래밍 기능

 3) 특징 :

- SQL Server의 성능향상 (첫 실행시 컴파일, 재컴파일 안함)

- 모듈식 프로그래밍 가능

- 보안강화 (저장프로시저 마다의 권한할당 가능)

- 네트워크 전송량 감소 (긴 쿼리문장의 단순화)

 4) 장점 :

- 빠르다

- 파라미터를 사용할 수 있다

- 여러 어플리케이션과 공유할수 있다

------------------------------------------------------------------

 # 일반적인 T SQL 구문 실행절차

1. 첫실행시

 1) 구문분석

 2) 개체검사

 3) 권한확인

 4) 최적화경로확인

 5) 컴파일(with 실행계획) --> 메모리 상주

 6) 실행

2. 두번째실행시 (구문이 같아야)

 1) 기 컴파일 사용

 2) 실행

 # 저장 프로시저

1. 첫실행시

 1) 구문분석

 2) 개체검사

 3) 권한확인

 4) 최적화경로확인

 5) 컴파일(with 실행계획) --> 메모리 상주

 6) 실행

2. 두번째실행시 (구문이 같지않아도)

 1) 기 컴파일 사용

 2) 실행

 use sqldb

create Procedure usp_userTbl

as

 select * from userTbl

Exec usp_userTbl

-- View 일 경우 --

create view v_Test 

as

   select * from userTbl

select * from v_Test where userID = 'AJH'

create Proc usp_userTbl2

 @userid nchar(8)

as

 select * from userTbl where userid = @userid

go

Exec usp_userTbl2 'AJH'

create Proc usp_userTbl3

 @a int,

 @b int

as

 select * from userTbl where birthyear > @a and birthyear <= @b

go

Exec usp_userTbl3 1978,1982

create Proc usp_userTbl4

@userid nchar(8)

as

declare @byear int

select @byear = birthyear from userTbl where userid = @userid

if (@byear >= 1978)

Begin

Print 'Low Age'

end

else

Begin

Print 'High Age'

end

go

Exec usp_userTbl4 'AJH'

-- Input Value, Output Value

create Proc usp_userTbl5

@userid nchar(8),

@outAge int OutPut

as

Declare @bYear int

select @bYear = birthyear from userTbl where userid = @userid

select @outAge = Year(getdate()) - @bYear

-- Execute SP

declare @iAge int

Exec usp_userTbl5 'AJH', @iAge Output

Print 'Your Age ==> ' + cast(@iAge as char(5))

select @@NESTLEVEL

### 사용자 정의 함수 (User Defined Function)

 1) 정의 : 리턴값을 갖는 프로시저의 종류

 2) 유형 : 

- 스칼라(Scalar) 함수 

- 테이블 함수

  - 인라인 테이블 값 (Inline Table Valued)함수

  - 다중문 테이블 값 (Multi Statement Table Valued)함수

 3) 제약사항 :

- 함수 내부에 Try Catch 문을 사용할 수 없다

- 함수 내부에 DDL문(Create/Alter/Drop)을 사용할 수 없다

 @ 스칼라 함수: Return문에 의해서 하나의 단일값을 돌려주는 함수

 @ 인라인 테이블값 함수 : Select 문장의 결과 집합을 돌려주는 함수

 @ 다중문 테이블 값 함수 : 정의된 임시 테이블 자체를 돌려주는 함수

 create #tmpTbl (id txt) : 사용할 수 없음

Inline_Fuction.sql

Muti_Fuction.sql

Scalar_Fuction.sql

exec sp_help usertbl  -- 테이블 분석

## 제약조건(Constraint)

create Table uTbl

(userID nchar(8) Not Null 

Constraint PK_userTbl_userID Primary Key,

 name nvarchar(10) Not Null

Constraint UQ_userTbl_name Unique,

 birthYear int Not Null --> 올해와 이후 100년 사이

Constraint CK_userTbl_BY 

check(birthyear>=year(getdate())

and birthyear<year(dateadd(yy,100,GETDATE()))),

 addr nchar(4) Not Null  --> 기본값 (서울)

Constraint DF_userTbl_addr default('서울'),

 mobile1 nchar(3) --> 010,011,016,017,018,019

Constraint CK_userTbl_mob1

check(mobile1 in ('010','011','016','017','018','019')),

 mobile2 nchar(8),

 height smallint --> 0 ~ 250

Constraint CK_userTbl_height

check (height > 0 and height <= 250)

)

go

select GETDATE()

select YEAR(getdate())

select year(dateadd(yy,100,GETDATE()))

페이지

---

SQL Server에서 페이지의 크기는 8KB입니다. 이 사실은 SQL Server 데이터베이스에 메가바이트당 128페이지가 있음을 의미합니다. 각 페이지는 96바이트 머리글로 시작하는데 이 머리글은 페이지에 대한 시스템 정보를 저장하는 데 사용됩니다. 페이지 번호, 페이지 유형, 해당 페이지의 사용 가능한 공간 크기 그리고 해당 페이지를 소유하고 있는 개체의 할당 단위 ID와 같은 정보를 저장합니다.

다음 표에서는 SQL Server 데이터베이스의 데이터 파일에서 사용되는 페이지 유형을 보여 줍니다.

페이지 유형	내용
데이터	text in row가 ON으로 설정된 경우에 text, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml 데이터를 제외한 모든 데이터가 있는 데이터 행
인덱스	인덱스 항목
텍스트/이미지	큰 개체 데이터 형식: text, ntext, image, nvarchar(max), varchar(max), varbinary(max) 및 xml 데이터 데이터 행이 8KB를 초과하는 경우 가변 길이 열: varchar, nvarchar, varbinary 및 sql_variant
전역 할당 맵, 공유 전역 할당 맵	익스텐트가 할당되었는지 여부에 대한 정보
페이지의 사용 가능한 공간	페이지 할당 및 페이지의 사용 가능한 공간에 대한 정보
인덱스 할당 맵	테이블 또는 인덱스에서 할당 단위당 사용하는 익스텐트에 대한 정보
대량 변경 맵	마지막 BACKUP LOG 문 이후에 할당 단위당 대량 작업에 의해 수정된 익스텐트에 대한 정보
차등 변경 맵	마지막 BACKUP DATABASE 문 이후에 할당 단위당 변경된 익스텐트에 대한 정보

참고
로그 파일은 페이지는 포함하지 않으며 일련의 로그 레코드를 포함합니다.

데이터 행은 머리글 바로 다음부터 시작하여 페이지에 차례로 나옵니다. 행 오프셋 테이블은 페이지 끝에서 시작하는데 각 행 오프셋 테이블에는 해당 페이지에 있는 각 행에 대한 항목이 하나씩 있습니다. 각 항목은 해당 행의 첫째 바이트가 페이지 시작 지점에서 얼마나 떨어져 있는지를 기록합니다. 행 오프셋 테이블의 항목 순서는 페이지의 행 순서의 역순입니다.

대용량 행 지원

행들이 여러 페이지에 걸쳐 있을 수 없지만 그러한 행 부분들이 해당 행의 페이지를 벗어나서 해당 행이 실제로는 아주 커질 수 있습니다. 한 페이지의 단일 행에 데이터와 오버헤드가 최대 8,060바이트(8KB)까지 저장됩니다. 그러나 텍스트/이미지 페이지 유형에 저장되는 데이터는 여기에 포함되지 않습니다. varchar, nvarchar, varbinary 또는 sql_variant 열이 있는 테이블의 경우 이러한 제한이 완화됩니다. 테이블에 있는 모든 고정 및 변수 열의 전체 행 크기가 8,060바이트 한계를 초과하면 SQL Server는 하나 이상의 가변 길이 열을 가장 너비가 넓은 열부터 시작하여 ROW_OVERFLOW_DATA 할당 단위에 있는 페이지로 동적으로 옮깁니다. 삽입 또는 업데이트 작업으로 행의 전체 크기가 8060바이트 한계를 초과하면 이러한 작업이 수행됩니다. 열이 ROW_OVERFLOW_DATA 할당 단위의 페이지로 이동하면 IN_ROW_DATA 할당 단위에 있는 원래 페이지의 24바이트 포인터가 그대로 유지됩니다. 후속 작업으로 행 크기가 줄면 SQL Server가 동적으로 열을 다시 원래 데이터 페이지로 이동합니다. 자세한 내용은 8KB를 초과하는 행 오버플로 데이터를 참조하십시오.

익스텐트

---

익스텐트는 공간 관리의 기본 단위입니다. 하나의 익스텐트는 실제로 연속하는 8페이지 또는 64KB입니다. 이 사실은 SQL Server 데이터베이스에 메가바이트당 익스텐트가 16개 있음을 의미합니다.

SQL Server은 효율적인 공간 할당을 위해 적은 양의 데이터를 포함하는 테이블에 전체 익스텐트를 할당하지 않습니다. SQL Server에는 다음 두 가지 유형의 익스텐트가 있습니다.

• 균일 익스텐트는 단일 개체가 소유합니다. 또한 익스텐트의 전체 8페이지는 소유하는 개체만 사용할 수 있습니다.

• 혼합 익스텐트는 최대 8개의 개체가 공유할 수 있습니다. 익스텐트의 8페이지를 각각 다른 개체가 소유할 수 있습니다.

일반적으로 새 테이블이나 인덱스에는 혼합 익스텐트의 페이지가 할당됩니다. 테이블이나 인덱스의 페이지가 8페이지로 증가하면 후속 할당을 위해 균일 익스텐트를 사용하도록 전환됩니다. 인덱스에 8개의 페이지를 생성하는 데 충분한 행을 가진 기존 테이블에서 인덱스를 만드는 경우 인덱스에 대한 모든 할당 항목은 균일 익스텐트에 있습니다.

### SHRINK 테스트

@@@ shrink database @@@

use master
create database shrinkDB
on Primary
(name = shrinkDB,
 Filename = N'C:\database\sDB\shrinkDb.mdf',
 size=3MB)
Log on
(name = shrinkDB_Log,
 Filename= N'C:\database\sDB\shrinkDb_log.ldf',
 size=3MB)

-- 1 (insert A) --

use shrinkDB
create Table test (txt varchar(1024))
go

Declare @i int
set @i = 0
while @i < 1024*10
Begin
 insert into test values (replicate ('A', 1024)) 
 set @i = @i+1
end

-- 2 (insert B,C) --

Declare @i int
set @i = 0
while @i < 1024*10
Begin
 insert into test values (replicate ('B', 1024)) 
 set @i = @i+1
end

set @i = 0
while @i < 1024*10
Begin
 insert into test values (replicate ('C', 1024)) 
 set @i = @i+1
end

-- 3 (shrink database [SSMS])

-- 4 (view Size)

-- 5 (delete B)
delete test where substring(txt,1,1) = 'B'

-- 6 (shrink database [SSMS])

-- 7 (view Size)

### File Group

 - Database Object에 대한 저장

 - Data File의 묶음

 - Raid 0 구성 (I/O를 향상) 

   -> 물리적 드라이브가 실제 분리되어 있어야 효과

 - 주 Data File(.mdf)은 기본적으로

   -> Primary File Group 소속되어져 있음

 - Primary File Group은 읽기 전용 그룹이 될 수 없음

 - 나머지 File Group은 읽기 전용 그룹이 될 수 있음

 - 백업/복원의 대상이 됨

 - 증분복원: 단계적 복원이 가능

# Table 이란??

 - Data가 저장되어지는 논리적 구조의 객체(그릇)
 - 행(Record)과 열(Column)이 존재
 - Table in RDB(관계형DB)에서는 자기/다른 Table
 과의 관계(Relationship)설정이 가능

 -> 일관성, 무결성을 위한 모델링을 하게되면

    분리된 Table 사이에서 연결고리를

    찾는게 어려워 지기때문에

    그것을 관계를 통해 해결

 - 모델링, 정규화 --> 데이터의 무결성

 # E-R 관계 사상 알고리즘

 - 단계 1: 정규 엔티티  <= 테이블 + 기본키
 - 단계 2: 약한 엔티티  <= 부모의 키 + 부분키
 - 단계 3: 1:1 관계타입  <= 부모의 PK -> 자식의 PK,FK
 - 단계 4: 1:N 관계타입  <= 부모의 PK -> 자식의 FK
 - 단계 5: M:N 관계타입  <= 신규테이블 + [양측의 PK -> FK]
 - 단계 6: 다치 애트리뷰트  <= 신규테이블 + [부모의 PK -> FK]

# 정규화란 중복성을 최소화하고 정보의 일관성을 보장하기 위한 관계형 데이터 베이스에서 제일 중요한 개념.

# 정규화를 하는 이유

 - 데이터의 중복성 제거
 - 데이터 모형의 단순화
 - Entity,Attribut의 누락여부
 - 데이터모형의 안전성 검증

 # Data 무결성

 1) 참조무결성 : 테이블간 불일치 데이터 방지하자
 2) 실체무결성 : 기본키로 Row를 구분하자
 3) 도메인무결성: 잘못된 형식을 방지하자

 # 정규화
 
 1) 1정규형
 - 데이터의 중복제거
 - 컬럼의 중복제거

 2) 2정규형
 - 기본키 전체에 의존 컬럼분류

 3) 3정규형
 - 일반컬럼 의존적 컬럼 분리

# 제 1정규화

 - 엔티티 내의 모든 속성은 반드시 하나의 값을 가져야 한다.

 - 여러 값을 가진 컬럼이 존재할 수 없다. 즉 반복되는 그룹이 존재해서는 안 된다. 각 행과 열에는 하나의 값만이 올수 있다.

# 제 2정규화

 - 복합키를 식별자로 가지는 경우 복합키의 일부분에만 종속적인 항목을 분류하는 작업

 - 모든키가 아닌 컬럼은 기본 키 전체에 의존적이여야 한다. 기본키의 일부분에 의존적이어서는 안 된다.

# 제3정규화
 
 - 엔티티 내의 식별자를 제외한 모든 속성은 종속될 수 없다.

 - 키가아닌 컬럼은, 다른 키가 아닌 컬럼에 의존적일어서는 안된다.

# 역정규화

 - 데이터의 중복을 통해 과도한 논리적 결합현상을 피한다.
 
 - 유도된 컬럼을 추가하여 불필요한 연산을 피한다. (예)판매금액=수량*단가

 - 하나의 테이블을 2개 이상의 테이블로 분리하여 불필요한 컬럼의 검색을 피한다.

 - 자주 사용되는 테이블의 논리적 결합을 피하기 위해 집계테이블을 생성한다.

논리적 모델링 단계에서 논해야 하는 문제는 개념적 모델링 후,

매핑룰에 의해 기초적인 논리적 모델링으로 내려 오고

논리적 모델링시에는 흔히 이야기 하는 정규화 과정을 거치게 됩니다.

즉, 차수 정의(1:1, 1:M, N:M)관계는 이미 개념적 모델링에서 처리가 된다는 것입니다.

 DA# 프로그램으로 말하면 플래너 단계에서 이루어 진다고 봅니다.

이에 대한 논리적 모델링 단계에선 관계형 데이타 베이스에 맞는 모델링을 해야 합니다.

마지막 단계에서 역정규화 작업이나.. 여타 작업을 하지만,

이것이 테이블에 대한 분리를 이야기 하지 않습니다.

정규화 단계를 많은 사람들이 알고 있듯이 테이블의 분할이라는 것은

속성에 대한 재정의 (차수의 변경등에 의한)를

통해서 속성에 대한 테이블의 분리로 이루어 질 수 있습니다.

하지만, 논리적 모델링 단계에서는 DBMS의 벤더에 종속되지 않는 모델링이 이루어 져야 하고,

 관계형 데이터베이스의 이론에 충실한 모델링이 이루어 져야 합니다.

1:1 엔티티에 대한 내용은 역정규화시에 통합이 되어야 하고, 업무분석시에 이루어지는 검색조건이나, 여타 조건에 의한 테이블의 분할이라는 것은 DBMS가 정해지고 플랫폼의 정의가 이루어진 후, 물리적 모델링 단계에서 이루어 져야 한다고 봅니다.
저는 1:1 엔티티에 대한 통합은 논리적 모델링 관계에서 무조건적으로 통합되어야 한다고 봅니다.

####

BCNF 정규화는
3정규형에서 BCNF 정규형이 되려면 비결정자에의한 함수종속을 제거해야 하는것을 알고계시죠..
비결정자에 의한 함수종속을 제거해서 분해된 BCNF정규형은
결과적으로 모든 속성들이 후보키로서 사용이 가능한 형태로 분해됩니다.
다시 말해 분해된 테이블의 모든 결정자들이 후보키이면
BCNF정규형이라 말합니다
제4정규화는
2정규화 된 테이블은 다대다 관계를 가질수 없다.
이건 따로 예를 안들어도 되겠죠?ㅋㅋ

#### 제약조건

 1. PK  : 기본키 => 유일한값 , NULL(X), Index (기본값:CI)

 2. UQ  : 유니크 => 유일한값 , NULL(1[MS]), Index (기본값:NCI)
          NULL(다[Ora])

 3. FK : 외래키 => 자기/다른 테이블의 PK, UQ를 참조

  참조하는 컬럼의 DataType과 Size가 일치

 4. CK : 범위 설정 => 0 < 값 < 100
   열거 조건 => 값 in (값1, 값2, 값3,,,,)

 5. DF : 기본값

 6. NN : Not Null => Null 값 허용 여부