레코드(컴퓨터 사이언스)

Record (computer science)

컴퓨터 과학에서 레코드(구조, 구조 또는 복합 데이터라고도 함)는 기본적인 데이터 구조입니다.데이터베이스 또는 스프레드시트의 레코드는 일반적으로 "행"[1][2][3][4]이라고 합니다.

레코드는 여러 데이터 유형의 필드 집합으로, 일반적으로 고정된 수와 [5]시퀀스로 구성됩니다.레코드의 필드는 멤버라고도 불리며, 특히 객체 지향 프로그래밍에서 필드는 요소라고도 불리지만 컬렉션의 요소와 혼동될 위험이 있습니다.

예를 들어 날짜를 숫자를 포함하는 레코드로 저장할 수 있습니다.year필드, amonth문자열 및 숫자로 표시되는 필드day-of-month인사 기록에는 이 정보가 포함되어 있을 수 있습니다name,asalary, 및 arankCircle 레코드에는 다음 항목이 포함될 수 있습니다.center및 aradius: 이 예에서는 센터 자체가,point포함하는 레코드x그리고.y좌표를 표시합니다.

레코드는 필드의 수가 레코드의 정의에 따라 결정되며 레코드가 이종 데이터 유형이라는 점에서 배열과 구별됩니다.모든 필드에 동일한 유형의 데이터가 포함되어 [6]있을 필요는 없습니다.

레코드 유형은 이러한 값과 변수를 설명하는 데이터 유형입니다.대부분의 현대 컴퓨터 언어는 프로그래머가 새로운 레코드 유형을 정의할 수 있도록 합니다.정의에는 각 필드의 데이터 유형과 해당 필드에 액세스할 수 있는 식별자(이름 또는 레이블) 지정이 포함됩니다.유형 이론에서는 일반적으로 제품 유형(필드 이름 없음)이 단순하기 때문에 선호되지만, 적절한 레코드 유형은 System F-sub과 같은 언어로 연구됩니다.유형 이론 레코드는 데이터 외에 1종류의 함수형 필드를 포함할 수 있기 때문에 객체 지향 프로그래밍의 많은 특징을 표현할 수 있습니다.

기록은 메인 메모리, 자기 테이프나 하드 디스크와 같은 대용량 저장 장치를 포함한 모든 저장 매체에 존재할 수 있습니다.레코드는 대부분의 데이터 구조, 특히 링크된 데이터 구조의 기본 구성요소입니다.대부분의 컴퓨터 파일은 논리 레코드의 배열로 구성되며, 효율성을 위해 종종 더 큰 물리적 레코드 또는 블록으로 그룹화됩니다.

함수 또는 프로시저의 파라미터는 대부분의 경우 레코드 변수의 필드로 볼 수 있습니다.또한 해당 함수에 전달되는 인수는 콜 시 해당 변수에 할당되는 레코드 값으로 볼 수 있습니다.또한 프로시저 콜의 실장에 자주 사용되는 콜스택에서는 각 엔트리는 프로시저 파라미터와 로컬 변수, 리턴 주소 및 기타 내부 필드를 포함하는 액티베이션레코드 또는 콜프레임입니다

오브젝트 지향 언어의 오브젝트는 기본적으로 그 레코드를 처리하기 위해 특화된 절차를 포함하는 레코드입니다.오브젝트 타입은 레코드 타입의 상세입니다.실제로, 대부분의 객체 지향 언어에서 레코드는 객체의 특수한 경우일 뿐이며, OO 기능을 사용하는 객체와 대조하기 위해 POD(Plain Old Data Structures)로 알려져 있습니다.

레코드는 수학적 태플의 컴퓨터 유사체로 볼 수 있지만, 규칙과 특정 프로그래밍 언어에 따라 태플이 레코드로 간주될 수도 있고 그렇지 않을 수도 있습니다.같은 맥락에서 레코드 타입은 2개 이상의 수학 집합의 데카르트 곱의 컴퓨터 언어 유사체 또는 특정 언어의 추상적 곱 유형의 구현으로 볼 수 있다.

열쇠들.

레코드에 0 이상의 키가 있을 수 있습니다.키는 레코드 내의 값 또는 값 세트에 식을 매핑합니다.프라이머리 키는 저장되어 있는 모든 레코드에서 고유한 키입니다.이 키가 존재하는 경우는 [7]1개뿐입니다.즉, 어떤 프라이머리 키에도 중복이 존재하지 않을 수 있습니다.예를 들어 직원 파일에 직원 번호, 이름, 부서 및 급여가 포함될 수 있습니다.사원번호는 조직 내에서 고유하며 주요 키가 됩니다.저장 매체 및 파일 조직에 따라 직원 번호가 색인화될 수 있습니다. 또한 직원 번호는 더 빨리 조회할 수 있도록 별도의 파일에 저장됩니다.부문 코드는 반드시 고유할 필요는 없습니다.또, 색인화되어 있는 경우도 있습니다.이 경우, 세컨더리 키 또는 [8]대체 키로 간주됩니다.인덱스가 작성되지 않은 경우 특정 부서의 모든 직원 목록을 작성하기 위해 전체 직원 파일을 스캔해야 합니다.키는 보통 하나의 키에 의해 여러 값이 매핑될 가능성을 최소화하는 방식으로 선택됩니다.예를 들어, 급여 필드는 많은 직원이 동일한 급여를 받을 가능성이 높기 때문에 일반적으로 열쇠로 사용할 수 있는 것으로 간주되지 않습니다.인덱싱은 파일 설계 시 고려해야 할 요소 중 하나입니다.

역사

1880년 미국 인구 조사 저널 시트. 데이터 행과 함께 표 형식의 데이터를 보여주며, 각 데이터는 한 사람에 해당한다.

레코드의 개념은 먼 옛날부터 회계에 사용된 다양한 유형의 테이블과 장부까지 추적할 수 있습니다.잘 정의된 유형과 크기의 분야를 가진 컴퓨터 과학에서 기록에 대한 현대적 개념은 배비지의 분석 [9][10]엔진과 같은 19세기 기계 계산기에 이미 내포되어 있었다.

Hollerith 펀치 카드(1895)

데이터에 사용된 원래의 기계 판독 가능한 매체는 1890년 미국 인구 조사에서 기록에 사용된 펀치 카드였다. 각 펀치 카드는 단일 기록이었다.1880년의 저널 엔트리와 1895년의 펀치 카드를 비교해 보세요.기록은 대부분의 데이터 처리가 펀치 카드를 사용하여 이루어졌던 20세기 전반기에 잘 확립되었습니다.일반적으로 데이터 파일의 각 레코드는 하나의 펀치카드에 기록되며 특정 컬럼이 특정 필드에 할당됩니다.일반적으로 레코드는 외장 스토리지(예: 카드 리더, 테이프 또는 디스크)에서 읽을 수 있는 최소 단위입니다.펀치카드 형식의 레코드의 내용은 원래 "유닛 레코드"라고 불렸는데, 펀치카드가 문서 [11]길이를 미리 결정했기 때문입니다.하드 드라이브와 자기 테이프의 사용으로 스토리지 시스템이 더욱 발전하면서 가변 길이 레코드가 표준이 되었습니다.가변 길이 레코드는 레코드 크기(바이트)가 필드 크기 합계와 거의 동일한 레코드입니다.더 고급 스토리지 하드웨어가 발명되기 전에는 이 작업을 수행할 수 없었습니다. 왜냐하면 모든 펀치 카드는 컴퓨터가 읽을 수 있는 미리 정해진 문서 길이를 준수해야 했기 때문입니다. 당시에는 카드를 기계에 물리적으로 공급해야 했기 때문입니다.

대부분의 기계어 구현과 초기 어셈블리 언어에는 레코드에 대한 특별한 구문이 없었지만, 이 개념은 인덱스 레지스터, 간접 주소 지정 및 자체 수정 코드를 사용하여 사용 가능(그리고 광범위하게 사용됨)했습니다.IBM 1620과 같은 일부 초기 컴퓨터에는 레코드와 필드를 구분하는 하드웨어 지원과 이러한 레코드를 복사하는 특별 지침이 있었습니다.

레코드 및 필드의 개념은 IBM의 RPG(Report Program Generator)와 같은 일부 초기 파일 정렬 및 표 작성 유틸리티에서 중심이었습니다.

COBOL은 레코드 [12]유형을 지원하는 최초의 광범위한 프로그래밍 언어였으며, 그 당시 레코드 정의 기능은 상당히 정교했다.이 언어에서는 임의의 크기와 정밀도의 영숫자, 정수 및 소수 필드를 사용하여 중첩된 레코드를 정의할 수 있으며, 여기에 할당된 값(통화 기호, 소수점 및 숫자 그룹 구분 기호 삽입 등)의 형식을 자동으로 지정하는 필드도 사용할 수 있습니다.각 파일은 데이터를 읽거나 쓰는 레코드 변수와 관련지어집니다.COBOL은 또한MOVE CORRESPONDING이름에 따라 두 레코드의 해당 필드를 할당하는 문.

FORTRAN(포트란 IV까지)과 Algol 60과 같은 수치 컴퓨팅을 위해 개발된 초기 언어들은 레코드 유형을 지원하지 않았지만, FORTRAN 77과 Algol 68과 같은 이후 버전의 언어들은 레코드 유형을 추가했다.원래의 리스프 프로그래밍 언어 역시 레코드가 부족했지만(내장된 consell을 제외), 그 S-표현은 적절한 대용품을 제공했다.파스칼 프로그래밍 언어는 레코드 타입을 다른 기본 타입과 논리적으로 일관된 타입 시스템으로 완전히 통합한 최초의 언어 중 하나였다.COBOL 형식의 레코드에 제공되는 PL/I 프로그래밍 언어.C 프로그래밍 언어는 처음에 레코드 개념을 템플릿의 일종으로 제공했습니다.struct실제 레코드 데이터 타입이 아닌 메모리 영역 위에 배치할 수 있습니다.후자는 최종적으로 (에 의해) 제공되었습니다.typedef선언)하지만 두 가지 개념은 언어에서 여전히 구별됩니다.Pascal 이후에 설계된 대부분의 언어(예: Ada, Modula, Java)도 레코드를 지원합니다.

레코드는 더 이상 원래 컨텍스트에서 자주 사용되지 않지만(즉, 데이터를 포함하는 목적으로만 사용됨), 레코드는 새로운 객체 지향 프로그래밍 언어 및 관계형 데이터베이스 관리 시스템에 영향을 미쳤다.레코드는 데이터 저장 및 처리 방식에 더 많은 모듈성을 제공하므로 기본적으로 언어로 제공되는 원시 데이터 유형보다 복잡하고 실제적인 개념을 표현하는 데 더 적합합니다.이는 프로그래머의 [13]동일한 모듈러성 문제를 다루는 C++, Python, JavaScript, Objective-C와 같은 이후 언어에 영향을 미쳤다.이들 언어의 오브젝트는 기본적으로 메서드와 상속이 추가된 레코드이며, 이를 통해 프로그래머는 레코드의 내용뿐만 아니라 데이터의 동작 방식을 조작할 수 있습니다.객체 지향 언어가 레코드의 기능을 훨씬 능가하는 기능을 가지고 있기 때문에 많은 프로그래머들은 레코드가 쓸모없다고 생각한다.반면에, 많은 프로그래머들은 낮은 오버헤드와 어셈블리 언어로 레코드를 사용하는 능력은 낮은 수준의 추상화로 프로그래밍할 때 여전히 레코드를 관련 있게 만든다고 주장한다. 오늘날, 프로그래밍 언어의 인기 지표인 TIOBE 지수에서 가장 인기 있는 언어들은 어떤 식으로든 레코드에 의해 영향을 받았다.e는 객체 [14]지향이라는 사실에 대한 것입니다.SQL이나 오브젝트 쿼리 언어 등의 쿼리 언어도 레코드의 개념에 영향을 받았습니다.이러한 언어에 의해 프로그래머는 기본적으로 레코드인 데이터 세트를 [15]테이블에 저장할 수 있습니다.그런 다음 기본 키를 사용하여 이 데이터를 검색할 수 있습니다.테이블 자체도 외부 키(다른 테이블의 데이터를 참조하는 키)를 가질 수 있는 레코드입니다.

운용

  • 각 필드의 위치, 유형 및 (가능성이 있는) 이름을 포함한 새로운 레코드 유형의 선언
  • 특정 레코드 유형을 갖는 변수 및 값의 선언
  • 지정된 필드 값 및 (때로는) 지정된 필드 이름으로 레코드 값 구성
  • 명시적 이름의 기록 필드 선택
  • 레코드 변수에 대한 레코드 값 할당
  • 평등에 대한 두 기록의 비교
  • 레코드의 표준 해시 값 계산.

레코드 값에서 필드를 선택하면 값이 생성됩니다.

일부 언어에서는 레코드의 모든 필드 또는 적어도 참조 필드만 열거하는 기능을 제공할 수 있습니다.이 기능은 디버거, 가비지 컬렉터, 시리얼화 등의 특정 서비스를 구현하기 위해 필요합니다.그것은 어느 정도의 다형성을 필요로 한다.

레코드 서브타이핑이 있는 시스템에서는 레코드 타입의 값에 대한 조작도 포함됩니다.

  • 레코드에 새 필드 추가, 새 필드 값 설정.
  • 레코드에서 필드 삭제.

이러한 설정에서 특정 레코드 유형은 특정 필드 세트가 있음을 의미하지만 해당 유형의 값에는 추가 필드가 포함될 수 있습니다.따라서 필드가 x, y 및 z인 레코드는 필드가 x, y, r인 레코드와 마찬가지로 필드가 x 및 y인 레코드 유형에 속합니다.그 이유는 (x,y,z) 레코드를 인수로 예상하는 함수에 전달하면 해당 함수가 레코드 내에서 필요한 모든 필드를 찾을 수 있기 때문입니다.실제로 프로그래밍 언어로 레코드를 구현하는 많은 방법들이 이러한 가변성을 허용하는 데 어려움을 겪지만, 문제는 보다 이론적인 맥락에서 레코드 유형의 핵심 특성입니다.

할당 및 비교

대부분의 언어에서는 레코드 유형이 완전히 동일한 레코드 간에 할당할 수 있습니다(같은 필드 유형과 이름을 같은 순서로 포함).단, 언어에 따라서는 필드가 완전히 같은 경우에도 별도로 정의된2개의 레코드 데이터 타입이 다른 타입으로 간주될 수 있습니다.

일부 언어에서는 필드 이름이 다른 레코드 간에 각 필드 값을 레코드 내의 위치에 따라 대응하는 필드 변수와 일치시켜 할당할 수도 있습니다.예를 들어 다음과 같이 필드가 다음과 같은 복소수입니다.real그리고.imag필드를 사용하여 2D 포인트 레코드 변수에 할당할 수 있습니다.X그리고.Y이 대체 방법에서는 두 오퍼랜드가 동일한 필드 유형의 시퀀스를 가져야 합니다.일부 언어에서는 레코드 전체를 해석되지 않은 비트 문자열로 할당할 수 있도록 대응하는 타입의 크기와 부호화도 동일하게 해야 할 수도 있습니다.다른 언어에서는 이 점에서 유연성이 높아 각 값 필드를 대응하는 변수 필드에 합법적으로 할당해야 합니다.예를 들어 짧은 정수 필드를 긴 정수 필드에 할당하거나 그 반대일 수 있습니다.

다른 언어(COBOL 등)는 위치가 아닌 이름으로 필드 및 값을 일치시킬 수 있습니다.

이러한 가능성은 동등성에 대한 두 기록 값의 비교에도 적용된다.일부 언어에서는 개별 [citation needed]필드 비교에 기초한 사전 정렬 순서를 사용하여 순서 비교('및 '>')를 할 수도 있습니다.

PL/I는 위의 두 가지 유형의 할당을 모두 허용하며 다음과 같은 구조 표현도 허용합니다.a = a+1;여기서 "a"는 PL/I 용어로 기록 또는 구조이다.

알골 68의 분포장 선택

알골 68에서는Pts레코드의 배열로, 각각 정수 필드가 있습니다.X그리고.Y글을 쓸 수 있다Y of Pts정수의 배열을 구하다Y모든 요소의 분야Pts그 결과, 진술은Y of Pts[3] := 7그리고.(Y of Pts)[3] := 7같은 효과가 있습니다.

Pascal의 "with" 스테이트먼트

파스칼 프로그래밍 언어에서 명령어는with R do S명령어 시퀀스를 실행하다S기록의 모든 분야처럼R변수로 선언되었습니다.C#과 같은 객체 지향 언어로 다른 네임스페이스를 입력하는 것과 마찬가지로 레코드 이름을 필드에 액세스하기 위한 접두사로 사용할 필요가 없어졌습니다.그래서 글을 쓰는 대신Pt.X := 5; Pt.Y := Pt.X + 3쓸 수 있다with Pt do begin X := 5; Y := X + 3 end.

메모리에서의 표현

메모리 내 레코드의 표현은 프로그래밍 언어에 따라 달라집니다.일반적으로 필드는 레코드 유형으로 선언된 순서와 동일한 순서로 메모리의 연속된 위치에 저장됩니다.이로 인해 두 개 이상의 필드가 동일한 메모리 워드에 저장될 수 있습니다.실제로 이 기능은 워드의 특정 비트에 액세스하기 위한 시스템 프로그래밍에서 자주 사용됩니다.한편, 대부분의 컴파일러는 기계에 의해 부과되는 정렬 제약(예를 들어 부동소수점 필드가 하나의 단어를 차지해야 한다)을 준수하기 위해 대부분 프로그래머에게는 보이지 않는 패딩 필드를 추가합니다.

일부 언어에서는 필드(및 이름이나 유형)를 가리키는 주소 배열로 레코드를 구현할 수 있습니다.객체 지향 언어의 객체는 특히 여러 클래스를 상속할 수 있는 언어에서 상당히 복잡한 방식으로 구현되는 경우가 많습니다.

자기 정의 레코드

자기 정의 레코드는 레코드 유형을 식별하고 레코드 내의 정보를 찾기 위한 정보를 포함하는 레코드 유형입니다.요소의 오프셋을 포함할 수 있으므로 요소를 임의의 순서로 저장하거나 [16]생략할 수 있습니다.자기 정의 레코드에 저장된 정보는 레코드의 메타데이터로 해석할 수 있습니다.이것은, 레코드의 작성 시간이나, 바이트 단위의 레코드의 사이즈등의 정보를 포함한, 파일에 관한 UNIX 메타데이터에 있는 것과 비슷합니다.또는 요소 식별자를 포함한 레코드의 다양한 요소가 임의의 순서로 단순히 서로 추종할 수 있다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Computer Science Dictionary Definitions". Computing Students. Retrieved Jan 22, 2018.
  2. ^ Radványi, Tibor (2014). Database Management Systems. Eszterházy Károly College. p. 19. Archived from the original on 2018-09-23. Retrieved 23 September 2018.
  3. ^ Kahate, Atul (2006). Introduction to Database Management Systems. Pearson. p. 3. ISBN 978-81-317-0078-5. Retrieved 23 September 2018.
  4. ^ Connolly, Thomas (2004). Database Solutions: A Step by Step Guide to Building Databases (2nd ed.). Pearson. p. 7. ISBN 978-0-321-17350-8.
  5. ^ Felleisen, Matthias (2001). How To Design Programs. MIT Press. pp. 53, 60. ISBN 978-0262062183.
  6. ^ Pape, Tobias; Kirilichev, Vasily; Bolz, Carl Friedrich; Hirschfeld, Robert (2017-01-13). "Record data structures in racket: usage analysis and optimization". ACM SIGAPP Applied Computing Review. 16 (4): 25–37. doi:10.1145/3040575.3040578. ISSN 1559-6915. S2CID 14306162.
  7. ^ "Add or change a table's primary key in Access". support.microsoft.com. Retrieved 2022-03-01.
  8. ^ "Alternate key - Oracle FAQ". www.orafaq.com. Retrieved 2022-03-01.
  9. ^ Bromley, Allan (October 1998). "Charles Babbage's Analytical Engine, 1838". IEEE Annals of the History of Computing. 20 (4): 29–45. doi:10.1109/85.728228. S2CID 2285332. Retrieved 23 September 2018.
  10. ^ Swade, Doron. "Automatic Computation: Charles Babbage and Computational Method". The Rutherford Journal. The Rutherford Journal. Retrieved 23 September 2018.
  11. ^ Edwin D. Reilly; Anthony Ralston; David Hemmendinger, eds. (2003). Encyclopedia of computer science (4th ed.). Chichester, UK: Wiley. ISBN 978-1-84972-160-8. OCLC 436846454.
  12. ^ Sebesta, Robert W. (1996). Concepts of Programming Languages (Third ed.). Addison-Wesley Publishing Company, Inc. p. 218. ISBN 0-8053-7133-8.
  13. ^ Leavens, Gary T.; Weihl, William E. (1990). "Reasoning about object-oriented programs that use subtypes". Proceedings of the European Conference on Object-oriented Programming on Object-oriented Programming Systems, Languages, and Applications - OOPSLA/ECOOP '90. New York, New York, USA: ACM Press: 212–223. doi:10.1145/97945.97970. ISBN 0-201-52430-9. S2CID 46526.
  14. ^ "index TIOBE - The Software Quality Company". www.tiobe.com. Retrieved 2022-03-01.
  15. ^ "What is a Relational Database (RDBMS)?". Oracle. Retrieved February 28, 2022.
  16. ^ Kraimer, Martin R. "EPICS Input / Output Controller (IOC) Application Developer's Guide". Argonne National Laboratory. Retrieved November 25, 2015.