플랫 파일 데이터베이스

플랫 파일 데이터베이스

일반 텍스트 파일인가요, 바이너리 파일인가요, 아니면 문자 파일인가요? 플랫 파일이 실제로 무엇을 의미하는지 설명할 수 있는 사람이 있나요?

답변1

dirkt가 맥락을 묻는 것은 옳지만 플랫 파일이 데이터베이스가 아니거나 레코드를 포함한다고 말하는 것은 매우 잘못된 것입니다.

플랫 파일 데이터베이스

데이터베이스의 맥락에서,플랫 파일 데이터베이스다음 조건:

  • 파일에 하나의 테이블만 포함하는 데이터베이스입니다.
  • 이 테이블에는 인덱스가 없습니다.
  • 구조는 관계형, 계층형 또는 네트워크형이 아닙니다.
  • 파일에는 필드가 열 위치로 표시되는 고정 길이 레코드 또는 레코드와 필드가 구분 기호로 서로 구분되는 가변 길이 레코드가 포함될 수 있습니다.

이 문제를 논의할 때 문헌에 등장하는 BSAM(기본 순차 액세스 방법) 및 QSAM(대기열 순차 액세스 방법)이라는 용어를 접할 수 있습니다. 이는 사람들이 플랫 파일 데이터베이스에 액세스하는 방법과 관련이 있습니다. 이 개념에서는 레코드를 정렬하거나 키를 입력할 필요가 없으므로 선형적이고 순차적으로 읽고 써야 합니다.

삽입 및 삭제에는 전체 파일 처리가 포함됩니다. 테이프와 같은 순차 액세스를 용이하게 하는 미디어에 저장되던 플랫 파일 데이터베이스와 데이터베이스 업데이트는 때때로 입력 테이프 A와 B에서 읽어 출력 테이프 C에 병합하는 형태를 취했습니다. (예: A는 오늘 시작하는 마스터 파일, B는 오늘의 트랜잭션, C는 내일 실행되는 마스터 파일일 수 있습니다.)

일상적인 플랫 파일 데이터베이스

이런 일이 다시는 발생하지 않을 것이라고 생각할 수도 있고, 적어도 Unix 및 Linux에서는 발생하지 않을 것이라고 생각할 수도 있습니다. 당신도 틀렸어요. 다음은 접할 수 있는 몇 가지 플랫 파일 데이터베이스입니다.일일:

  • Linux의 사용자 계정 데이터베이스는 플랫 파일 모음입니다.
    • 버전 7 /etc/passwd파일은 가변 길이 레코드, 필드 구분자로 콜론 문자, 레코드 구분자로 개행 문자를 포함하는 단일 테이블입니다.
    • /etc/group, /etc/shadow, 에도 마찬가지입니다 /etc/gshadow.
  • 파일 /etc/fstab은 가변 길이 레코드, 필드 구분자로 개행이 아닌 공백 문자, 레코드 구분자로 개행 문자가 포함된 단일 테이블입니다. 파일 시스템테이블- 이름에 딱 들어있어요.
    • /etc/services,,,, 및도 마찬가지입니다.​​/etc/crontab/etc/phones/etc/ttys/etc/hosts/etc/protocols
  • 로그인 데이터베이스(Linux /run/utmp; , , FreeBSD 등)는 고정 길이 레코드가 있고 필드 또는 레코드 구분 기호가 없으며 필드가 열 위치로 표시되는 플랫 파일 데이터베이스입니다./var/log/wtmp/run/utx.active/var/log/utx.lastlogin/var/log/utx.log

위에서 설명한 가변 길이 레코드 데이터베이스에서 레코드 삽입 및 삭제를 수행하기 위해 전체 파일을 읽은 다음 전체 파일을 다시 작성하지 않을 것이라고 생각할 수도 있습니다. 커서를 이동하고 줄 삭제 및 삽입을 수행합니다. 하지만 당신은 텍스트 편집기가 제공하는 파일 I/O 전체를 무시하고 있습니다.그 자체실제로 그럴 때파일 로드 및 저장. 파일 자체에 대한 실제 접근 방식은 플랫 파일 데이터베이스 방식이다.

플랫 파일이 아닌 일상적인 데이터베이스

이러한 플랫 파일 데이터베이스는 순차 액세스 이외의 다른 것을 원할 때 성능이 저하되는 플랫 파일 데이터베이스의 예입니다. 호스트 /etc/hosts또는 사용자 계정을 찾는 작업에는 /etc/passwd파일을 순차적으로 읽는 작업이 포함됩니다. 색인이 없으며 항목이 검색에 사용된 키 순서대로 정렬되지 않습니다. 이러한 플랫 파일 데이터베이스(예 gethostent(): getpwent(), getfsent(), , getgrent()getutxent())를 검색하기 위한 C 라이브러리 루틴을 살펴보면 나중에 다루게 될 예외를 제외하고 순차적 액세스 방법을 볼 수 있습니다. (다양한 getXbyY()루틴이 이러한 루틴 위에 구축됩니다. 일치하는 항목이 발견될 때까지 순차 액세스 루틴을 호출하기만 한다는 것을 알 수 있습니다.)

따라서 BSD에서 실제 사용자 계정 데이터베이스는 다음과 같습니다.아니요플랫 파일 데이터베이스. UID와 사용자 이름으로 색인이 생성된 Berkeley DB 파일입니다. .NET 파일 /etc/master.passwd에 저장된 플랫 파일 데이터베이스의 프로그램에 의해 컴파일됩니다 pwd_mkdb. C 라이브러리는 실제로 /etc/pwd.db또는 (가능한 경우)를 읽습니다 /etc/spwd.db.

BSD "기능 데이터베이스" 소스 파일 구조(예 /etc/gettytab: /etc/login.conf, , 및 /etc/termcap)는 진정한 플랫 파일이 아닙니다. ( /etc/login.conf.db컴파일된 파일 구조는 및 에 있지만 /etc/termcap.db절대 그렇지 않습니다.) 레코드는 참조로 다른 레코드를 포함할 수 있으며, 주어진 레코드의 모든 필드를 찾기 위해 따라야 하는 체인을 형성합니다. 실제로 컴파일러는 cap_mkdb바로 그런 일을 합니다.

플랫 파일은 "ASCII 텍스트"가 아닙니다.

ASCII는 파일, 그룹, 레코드 및 단위(예: 필드) 구분 기호에 대한 특정 제어 문자를 정의합니다. Unices 및 Linux에서는 주로 사용되지 않으며 대신 공백 TAB, LF콜론과 같은 문자를 사용합니다 .

사람들은 때때로 "플랫 파일 데이터베이스에는 간단한 ASCII 텍스트가 포함되어 있습니다"라고 말합니다. 위의 예 중 일부를 보면 이것이 사실이 아님이 분명합니다. 이는 특정한 일반적인 유형의 가변 길이 레코드 플랫 파일 데이터베이스의 경우에만 해당됩니다. 그러나 Unix나 Linux 시스템에서도 널리 사용되는 로그인 데이터베이스도 플랫 파일 데이터베이스이지만, 그 안의 다양한 필드는 확실히 플랫 파일 데이터베이스입니다.아니요ASCII 문자 인코딩으로 해석됩니다.

(더 넓은 세상을 바라보며 Unix/Linux 터널 비전 너머를 볼 때: 이것은 dbfxBase가 ASCII로 인코딩된 필드 내용을 파일에 저장한다는 사실에서 비롯된 오해입니다. 사람들은 xBase에 대해 이야기하곤 했습니다. 세계에서 가장 인기 있는 데이터베이스 시스템은 "플랫 파일" 시스템이지만 실제로는 "관계형" 또는 "객체 지향"이라는 용어를 사용했으며 사람들이 "레거시"를 오용한 것과 같은 방식으로 "오래된" 시스템입니다. 플랫 파일" 시스템은 "ASCII를 사용"하지만 dbf파일에는 실제로 많은 내용이 있습니다.아니요ASCII 문자 인코딩으로 해석됩니다. )

추가 읽기

  • Burleson, 도널드 K. (1998).데이터베이스 개체 모델 내부. CRC 프레스. ISBN 9780849318078.
  • 매티슨, 롭(1998).데이터베이스 관리 시스템에 대해 알아보기. 맥그로힐. ISBN 9780070499997.

답변2

Unix용 POSIX 표준에는 다음과 같은 언급을 제외하면 "플랫 파일"이라는 것이 없습니다.

시스템 메일함의 형식은 의도적으로 지정되지 않았습니다. 모든 시스템이 시스템 사서함을 플랫 파일로 구현하는 것은 아니며 특히 멀티미디어 메일 메시지의 출현으로 인해 더욱 그렇습니다. 일부 시스템 사서함은 여러 파일로 구성될 수 있지만 다른 시스템 사서함은 데이터베이스에 기록됩니다.

내 직업(생물정보학)에서 "플랫 파일"은대개일반적으로 Fasta 형식(또는 파생 형식 중 하나)의 게놈 데이터인 데이터가 포함된 일반 텍스트 ASCII 파일입니다.

이는 데이터베이스나 비ASCII 파일(예: BAM 또는 CRAM 형식 파일)에 저장된 데이터와 대조됩니다. 그러나 비ASCII 파일을 일부에서는 "플랫 파일"이라고도 합니다.

@ikkachu가 언급한 "플랫 파일"에 대한 Wikipedia 정의는 게놈 데이터의 크기가 크기 때문에 여기서는 완전히 적절하지 않습니다. 플랫 파일에서 RAM으로 종의 전체 DNA 서열을 읽는 것은 느리고 불필요하며 대부분의 경우 불가능합니다.

생물정보학자들은 "플랫 파일"이라는 용어를 느슨하게 사용하는 것 같습니다.어느GTF/GFF 및 GeneBank 파일의 경우와 같이 레코드가 파일 내에 참조를 포함할 수 있는 방식으로 데이터 파일이 구성되어 있더라도 그들이 사용하는 데이터 파일의 유형.

아마도 "플랫 파일"의 가장 일반적인 정의는 다음과 같습니다.데이터를 변경해야 하는 경우 전체 파일을 다시 작성해야 하는 데이터가 포함된 파일. 나는 이것이 일부 바이너리 형식에도 적용된다고 생각합니다.

답변3

아마도 이에 대한 좋은 대답은 없을 것이고, 그 용어가 정확한 의미를 갖고 있는지 의심스럽습니다.

일반적으로 이는 약간의 구조를 가지며 그 자체로 유용한 것을 의미하지만(필수 인덱스가 없는 등), 여기서부터 정의가 갈라지기 시작합니다.

FOLDOC 정의분명히 바이너리 데이터와 반대되는 (ASCII) 텍스트를 포함하는 플랫 파일입니다. (소스 없음)위키피디아의 정의해당 부분만 수정하면 업데이트가 되는 것보다는 "전체적으로 메모리에서 읽고 써야 하는 것"으로 보입니다. 행의 길이는 다양하고 연속적으로 저장되므로 일반적인 텍스트 파일은 이 정의에 적합합니다. 따라서 대부분의 변경 사항으로 인해 후속 파일의 위치가 변경됩니다.

나에게는 데이터베이스의 텍스트 덤프가 "플랫 파일"로 간주되지만 바이너리 파일에 대해서는 잘 모르겠습니다. YMMV.

답변4

연합 데이터베이스 기술 - 데이터 저장을 위한 플랫 파일, 프로그램 해시 테이블에 바인딩된 키/값 쌍의 Perl SDBM 파일과 함께 작동하여 고정 길이 레코드 오프셋(바이트)의 지속적인 무작위화를 위해 액세스 인덱스. 이것은 ISAM/NoSql 데이터베이스 시스템 구현입니다. 바라보다: http://www.perlmonks.org/?node_id=1121222

고정 길이 레코드에 "텍스트" 데이터를 저장하는 플랫 파일 데이터베이스는 프로그램 해시 테이블과 연결된 키/값 쌍의 SDBM 바이너리를 사용하여 즉각적인 무작위 액세스를 위해 설정할 수 있습니다. 여기서 "값"은 레코드 오프셋(바이트 단위)입니다. ) 키가 단일 필드, 부분 필드 또는 플랫 파일 레코드에 포함된 데이터에 함께 연결된 여러 단일 및/또는 부분 필드인 파일 포인터를 찾습니다.

주민등록번호, 대출 번호 또는 계좌 번호는 고유 키로 사용할 수 있는 필드의 예입니다.

플랫 파일에 대해 SDBM 파일의 여러 인덱스를 설정할 수 있습니다. 각 SDBM 파일에는 "키"를 구성하는 필드 또는 필드의 일부를 기반으로 하는 서로 다른 키/값 쌍 세트가 포함되어 있습니다. DUPLICATES가 있는 대체 인덱스는 "키"에 nbr 시퀀스를 추가하여 사용할 수 있습니다.

별도의 플랫 파일을 사용하여 다른 플랫 파일에 저장된 각 단일 상위 레코드와 관련된 여러 하위 레코드를 저장할 수 있습니다. 예: 대출 플랫 파일(상위) 및 담보 플랫 파일(하위), 여기서 하위는 모두 각 특정 할부 대출에 대한 담보입니다.

저는 각각 4GIG의 FLAT 파일을 사용하고 각각 2GIG의 SDBM 파일을 사용합니다.

쉽게 무작위 및 순차적 액세스를 위해 데이터를 논리적으로 격리할 수 있습니다. 예: US_Census_2010_TX_A.dat는 성이 문자 "A"로 시작하는 텍사스 시민에 대한 데이터만 포함하는 플랫 파일일 수 있습니다. 각각 26개의 플랫 파일(AZ용 1개)을 포함하는 50개의 STATE 하위 디렉터리를 가질 수 있습니다. 배치 애플리케이션 또는 사용자 인터페이스는 플랫 파일 및 SDBM 파일 명명 규칙을 이해하여 올바른 파일에 액세스할 수 있습니다.

참고: 유사한 기술을 사용하여 ODBC를 통해 액세스되는 거대한 MS-ACCESS(실제로는 MS-Jet "Red" 엔진) 데이터베이스를 구축할 수 있습니다. 따라서 각 *.MDB 파일에는 하나 이상의 백엔드 테이블 개체만 포함되고 각 MDB는 파일은 모든 MDB 파일에 공통되는 단일 테이블, 테이블 그룹 또는 부분 테이블 역할을 합니다. MDB 파일 자체는 데이터베이스가 아닙니다. 이는 일반적입니다. 이는 순차 및 무작위 액세스를 최적화하기 위해 논리적으로 격리되고 인덱싱된 대량의 데이터를 저장하는 단순한 컨테이너입니다. MS-Access에는 자체 인덱싱 기능이 있으므로 여기서는 SDBM을 인덱싱에 사용하지 않습니다. MDAC 및 ODBC 관리자 유틸리티는 Windows 7에 기본적으로 설치되어 있으므로 MS-Access 소프트웨어는 필요하지 않습니다. ODBC 관리자를 사용하여 빈 MDB 파일을 만들고 프로그래밍 언어를 사용하여 SQL 문을 실행하여 해당 테이블에 대한 테이블과 인덱스를 만듭니다.

관련 정보