플랫 파일 데이터베이스
"오늘의AI위키"의 AI를 통해 더욱 풍부하고 폭넓은 지식 경험을 누리세요.
1. 개요
플랫 파일 데이터베이스는 단순한 구조의 데이터베이스로, 초창기 컴퓨터에서부터 사용되었으며, 텍스트 파일 형태로 데이터를 저장한다. 각 레코드는 한 줄에, 각 필드는 공백이나 구분자로 구분되어 저장되며, 구조적 관계는 존재하지 않는다. 플랫 파일 데이터베이스는 작성 및 편집이 용이하여 설정 파일 저장, 소규모 데이터 저장, 데이터 교환 등 다양한 용도로 활용된다. 관계형 데이터베이스와 비교하여 단순한 구조를 가지며, 관계형 데이터베이스 매니지먼트 시스템을 통해 관계형 데이터베이스처럼 사용할 수도 있다.
플랫 파일 데이터베이스의 역사는 컴퓨팅 기술 발전과 함께 한다. 초기 계산 기계는 단순한 데이터베이스를 구현하는데 사용되었다. 허먼 홀러리스는 미국 통계청의 인구 조사 데이터를 천공 카드에 기록하고, 이를 기계로 처리하는 아이디어를 고안했다. 1890년 미국 인구 조사는 이러한 방식으로 데이터가 처리된 최초의 전산화된 데이터베이스였다.
플랫 파일은 한 줄에 하나의 레코드를 기록하는 단순한 구조를 가진다. 각 필드는 고정 너비를 가지거나, 공백, 탭, 쉼표 등 공백 문자나 지정된 문자로 구분된다. 구분자를 사용하는 경우, '구분자 충돌'을 방지하기 위해 추가적인 형식 지정이 필요하다.
2. 역사
제2차 세계 대전 이후, 정부와 기업들은 컴퓨터를 활용하여 회계 등의 분야에서 플랫 파일 데이터베이스를 사용했다. 그러나 컴퓨터의 효율적인 사용에 대한 요구가 커지면서 관계형 데이터베이스가 등장하게 되었다. 홀러리스의 회사는 IBM으로 성장하여 시장을 지배했으며, IBM의 80열 천공 카드는 1970년대까지 데이터 입력의 주요 수단으로 사용되었다.
1980년대에는 매킨토시와 DOS 환경에서 사용자가 직접 데이터베이스를 구성할 수 있는 플랫 파일 데이터베이스 응용 프로그램들이 인기를 얻었다. 파일메이커 초기 버전이나 PC-파일 등이 대표적이며, 워드 프로세서나 스프레드시트만큼 널리 사용되었다. 이들은 제한적인 관계형 데이터베이스 기능을 제공하기도 했다.
2. 1. 초기 역사
컴퓨팅 기기는 초기에는 단순한 데이터베이스를 구현하기 위해 사용되었다. 허먼 홀러리스는 이름, 나이 등 미국 주민 정보를 숫자와 문자로 표현되는 80자 길이의 문자열로 나타내도록 설정했다. 각 주민의 성명 길이를 맞추기 위해 공백을 채웠고, 이는 데이터베이스 필드의 줄을 정렬하는 데 기여했다. 홀러리스는 미국 통계청에 이 아이디어와 관련 기기, 천공 카드를 판매했고, 실제로 주민 정보는 이러한 수단을 통해 기록 및 수집되었다. 1890년의 인구 조사는 최초의 전산화된 데이터베이스였으며, 실질적으로는 수천 개의 천공 카드를 담은 상자들이었다.
제2차 세계 대전 이후, 정부 기관과 민간 기업은 초창기 컴퓨터를 운용했다. 이 컴퓨터들은 급여 계산 등 회계 분야에서 플랫 파일 데이터베이스를 구현하는 데 사용되었다. 그러나 당시 매우 비쌌던 컴퓨터를 효율적으로 사용하고자 하는 욕구가 커졌고, 이는 초창기 관계형 데이터베이스 탄생의 계기가 되었다. 초창기 응용 프로그램들은 천공 카드의 원래 디자인을 조금 변경하여 계속 사용하였다. 홀러리스의 기업은 성장하여 컴퓨터 업계의 거인 IBM이 되었고, 시장 전반을 지배하였다. 고정 길이 필드를 가진 80열 천공 카드 기반 데이터베이스의 정당성은 문제가 되기도 하였다.
1980년대, 매킨토시와 도스에서 '설정 가능한' 플랫 파일 데이터베이스 응용 프로그램이 인기를 끌었다. 이러한 프로그램은 개인이 데이터베이스를 쉽게 디자인할 수 있게 해주었고, 워드 프로세서나 스프레드시트에 버금가는 인기를 누렸다. 파일메이커 초기 버전, PC-파일 등이 대표적이며, 파일 간 데이터 공유와 같은 제한적인 관계형 데이터베이스 기능을 제공했다.
2. 2. 발전과 대중화
허먼 홀러리스가 미국 인구 조사국을 위해 수행한 작업은 1890년 미국 인구 조사에서 처음 사용되었으며, 종이 카드에 구멍을 뚫어 데이터를 집계하는 방식을 사용했다.[3] 이는 카드 간의 색인이나 개별 카드를 서로 연결하는 방식을 사용하지 않고, 그룹 멤버십으로만 연결되었기에 최초의 컴퓨터화된 플랫 파일 데이터베이스로 간주되기도 한다.
1980년대에는 IBM PC와 매킨토시에서 구성 가능한 플랫 파일 데이터베이스 컴퓨터 응용 프로그램이 인기를 얻었다. 이 프로그램들은 개인들이 자신만의 데이터베이스를 설계하고 사용하기 쉽도록 설계되었으며, 워드 프로세서 및 스프레드시트와 거의 비슷한 인기를 누렸다. 플랫 파일 데이터베이스 소프트웨어의 예로는 초기 버전의 FileMaker와 셰어웨어 PC-File, 그리고 인기 있는 dBase가 있다.
계산 기계의 초기 용도로는 단순한 데이터베이스 구현이 있었다. 허먼 홀러리스는 국세 조사 데이터를 구멍이 뚫린 종이 카드(천공 카드)로 나타내고 기계를 사용하여 표를 만드는 아이디어를 생각해냈다 (타뷸레이팅 머신). 그는 이 컨셉을 미국 인구 조사국에 판매했다. 이로 인해 1890년 미국 인구 조사는 사상 처음으로 계산 기계를 사용하여 데이터베이스화되었다고 할 수 있다. 하지만 그 데이터베이스는 무수한 펀치 카드로 구성되어 있었다.
홀러리스의 회사는 IBM의 모태가 되었고, IBM은 20세기의 데이터 처리 시장을 계속 지배했다. IBM의 고정 길이 필드의 80열 펀치 카드는 1970년대까지 데이터 입력의 일반적인 수단으로 계속 사용되었다.
1980년대에 들어서 DOS 또는 매킨토시에서 설정 변경 가능한 플랫 파일 데이터베이스가 응용 소프트웨어로 다수 개발되었다. 그것들은 개인적인 데이터베이스를 쉽게 설계할 수 있었고, 워드 프로세서나 스프레드시트와 비슷한 정도로 판매되었다. 플랫 파일 데이터베이스 제품의 예로는 초기 FileMaker, 셰어웨어의 PC-File 등이 있다. 관계를 나타내는 능력은 제한적이었지만, 여러 파일 간에 데이터를 공유할 수 있었다.
플랫 파일 데이터베이스는 작성 및 편집이 쉽고 복잡하지 않은 방식으로 다양한 목적에 적합하기 때문에 널리 사용되고 있다.
2. 3. 현대의 구현
최근에는 사용자가 직접 플랫 파일 데이터베이스를 만들 수 있는 프로그램은 많지 않지만, 마이크로소프트 웍스(초창기 윈도 버전에만 제공), 애플웍스, 클라리스웍스(윈도 및 매킨토시 용) 등에서 플랫 파일 데이터베이스 기능을 제공했다. 볼랜드의 파라독스, 마이크로소프트 액세스 등은 초기에는 플랫 파일 데이터베이스 형태였으나, 시간이 지나면서 관계형 데이터베이스 기능과 내장 프로그래밍 언어를 포함하게 되었다. MySQL이나 오라클 DBMS 같은 데이터베이스 관리 시스템(DBMS)들은 프로그래머가 직접 응용 프로그램을 개발해야 사용할 수 있다.[1]
오늘날에도 응용 프로그램들은 설정 파일 등을 저장하기 위해 플랫 파일 데이터베이스를 널리 사용한다. 많은 응용 프로그램이 미리 정의된 필드를 사용하여 플랫 파일에서 사용자 고유의 정보를 가져올 수 있도록 지원한다. 작은 크기의 도서 관리 프로그램, 일정 관리 프로그램, 특히 주소록 프로그램 등은 플랫 파일을 자주 사용한다. XML은 일반 텍스트 파일에 데이터를 저장하는 데 널리 사용되는 포맷이지만, 복잡하고 중첩된 데이터를 저장할 수 있어 플랫 파일 데이터베이스로 분류하기는 어렵다.[1]
NoSQL 데이터의 선형 저장소, JSON 데이터, 기본적인 스프레드시트(쉼표나 탭으로 구분) 및 텍스트 파일은 통합된 인덱스, 데이터 요소 간의 내장된 참조, 복잡한 데이터 형식이 없기 때문에 플랫 파일 데이터베이스로 간주될 수 있다. 책, 약속, 주소록 모음을 관리하는 프로그램은 단일 목적 플랫 파일 데이터베이스를 사용하여 인덱스나 참조 시스템 없이 플랫 파일에서 정보를 저장하고 검색할 수 있다.[1]
사용자는 텍스트 파일에 목차를 작성할 수 있지만, 텍스트 파일 형식 자체는 목차 개념을 포함하지 않는다. 사용자가 John의 연락처 정보의 "Notes" 섹션에 "Kathy와 친구"라고 작성할 수 있지만, 이는 데이터베이스의 내장 기능이 아닌 사용자에 의해 해석되는 것이다. 데이터베이스 시스템이 레코드 간의 관계를 인식하고 코드화하기 시작하면 "플랫"에서 벗어나며, 유형과 계층적 관계를 설명하는 자세한 시스템을 갖추면 "플랫"으로 간주하기에는 너무 구조화된다.[1]
FairCom의 C-tree는 기업용 최근 구현 사례이다. 그러나 그 외에는 초보자가 플랫 파일 데이터베이스를 쉽게 사용할 수 있는 소프트웨어 제품은 적다. 이러한 기능은 Microsoft Works의 데이터베이스 기능(일부 버전의 Windows에서만 사용 가능), ClarisWorks라는 이름으로도 알려진 AppleWorks(Macintosh 버전과 Windows 버전이 있었다)에 있었다. 보랜드의 Paradox나 마이크로소프트의 Access와 같은 데이터베이스 소프트웨어가 관계형 데이터베이스적인 기능을 제공하게 되었고, 동시에 내장 프로그래밍 언어를 사용하게 되었다. MySQL이나 Oracle과 같은 데이터베이스 관리 시스템(DBMS)은 일반적으로 초보자가 다루기 어렵고, 프로그래머가 애플리케이션을 구축해야만 사용할 수 있다.[1]
많은 애플리케이션 소프트웨어는 내부적으로 플랫 파일 데이터베이스를 사용하여 설정 데이터를 저장한다. 사용자가 정보를 입력하거나 검색하는 형태의 애플리케이션은 내부적으로 플랫 파일을 사용할 수 있다. 예를 들어, 어떤 종류의 컬렉션 관리 소프트웨어나 캘린더 등이다. 작은 주소록 소프트웨어도 내부적으로는 플랫 파일에 정보를 저장하는 경우가 많다.[1]
XML은 일반 텍스트 파일에 데이터를 저장하는 데 자주 사용되지만, XML은 매우 구조적이며, 저장해야 할 데이터에 대해서도 정의되어 있다. 따라서 플랫 파일 모델과는 전혀 다르다.[1]3. 구조 및 특징
플랫 파일은 관계형 데이터베이스처럼 복잡한 구조적 관계를 갖지 않고, 종이 한 장과 같이 '정형화'된 데이터를 갖는다. '이름', '주소', '전화번호' 등 적은 수의 필드로 구성된 주소록이나, HTML 테이블 등이 플랫 파일 데이터베이스의 대표적인 예시다. 플랫 파일 데이터베이스는 일상에서 자주 볼 수 있지만, '데이터베이스'로 명확히 구분되지 않는 경우가 많다.
3. 1. 데이터 구조
일반적으로 플랫 파일은 한 줄에 하나의 레코드를 포함한다.[2]
각 필드는 공간 채워넣기(padding영어)를 통해 고정 너비를 갖도록 하거나, 공백, 탭, 쉼표와 같은 공백문자 또는 지정된 문자로 구분될 수 있다. 후자의 경우, 구분자가 실제 데이터에 사용되어 발생하는 ‘구분자 충돌’을 방지하기 위해 추가적인 형식 지정이 필요하다.
플랫 파일 내에는 구조적 관계가 존재하지 않는다. 관계형 데이터베이스처럼 복잡한 모델이 아닌, 종이 한 장과 같은 ‘정형화’된 데이터를 가진다.
플랫 파일 데이터베이스의 예로는, 적은 수의 필드로 구성된 주소록(이름, 주소, 전화번호 등)이나, 열과 행으로 이루어진 HTML 테이블이 있다.
다음은 플랫 파일 데이터베이스의 예시다. 데이터는 행과 열로 구성되어 표 형식으로 표현된다.
아이디 | 이름 | 등급 |
---|---|---|
1 | 철수 | 관리자 |
2 | 영희 | 관리자 |
3 | 찬희 | 일반사용자 |
4 | 길동 | 일반사용자 |
5 | 홍련 | 일반사용자 |
6 | 민희 | 관리자 |
7 | 길수 | 일반사용자 |
8 | 형구 | 일반사용자 |
이 예제에서는 한 개의 테이블이 사용되었다. 열은 '이름'(사람 이름), '등급'(위키백과 사용자 등급), '고유 아이디'(레코드를 구별하는 숫자)로 구성된다고 가정한다.
이러한 데이터 표현 방식은 플랫 파일 데이터베이스에서 자주 사용된다.
몇 가지 추가적인 고려 사항은 다음과 같다.
- '''데이터 형(Data Types영어):''' 테이블의 각 열은 특정 데이터 형으로 제한되는 것이 일반적이다. 이러한 제한은 주로 관례에 따르며, 관계형 데이터베이스로 데이터를 변환하기 전까지는 공식적으로 규정되지 않는 경우가 많다.
- '''분리된 열:''' 위의 예시에서는 각 열이 공백 문자로 구분되어 있다. 이는 들여쓰기 또는 “고정 길이” 데이터 형식 지정이라고도 한다. 다른 방식으로는 구분자 문자를 사용하는 것이 있다. (예: 쉼표-분리 값, 구분자-분리 값, 마크업 언어, 프로그래밍 언어)
- '''관계 대수:''' 예시의 각 레코드(행)은 관계 대수에서 정의하는 튜플의 정의에 부합한다. (위 예시는 3-튜플 한 벌을 표현한다.) 첫 번째 행은 각 행의 값과 관련된 필드 이름을 정의한다.
- '''데이터베이스 매니지먼트 시스템:''' 텍스트 파일에 대한 조작은 여러 면에서 제한적이기 때문에, 데이터는 데이터베이스 관리 시스템으로 이동하기 전에 중간 표현 형태로 바뀌는 경우가 많다.
3. 2. 데이터 형식
플랫 파일에서 데이터 형식은 일반적으로 각 필드(열)가 특정 데이터 형식을 갖도록 제한된다. 이러한 제한은 보통 관례에 따르지만, 관계형 데이터베이스로 데이터를 변환하기 전까지는 명시적으로 지정되지 않는 경우가 많다.[5]각 열은 공백 문자, 탭, 쉼표 등 지정된 구분 문자로 구분되거나, 고정 너비를 갖도록 공백 채워넣기(padding영어)를 통해 만들어진다. 구분자 문자를 사용하는 경우, 실제 데이터에 구분자가 포함되어 '구분자 충돌'이 발생하지 않도록 추가적인 형식 지정(포맷팅)이 필요하다.[5]
다음은 플랫 파일 데이터베이스의 예시이다.
아이디 (id) | 이름 (name) | 등급 (team) |
---|---|---|
1 | 철수 | 관리자 |
2 | 영희 | 관리자 |
3 | 찬희 | 일반사용자 |
4 | 길동 | 일반사용자 |
5 | 홍련 | 일반사용자 |
6 | 민희 | 관리자 |
7 | 길수 | 일반사용자 |
8 | 형구 | 일반사용자 |
위 예시에서 각 열은 공백 문자로 구분되어 있으며, '아이디'는 숫자, '이름'은 문자열, '등급'은 특정 문자열(관리자, 일반사용자)로 제한되는 데이터 형식을 갖는다.
3. 3. 구분자
플랫 파일에서 각 필드를 구분하는 방법에는 여러 가지가 있다. 일반적으로 공백, 탭, 쉼표 등과 같이 지정된 문자를 사용하거나, 각 필드의 고정 너비를 지정하여 공간 채워넣기(padding영어)를 통해 구분한다.[5]구분자를 사용하는 경우, 실제 데이터에 구분자가 포함되어 '구분자 충돌'이 발생하지 않도록 추가적인 형식 지정(포맷팅)이 필요하다.
일반적인 구분자로는 CSV(쉼표로 구분,
,
), TSV(탭 문자로 구분), 공백, 수직 막대(|
) 등이 있다.[5]구분자가 필드 내에서 허용되는 경우, 리터럴로 표시하려는 구분자 문자와 실제 구분자를 구별하는 방법이 필요하다. 예를 들어, "If I have to, I'll do it myself."라는 문장을 CSV로 인코딩하려면 쉼표가 필드를 분할하지 않도록 해야 한다. 이러한 구분자 충돌을 방지하기 위한 여러 전략이 존재한다.
고정 필드 길이가 아닌 경우, 구분자를 만날 때까지 한 글자씩 조사해야 하므로 약간의 오버헤드가 발생한다. 하지만 쉼표를 대표로 하는 구분자를 사용하면 데이터량을 줄일 수 있으며(불필요한 공백이 없기 때문에) 데이터 전송 목적에 중요했다. 고정 필드 길이에 구분 문자를 병용하는 경우는 드물지만, 필드를 빠르게 잘라낼 수 있다는 장점이 있다.[5]
3. 4. 고정 폭 형식
고정 폭 형식은 각 열의 길이가 고정되어 있으며, 필요한 경우 공백으로 필드를 채우는 방식이다.[5] 고정 길이는 미리 정의되어 알려져 있거나, 헤더에서 구문 분석될 수 있다.미리 정의된 길이를 사용하면 필드의 최대 길이가 제한된다. 형식이 정의된 후 더 긴 필드가 필요할 수 있는데, 이에 대한 해결 방법으로는 구문 축약, 값을 링크(예: 값에 대한 URI)로 바꾸기, 파일을 여러 파일로 분할하기 등이 있다.
구분 기호로 분리된 형식에서는 필드 경계를 결정하기 위해 구분 기호를 찾아야 하므로 약간의 오버헤드가 발생한다. 고정 폭 형식에서는 이것이 필요하지 않다. 그러나 고정 폭 형식은 필드가 예약된 길이보다 짧은 경향이 있을 때 파일 크기가 불필요하게 커질 수 있다는 단점이 있다.
4. 장단점
플랫 파일 데이터베이스는 구조가 단순하여 구현 및 사용이 쉽지만, 데이터 중복, 무결성 문제, 동시 접근의 어려움, 보안 취약성, 복잡한 질의 처리의 어려움 등 여러 단점을 가진다.
Berkeley DB는 플랫 파일 데이터베이스이면서 ACID 트랜잭션을 지원하는 데이터베이스이다.[1]
플랫 파일 데이터베이스의 예시는 다음과 같다.
- Berkeley DB[1]
- Borland Reflex
- [http://sourceforge.net/projects/textdb TextDB]
- [http://mimesis.110mb.com Mimesis]
- [http://dev.mysql.com/tech-resources/articles/csv-storage-engine.html MySQL CSV]
4. 1. 장점
다음은 플랫 파일 데이터베이스의 장점을 보여주는 예시이다.- Berkeley DB
- Borland Reflex
- [http://sourceforge.net/projects/textdb TextDB]
- [http://mimesis.110mb.com Mimesis]
- [http://dev.mysql.com/tech-resources/articles/csv-storage-engine.html MySQL CSV]
4. 2. 단점
플랫 파일 데이터베이스는 구조가 단순하여 사용하기 쉽지만, 다음과 같은 단점들이 존재한다.- 데이터 중복: 여러 파일에 동일한 정보가 중복 저장될 수 있어 저장 공간이 낭비되고 데이터 불일치 문제가 발생할 수 있다.
- 데이터 무결성 문제: 데이터 중복으로 인해 데이터 수정 시 일부만 반영되어 데이터의 정확성과 일관성이 손상될 수 있다.
- 동시 접근 어려움: 여러 사용자가 동시에 데이터베이스에 접근하여 수정할 경우 데이터 충돌 및 손실이 발생할 수 있다.
- 보안 취약: 데이터 암호화, 접근 제어 등의 보안 기능이 부족하여 데이터 유출 위험이 높다.
- 복잡한 질의 어려움: 데이터 간의 관계를 표현하기 어려워 복잡한 질의 처리가 어렵고, 데이터 검색 속도가 느릴 수 있다.
이러한 단점들 때문에 플랫 파일 데이터베이스는 소규모의 단순한 데이터를 관리하는 데는 적합하지만, 대규모의 복잡한 데이터를 관리하는 데는 적합하지 않다.
5. 활용 사례
플랫 파일 데이터베이스는 유닉스 계열 운영 체제의 /etc/passwd
, /etc/group
파일과 같이 주소록 등 다양한 분야에서 활용된다.[5] 사람이 직접 손으로 쓰거나, 타자기, 워드 프로세서로도 작성할 수 있다.
플랫 파일 데이터베이스를 활용하는 소프트웨어는 다음과 같다.[5]
- Berkeley DB - ACID 트랜잭션을 지원한다.
- Borland Reflex
- [http://sourceforge.net/projects/textdb TextDB]
- [http://mimesis.110mb.com Mimesis]
- [http://dev.mysql.com/tech-resources/articles/csv-storage-engine.html MySQL CSV] - MySQL 5.x 용 스토리지 엔진
5. 1. 설정 파일
오늘날에도 응용 프로그램은 설정 파일 등을 저장하기 위해 플랫 파일 데이터베이스를 널리 사용한다. 많은 응용 프로그램이 사용자 고유의 정보를 플랫 파일에서 가져올 수 있도록 미리 정의된 필드를 사용한 플랫 파일을 제공한다. 작은 크기의 도서 관리 프로그램, 일정 관리 프로그램, 특히 주소록 프로그램 등은 플랫 파일을 빈번히 이용하기도 한다. XML은 일반 텍스트 파일에 데이터를 저장할 때 쓰이는 매우 인기 있는 포맷이지만, XML에는 복잡하고도 많이 중첩된 데이터를 저장할 수 있기 때문에 XML을 플랫 파일 데이터베이스로 분류하는 것은 적절치 않다.[5]5. 2. 소규모 데이터 저장
최근에는 일반 사용자가 플랫 파일 데이터베이스를 쉽게 만들 수 있는 프로그램은 드물지만, 마이크로소프트 웍스(초창기 윈도 버전에만 존재), 애플웍스(클라리스웍스, 윈도 및 매킨토시 용) 등에서 플랫 파일 데이터베이스 기능을 제공했다.[5] 볼랜드의 파라독스, 마이크로소프트 액세스 등은 관계형 데이터베이스 기능과 내장 프로그래밍 언어를 제공한다. MySQL이나 오라클 DBMS 같은 데이터베이스 관리 시스템(DBMS)은 프로그래머가 직접 응용 프로그램을 개발해야 한다.오늘날에도 응용 프로그램 설정 파일 저장 등에는 플랫 파일 데이터베이스가 널리 사용된다. 많은 응용 프로그램이 사용자 정보를 플랫 파일에서 가져오며, 소규모 도서/일정/주소록 관리 프로그램 등도 플랫 파일을 활용한다. XML은 일반 텍스트 파일에 데이터를 저장하는 인기 있는 형식이지만, 복잡한 데이터를 저장할 수 있어 플랫 파일 데이터베이스로 분류하기는 어렵다.[5]
5. 3. 데이터 교환
일반 텍스트 또는 텍스트와 이진 데이터의 혼합인 "플랫 파일"은, 일반적으로 한 행이 하나의 레코드가 된다.[5] 레코드 안에서 필드는 구분 문자(Delimiter)로 구분되는 구조를 가지는데, 예를 들어 쉼표로 구분하거나 고정된 문자 수로 구분한다. 후자의 경우, 규정된 길이를 채우기 위해 패딩이 필요하다. 일반적으로 구분 문자는 필드 내에서 사용할 수 없는 문자여야 한다. 필드 내에 구분 문자와 같은 문자가 있으면, 그곳을 구분 지점으로 잘못 해석하기 때문이다. 레코드 사이에는 구조적 관련성이 없다.플랫 파일의 전형적인 예로는 유닉스 계열 운영 체제의
/etc/passwd
와 /etc/group
이 있다. 예를 들어, 각 행에 이름, 주소, 전화번호를 순서대로 기술한 파일은 주소록의 플랫 파일이다.플랫 파일은 사람이 손으로 써서 종이에 작성할 수도 있으며, 이것도 일종의 플랫 파일 데이터베이스이다. 물론, 타자기나 워드 프로세서로도 작성할 수 있다.
6. 관계형 데이터베이스와의 비교
관계형 데이터베이스 모델은 여러 플랫 파일 테이블을 사용하며, 관계형 데이터베이스 매니지먼트 시스템이 이들 간의 외부 키 관계를 해석할 수 있어야 한다. 반면 플랫 파일 데이터베이스는 단일 테이블로 구성되어 필드나 레코드 간의 관계(링크)가 없는 형태이다.
엄밀한 의미에서 플랫 파일은 데이터 외에 레코드 길이나 구분자에 대한 정보를 포함하지 않는다. 그러나 넓은 의미로는 단일 파일로 구성된 데이터베이스로, 표 형식은 갖추지만 필드나 레코드 간 링크가 없는 것을 지칭한다.
다음은 플랫 파일 데이터베이스 예시이다.
'''첫 번째 파일'''
파일-오프셋 | 아이디 | 성명 | 등급 |
---|---|---|---|
0x00 | 8 | 형구 | 일반사용자 |
0x13 | 1 | 철수 | 관리자 |
0x27 | 3 | 찬희 | 일반사용자 |
0x3B | 4 | 길동 | 일반사용자 |
0x4F | 5 | 홍련 | 일반사용자 |
0x62 | 7 | 길수 | 일반사용자 |
0x76 | 6 | 민희 | 관리자 |
0x8A | 2 | 영희 | 관리자 |
'''파일 오프셋'''은 데이터베이스의 일부가 아니며, 관계 설명을 위해 존재한다.
'''두 번째 파일 '''
위 예시에서 볼 수 있듯이, 플랫 파일은 현대적인 관계형 데이터베이스의 데이터 저장소 역할을 할 수 있다. 관계형 데이터베이스 관리 시스템이 인덱스, 검색 제한, 트리거, 외부 키 관계 등의 기능을 플랫 파일에 담아 데이터베이스로 동작하게 할 수 있다.
데이터베이스 관련 용어는 구현에 따라 다르지만, 개념은 동일하다. 예를 들어 FileMaker의 'Find'는 MySQL의 'Query'와 같은 개념이며, FileMaker의 '파일'은 MySQL의 '표'와 같다. 그러나 '레코드'와 '필드'라는 기본 용어는 대부분의 플랫 파일 데이터베이스 구현에서 공통적으로 사용된다.
참조
[1]
웹사이트
Data Integration Glossary
http://knowledge.fhw[...]
U.S. Department of Transportation
2001-08-00
[2]
논문
cql: Flat-file database query language
http://static.usenix[...]
[3]
논문
Herman hollerith: data processing pioneer
https://onlinelibrar[...]
1969-00-00
[4]
웹사이트
Data Integration Glossary
http://knowledge.fhw[...]
U.S. Department of Transportation
2001-08-00
[5]
논문
cql: Flat file database query language
http://www.research.[...]
본 사이트는 AI가 위키백과와 뉴스 기사,정부 간행물,학술 논문등을 바탕으로 정보를 가공하여 제공하는 백과사전형 서비스입니다.
모든 문서는 AI에 의해 자동 생성되며, CC BY-SA 4.0 라이선스에 따라 이용할 수 있습니다.
하지만, 위키백과나 뉴스 기사 자체에 오류, 부정확한 정보, 또는 가짜 뉴스가 포함될 수 있으며, AI는 이러한 내용을 완벽하게 걸러내지 못할 수 있습니다.
따라서 제공되는 정보에 일부 오류나 편향이 있을 수 있으므로, 중요한 정보는 반드시 다른 출처를 통해 교차 검증하시기 바랍니다.
문의하기 : help@durumis.com