Что такое плоский файл

Иллюстрированный самоучитель по SQL для начинающих

Основы реляционных баз данных

Плоские файлы

Плоские файлы – самая простая разновидность структурированных данных. Нет, плоский файл – это не папка, придавленная стопкой книг. Плоские файлы называются так потому, что имеют минимальную структуру. Если бы они были зданиями, то их стены поднимались бы не от фундамента, а прямо от земли. Плоский файл – это собрание записей данных, записываемых в определенном формате одна за другой, – данные, одни только данные и ничего, кроме данных, т.е. список. На компьютерном языке плоский файл называется простым. В таком файле нет метаданных со структурной информацией, а есть лишь одни данные.

Скажем, вам нужно сохранить в системе плоских файлов имена и адреса клиентов вашей компании. У этой системы может быть примерно такая структура.

Как видите, в файле нет ничего, кроме данных. Каждое поле имеет фиксированную длину (например, длина поля имени всегда равна 15 символам), и в этой структуре поля не отделены друг от друга. Тот, кто создал базу данных, для каждого из полей назначил позицию и длину. Любая программа, которая использует этот файл, должна «знать», какие характеристики назначены каждому полю, потому что этой информации в самой базе данных нет.

Такая структура плоских файлов позволяет работать с ними очень быстро. Однако недостатком является то, что программная логика, которая предназначена для манипуляции данными из файлов, должна быть очень подробной. Приложение должно точно «знать», где и как в файле хранятся данные. Итак, что касается малых систем, то в них плоские файлы работают прекрасно. Но чем больше система плоских файлов, тем труднее с ней работать. Использование базы данных вместо системы плоских файлов позволяет этого избежать. Хотя файлы базы данных имеют больший «фундамент», приложения могут работать на большем количестве аппаратных платформ и операционных систем. Кроме того, базы данных позволяют легче писать прикладные программы, потому что программисту не нужно вникать в детали того, как в файлах физически расположены данные.

Базы данных облегчают работу программистов, потому что при работе с данными в детали «вникает» СУБД. А приложениям, написанным для работы с плоскими файлами, необходимо держать эти детали при себе, т.е. в собственном коде. Если нескольким приложениям приходится одновременно получать доступ к одним и тем же данным из плоских файлов, то в каждом из приложений обязательно должен быть код, предназначенный для работы с этими данными. Но когда используется СУБД, то такой код в приложениях вообще не нужен.

Кроме того, если в приложении имеется код для работы с данными из плоских файлов, причем работает он только на определенной аппаратной платформе, то перенос приложения на новую платформу – это довольно сложное дело. Ведь придется изменить весь код, связанный с аппаратным обеспечением. А вот перенос на другую платформу аналогичного СУБД-приложения проходит намного проще – с меньшим количеством проблем и выпитого аспирина.

Источник

Плоские файлы

Плоские файлы — самая простая разновидность структурированных данных. Нет, плоский файл — это не папка, придавленная стопкой книг. Плоские файлы называются так потому, что имеют минимальную структуру. Если бы они были зданиями, то их стены поднимались бы не от фундамента, а прямо от земли. Плоский файл — это собрание записей данных, записываемых в определенном формате одна за другой, — данные, одни только данные и ничего, кроме данных, т.е. список. На компьютерном языке плоский файл называется простым. В таком файле нет метаданных со структурной информацией, а есть лишь одни данные.

Скажем, вам нужно сохранить в системе плоских файлов имена и адреса клиентов вашей компании. У этой системы может быть примерно такая структура.

Как видите, в файле нет ничего, кроме данных. Каждое поле имеет фиксированную длину (например, длина поля имени всегда равна 15 символам), и в этой структуре поля не отделены друг от друга. Тот, кто создал базу данных, для каждого из полей назначил позицию и длину. Любая программа, которая использует этот файл, должна «знать», какие характеристики назначены каждому полю, потому что этой информации в самой базе данных нет.

Такая структура плоских файлов позволяет работать с ними очень быстро. Однако недостатком является то, что программная логика, которая предназначена для манипуляции данными из файлов, должна быть очень подробной. Приложение должно точно «знать», где и как в файле хранятся данные. Итак, что касается малых систем, то в них плоские файлы работают прекрасно. Но чем больше система плоских файлов, тем труднее с ней работать. Использование базы данных вместо системы плоских файлов позволяет этого избежать. Хотя файлы базы данных имеют больший «фундамент», приложения могут работать на большем количестве аппаратных платформ и операционных систем. Кроме того, базы данных позволяют легче писать прикладные программы, потому что программисту не нужно вникать в детали того, как в файлах физически расположены данные.

Базы данных облегчают работу программистов, потому что при работе с данными в детали «вникает» СУБД. А приложениям, написанным для работы с плоскими файлами, необходимо держать эти детали при себе, т.е. в собственном коде. Если нескольким приложениям приходится одновременно получать доступ к одним и тем же данным из плоских файлов, то в каждом из приложений обязательно должен быть код, предназначенный для работы с этими данными. Но когда используется СУБД, то такой код в приложениях вообще не нужен.

Кроме того, если в приложении имеется код для работы с данными из плоских файлов, причем работает он только на определенной аппаратной платформе, то перенос приложения на новую платформу — это довольно сложное дело. Ведь придется изменить весь код, связанный с аппаратным обеспечением. А вот перенос на другую платформу аналогичного СУБД-приложения проходит намного проще — с меньшим количеством проблем и выпитого аспирина.

Источник

Этот термин обычно подразумевает небольшую базу данных, но очень большие базы данных также могут быть плоскими.

СОДЕРЖАНИЕ

Обзор

История

Базы данных в виде плоских файлов являются обычными и повсеместными, потому что их легко писать и редактировать, и они подходят для множества целей несложным образом.

Современные реализации

Хотя пользователь может записать оглавление в текстовый файл, сам формат текстового файла не включает понятие оглавления. Хотя пользователь может написать «друзья с Кэти» в разделе «Примечания» для контактной информации Джона, это интерпретируется пользователем, а не встроенной функцией базы данных. Когда система баз данных начинает распознавать и кодифицировать отношения между записями, она начинает отходить от «плоской», а когда у нее есть подробная система для описания типов и иерархических отношений, она теперь слишком структурирована, чтобы считаться «плоской».

Пример базы данных

Столбцы включают: имя ( имя человека, второй столбец); команда (название спортивной команды, которую поддерживает человек, третий столбец); и числовой уникальный идентификатор (используется для однозначной идентификации записей, первый столбец).

Вот пример текстового представления описанных данных:

Этот тип представления данных является вполне стандартным для базы данных с плоскими файлами, хотя есть некоторые дополнительные соображения, которые не сразу очевидны из текста:

Источник

Базы данных, состоящие из плоских файлов

Плоские файлы могут быть очень полезны во многих видах приложений. До тех пор пока файл не настолько велик, чтобы его обработка стала слишком сложной, вполне можно использовать плоские файлы. Многие системы и приложения, в том числе написанные для UNIX, используют такие файлы для хранения данных или обмена информацией. В качестве примера можно привести файл паролей UNIX.

Плоский файл, рассмотренный выше, состоит из некоторого количества информационных элементов или атрибутов, вместе они составляют то, что можно назвать «записью». Записи устроены так, что каждая строка файла является отдельной записью, а файл собирает связанные записи вместе. Бывают случаи, когда такая конструкция не совсем подходит для поддержания работы приложения, тогда приходится вводить дополнительные возможности.

Предположим, что в приложение из предыдущего раздела нужно для каждой страны внести язык, на котором в ней говорят, а также площадь и численность населения. В плоском файле одна строка соответствует одной записи, при этом каждая запись состоит из нескольких атрибутов. Каждый отдельный атрибут всегда находится внутри записи на одном и том же месте, например обозначение валюты всегда является вторым атрибутом, поэтому можно просматривать данные по столбцам, в столбце всегда представлена информация одного вида. Таким образом, добавление языка, на котором говорят в какой-то стране, можно понимать как добавление еще одного столбца во все имеющиеся строки.

Такая проблема носит название повторяющихся групп. Ситуация выглядит следующим образом: абсолютно законный элемент (язык) может повторяться в записи несколько раз, поэтому повторяется не только запись (строка), но и данные в ней. Плоские файлы не справляются с задачей, ведь невозможно определить, где заканчивается перечисление языков и начинается следующая часть записи. Единственным способом выхода из положения является введение в файл некоторой структуры, но тогда он перестает быть плоским.

Проблема повторяющихся групп возникает очень часто, и именно она стимулировала разработку более сложных систем управления базами данных. Можно попытаться решить задачу, используя обычные текстовые файлы, в которые введена некоторая структура. Такие файлы часто тоже называют плоскими, но название «структурированный плоский файл» точнее. Рассмотрим новый пример.

Проблема повторяющихся групп решена введением тегов, указывающих тип каждого элемента записи. Теперь приложение должно прочитать и интерпретировать более сложный файл только для того, чтобы добраться до содержащихся в нем данных. Выполнять в такой структуре обновление записи и поиск не очень удобно. Как можно быть уверенным в том, что описание жанра или классификация выбраны из определенного подмножества? Как, не прилагая особых усилий, вывести упорядоченный список фильмов Кубрика?

По мере того как требования к данным становятся все более и более сложными, приходится писать все больше и больше кода для чтения и хранения этих данных. Если же расширить наше DVD-приложение, включив в него информацию, которая может быть полезна владельцу магазина, занимающегося выдачей фильмов напрокат, например данные о берущих диски и взимаемой плате, о возвратах и бронировании фильмов, то перспектива использовать плоский файл для хранения всей этой информации представляется не очень-то заманчивой.

Нужен некий универсальный способ хранения и извлечения данных, а не решение, придумываемое каждый раз для того, чтобы обойти не-сколько отличающиеся друг от друга, но весьма схожие проблемы, возникающие в большинстве систем обработки данных. Нужна база данных.

Источник

Что такое плоский файл?

Как это работает

Чтобы сделать модель данных плоского файла функциональной, вся соответствующая информация о записи должна храниться в одном файле. Например, в листе CSV никакие специфичные для приложения форматы не применяются к данным, содержащимся в файле; только запятая обозначает конец одного поля в записи. Каждая запись записывается в строку в файле, что позволяет хранить все данные для одной записи отдельно от других записей.

Такие базы данных могут быстро стать очень большими и трудными для управления из-за простого способа их организации. Многие современные модели данных используют связанные таблицы для организации групп связанных данных. Это упрощает поиск и гибкость такой информации.

Использование плоской системы

Если клиент звонит компании, чтобы разместить заказ, то кто-то вводит его или ее информацию в таблицу или базу данных. Тот же самый человек или кто-то еще вводит информацию для этого конкретного заказа. Плоская файловая система может хранить всю эту информацию для клиента в одном файле.

Однако в этом нет необходимости, поэтому можно поддерживать несколько файлов: один для клиента и один для каждого отдельного заказа. Информация о заказе, хранящаяся в одном плоском файле, не связана с информацией о клиенте, хранящейся в другом. Эти файлы не имеют никакого отношения, поэтому кто-то, использующий базу данных плоских файлов для поиска информации о клиентах, может легко пропустить дополнительные файлы о заказах.

Слабые стороны этой системы

Поскольку каждая запись должна быть завершена сама по себе, плоская файловая система обычно приводит к очень большим файлам или отсутствию связи между информацией внутри нее. Общая база данных, используемая сегодня, является реляционной базой данных. Эта модель позволяет связать информацию в одной таблице с другими таблицами, используя ключевые поля, которые существуют в каждой из них. Несколько таблиц соединяются через эти поля, что позволяет каждой из них иметь только часть всей необходимой информации.

Реляционные базы данных

Тот же пример клиента, приведенный выше, может выглядеть совсем иначе в реляционной модели. Когда клиент звонит, чтобы разместить заказ, кто-то вводит его или ее информацию в таблицу «клиент» в базе данных. Затем другой человек может ввести информацию для своего заказа в отдельной таблице. Каждая из этих таблиц содержит поля, которые связывают их друг с другом. Это означает, что кто-то может использовать систему для более удобного поиска всей информации для клиента, включая общую историю заказов.

Продолжение использования

Базы данных с плоскими файлами действительно используются, хотя функциональность этой модели данных не так эффективна, как более быстрый реляционный подход. Простые системы могут легко содержать основную информацию для быстрой базы данных. Отсутствие связанных полей также устраняет ошибки, которые могут возникнуть из-за отсутствующих таблиц, поэтому многие загружаемые базы данных используют этот формат, чтобы избежать таких проблем.

Источник