Плоска база даних структура або модель даних, яка характеризується тим, що дані зберігаються у текстових файлах у вигляді таблиці.

Плоскі файли ред.

У плоскому файлі, як правило зберігається по одному запису у кожному рядку. Поля повинні мати фіксовану ширину або розділені знаками табуляції (TSV), пропусками, комами (CSV) або іншими символами. Таке надмірне форматування потрібне для того щоб уникнути колізії розділяючих символів. Плоска організація даних не передбачає структурних взаємозв'язків між даними, тобто дані роздруковані на листку паперу виглядатимуть так само як і у файлі, на відміну від більш складно організованих реляційних баз даних.

Класичним прикладом плоскої бази даних може вважатися телефонний довідник, що містить невеликі записи фіксованої довжини: Імені, Адреси та Номера телефону. Інший дуже поширений, хоча й не традиційний приклад, проста (не складена) HTML таблиця, яка складається із рядків і стовпців.

Реалізації ред.

Телефонний довідник можна написати від руки у звичайній алфавітній книжці, можна на листі паперу і скористатися друкарською машинкою або текстовим редактором на комп'ютері і роздрукувати на принтері. Хоча є багато прикладів програмного забезпечення написаного спеціально для зручного створення і використання тих чи інших плоских баз даних.

Історичні реалізації ред.

Виникнення плоских баз даних пов'язують із іменем американського статиста Германа Голлеріта, якому належить ідея про те, що персональні дані кожного резидента США такі як ім'я, вік, тощо можуть бути представлені рядком із букв та цифр, розділених між собою пробілами довжиною рівно 80 символів. У 1888 р Г.Голлеріт створив особливий пристрій — табулятор, у якому інформація, нанесена на спеціальні носії інформації перфокарти, розшифровувалася електричним струмом. Згодом, він продав свою концепцію і табулятор бюро перепису населення США. У 1890 р. табулятор використовувався для обробки даних дванадцятого перепису населення США, це була перша комп'ютеризована база даних, яка являла собою тисячі коробок заповнених перфокартами.

Протягом Другої світової війни американський уряд та великі корпорації використовували примітивні комп'ютери для найтиповіших задач бухгалтерського обліку, наприклад, обрахунку заробітної платні. Слід відмітити, що ці машини усе ще використовували 80-символьні перфокарти Голлеріта як основний носій при зберіганні і обробці даних. Підпириємство Голеріта згодом переросло у комп'ютерного гіганта фірму IBM, яка займає домінуючі позиції на ринку і сьогодні.

У 80-х роках ХХ-го століття на обох платформах як DOS так і Macintosh, програми, що дозволяли користувачам створювати їхні власні плоскі бази даних стали такими ж популярними, як і текстові редактори або електронні таблиці. Приклади засобів моделювання плоских баз даних можна було знайти у ранніх версіях FileMaker та PC-File. Деякі програми забезпечували обмежені реляційні можливості, дозволяючи обмін даними між файлами.

Сучасні реалізації ред.

Наразі небагато програм дозволяють створювати та використовувати плоскі бази даних загального використання, така можливість реалізована у Microsoft Works (доступна у деяких версіях Windows) та AppleWorks інколи називається ClarisWorks (доступна як для Windows так і для Apple платформ). В той же час такі продукти як Paradox фірми Borland та Access фірми Microsoft пропонують прості засоби створення реляційних баз даних разом із вбудованими мовами програмування. Системи керування БД такі як MySQL або Oracle вимагають програмістських навичок для створення баз даних.

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

XML дуже популярний формат зберігання даних у текстових файлах, однак XML допускає складні вкладені структри даних та визначення самих даних, тому було б некоректно називати XML засобом реалізації плоских баз даних.

Терміни та означення ред.

Терміни, що вживаються для опису плоских баз даних та засобів їхньої підтримки, різні для кожної конкретної реалізації, проте їхня суть від цього не змінюється. Наприклад, FileMaker використовує термін «Find» в той час як MySQL застосовує «Query». Інший приклад: термін «files» у FileMaker еквівалентний терміну «tables» у MySQL. Щоб уникнути плутанини наведемо такі означення:

Стовпець (поле) — деякий параметр, що характеризує об'єкт. В СКБД FoxPro і FileMaker ця сутність називається полем (англ. field), у MySQL та Microsoft SQL Serverстовпцем (англ. column). Програма Microsoft Access використовує обидва терміни. Полем також часто називають перетин стовпця і рядка.

Рядок (запис) — набір значень стовпців. Кожен рядок плоскої бази даних містить один і той самий набір стовпців що й будь-який інший. У програмах FoxPro і FileMaker вживається термін запис (англ. record), у MySQL та Microsoft SQL Server — рядок (англ. row). Програма Microsoft Access використовує обидва терміни. Дуже важливо не плутати рядок таблиці (англ. row) і типом даних рядок (англ. string).

База даних — набір записів, де кожен запис містить усю доступну інформацію про конкретний об'єкт. Строго кажучи плоска база даних не повинна містити нічого окрім самих даних та роздільників. У ширшому розумінні — це така база даних, яка зберігається у одному-єдиному файлі і має форму простої таблиці із рядків та стовпчиків, що не містять посилань один на одного або інші таблиці.

Приклади баз даних ред.

Нехай задано наступну базу даних, ідентифікатор, ім'я вболівальника, назва команди, за яку він вболіває. Власне самі дані можуть бути подані у вигляді наступної таблиці

1       Дмитро          Шахтар
3       Вячеслав        Шахтар
4       Олександр       Шахтар
5       Артем           Динамо
7       Ігор            Шахтар
6       Олег            Шахтар
2       Олександр       Динамо

Відповідно до означень поданих вище стовпчики цієї таблиці назвемо стовпцями або полями а рядки — рядками або записами. Слід звернути увагу, що дані в середині одного поля — «однорідні». У першому стовпці це — ідентифікатори (унікальні номери), у другому — імена, у третьому — назви футбольних клубів. Також важливим є те, що поля в межах одного запису пов'язані семантично, тобто записи у даному прикладі можна читати так: «Артем вболіває за „Динамо“».

Для того, щоб перетворити дану таблицю на плоску базу даних, необхідно задати правило зберігання даних. Одним із найпростіших є таке: усі поля мають фіксовану ширину (якщо довжина запису менша ширини поля, заповнити місце пробілами), кожен новий запис повинен починатися із нового рядка. Той самий результ можна досягнути, розділяючи поля знаками табуляції а записи — символом нового рядка. Файли такого формату називаються розділеними табуляцією.

Інший спосіб зберігання даних полягає у тому, що поля розділяються комами, а записи символами нового рядка. Дані у такому форматі називаються розділеними комами (CSV).

"1","Дмитро","Шахтар"
"3","Вячеслав","Шахтар"
"4","Олександр","Шахтар"
"5","Артем","Динамо"
"7","Ігор","Шахтар"
"6","Олег","Шахтар"
"2","Олександр","Динамо"

І ще один спосіб зберігання даних:

1-Дмитро-Шахтар/3-Вячеслав-Шахтар/4-Олександр-Шахтар/5-Артем-Динамо/7-Ігор-Шахтар/6-Олег-Шахтар/2-Олександр-Динамо

Усе це еквівалентні бази даних.

Редагування таких баз здається дуже простим коли даних небагато, проте зручність спеціальних засобів, які дозволяють читати, редагувати, створювати і стирати файли плоских баз даних стає особливо помітною на значних обсягах даних, крім того реалізації СКПБД (систем керування плоскими базами даних) дозволяють перевіряти дані на відповідність типу і шаблону, здійснювати пошук тощо.

Швидкість і простота таких засобів є очевидними плюсами, але по мірі зростання обсягів і складності самих даних з'являється необхідність у більш складному та гнучкому інструментарії такому як реляційні бази даних.

Різниця між плоскою і реляційною моделлю баз даних ред.

Дуже важливо розуміти різницю між однотабличною плоскою базою даних, описаною вище і багатотабличною реляційною базою даних. Плоскі файли насправді є складовою частинами будь-якої реляційної бази даних і виступають як сховища індексів (indexes), обмежень (constraints), триггерів (triggers), відношень (foreign key relationships), планів фрагментації (fragmentation plans) та реплікації (replication plans) а також інших складових сучасних розподілених реляційних баз даних.

у наступному прикладі дві плоскі таблиці File1 та File2 зв'язані між собою зовнішнім ключем team у деякому реляційному відношенні R

File1

file-offset	id	name		team
0x00		8	Сергій		Динамо
0x13		1	Дмитро		Шахтар
0x27		3	Вячеслав	Шахтар
0x3B		4	Олександр	Шахтар
0x4F		5	Артем		Динамо
0x62		7	Ігор		Шахтар
0x76		6	Олег		Шахтар
0x8A		2	Олександр	Динамо

File2

team	arena
Динамо	НСК "Олімпійський"
Шахтар	РСК "Олімпійський"

Стовпець file-offset насправді не є частиною цього відношення він є прикладом індексу.

Індекс для File1

0x00000013
0x0000008A
0x00000027
0x0000003B
0x0000004F
0x00000076
0x00000062
0x00000000

Див. також ред.

Джерела інформації ред.

Обчислювальні механізми