что такое плоские данные

Что может сводная таблица (часть 1)

Сводная таблица – невероятно сильный инструмент анализа. Конечно, мы не спорим с дисперсионным анализом данных, с дескриптивной статистикой, с регрессивным анализом, с методами Machine Learning и BigData (графы, ближайший сосед и пр.), речь о том, что «сводная таблица» это самый простой и доступный прикладной инструмент, освоить который можно в течении 5-10 минут. При этом, по принципу Парето «80 на 20», знание такого простого инструмента поможет вам решить 80% всех задач, связанных с обработкой данных. Для освоения нам нужно немного совсем простой (специально упрощенной) теории. Дело в том, что Сводную таблицу можно построить только из таблицы определённого типа… (забегая вперед из «Плоской таблицы») Во-вторых, чтобы анализировать данные, нам нужно понимать, что такое данные (хоть вопрос и кажется тривиальным).

Итак мы имеем два основных вопроса.

1. НАШИ ВОПРОСЫ

Запоминаем. ВОПРОС 1: «Что такое «плоская таблица»? ВОПРОС 2: «Какие бывают данные»? ))

2. А теперь ПРИМЕР

Допустим вы производите и продаете какую-то продукцию. И хотите спланировать свою деятельность. Сколько вам произвести или закупить?

Вот ваша таблица со среднемесячными продажами. (Рисунок 1)

По этим данным вы легко можете спланировать свою деятельность. Сколько вам купить-произвести для продажи на следующий месяц. Но вот незадача, вы вспоминаете, что у вас не одна номенклатура товара, а семь. Семь разных видов товара. Соответственно, для планирования вам нужна более сложная таблица, в которой кроме «Клиентов» появляется еще и «Товар». НО вы легко решаете эту проблему, расположив по вертикали (как и было) Контрагентов и по горизонтали Товар. Теперь вы знаете, сколько товара вам нужно купить или произвести для какого клиента. Сумма ИТОГО, конечно совпадает. (Рисунок 2)

И только вы решили, приступить к производству или к закупке этого товара, как вспомнили, что это же среднемесячные продажи, но ваш товар сезонный, и вам нужна таблица продаж по месяцам.

И вот тут-то вы призадумались! Как вам расположить поля? Можно использовать разные листочки, для каждого месяца свой лист (Рисунок 3)

Можно попробовать добавить строк в таблицу (Рисунок 4).

А что если появится еще что-то … это может быть что угодно, давайте придумаем пример, хотя он не важен.

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

Если появится еще что-то, как мы это разместим в таблице? Будем делать строчки под январем, февралем? Или разделим ячейку на несколько цветов? Почему вообще мы имеем ограничения, почему нам сложно, когда у нас появляется еще что-то? И как назвать это «еще что-то»?

Отметим, что у нас появились еще вопросы. Как назвать это «еще что-то», при появлении которого нам приходится перестраивать таблицу? Забегая вперед, это производная от ВОПРОСА 2 («Какие бывают данные»)?

И еще появился еще один вспомогательный ВОПРОС 3: «Почему сложно построить большие таблицы»? Пример не пока не помог нам ответить на ВОПРОС 1, ВОПРОС 2, а только добавил ВОПРОС 3.

3. ТОТ ЖЕ ПРИМЕР, ТОЛЬКО с другой стороны

Вторая таблица (там, где был Контрагент и Товар) будет выглядеть так (Рисунок 7). Теперь наши коробки лежат не на прямой, а на плоскости. По одной линии мы откладываем Контрагент 1, Контрагент 2, а по другой линии откладываем Товар 1, Товар 2…А на пересечении лежит наш коробок с цифрой, с ответом на вопрос, сколько Товара N покупает Контрагент N. Это двухмерный мир. Декартова система координат (кто помнит математику 6-го класса). Математики бы сказали: «Двухмерный массив данных».

Наша третья таблица выглядела бы так (нарисуем в ней циферки, чтобы легче было представлять). По одной прямой мы бы откладывали метки Контрагент 1, 2. по другой Товар 1,2. а по третьей Месяц 1,2…И на пересечении этих трех линий коробков был бы наш искомый коробок, с нужной нам цифрой. Это уже походе на трехмерный мир, и математики бы назвали бы это «трехмерный массив данных».

4. А ТЕПЕРЬ ОТВЕТЫ

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

А то, что мы откладывали как метки по прямым (Контрагент 1,2. Товар 1,2, Месяц 1,2..) — это были аналитические разрезы или характеристики данных, или еще говорят: «аналитики-разрезы-аналитические разрезы-характеристики данных- измерения»… (слово «измерение» скорее всего вам не знакомо, но программисты используют едва ли не чаще всего; почему, мы это узнаем чуть позже).

Кстати, в нашем примере была одна бумажка с в коробке, но это для простоты, на самом деле и данных может быть очень много, В нашем примере, например, % накапливаемой скидки за эту продажу, или за цена (если мы каждому клиенту продаем по своей цене, так называемая — ценовая дискриминация), себестоимость, но это легко представить, как просто 2,3… подписанные бумажки с цифрами в нашей коробочке.

«Почему сложно построить большие таблицы»? ОТВЕТ: потому что мы живем в трехмерном измерении, а аналитических разрезов бывает на-а-а-а-много больше, чем 3. Да даже когда их 3, мы уже вынуждены напрягаться, разные таблицы или расшифровка строк. А как же быть, если аналитик больше, чем три? (ЭТО ВОПРОС 4, но дадим на него ответ сразу.)

ВОПРОС: «А как же быть, если аналитик больше, чем три»? ОТВЕТ: использовать «плоскую таблицу». Плоская таблица дает возможность упорядоченно расположить таблицу с любым количеством Аналитических разрезов.

5. КАК СТРОЯТСЯ ПЛОСКИЕ ТАБЛИЦЫ

Посмотрим, как они строятся?

На том же примере: Сначала у нас была одна линия, по которой мы откладывали Контрагент 1,2.. Потом появилось «две пересекающиеся линии», на пересечении которых наши данные. Потом «три пересекающиеся линии». А что если эти линии не пресекать? Если они будут параллельными? А считать данные мы сможем прочтя строку (см. самую правую картинку на Рисунок 9). Контрагент 1, Товар 1, Март, можем добавить что-то еще, и в конце данные по продаже – 15. Кажется в такой таблице можно поместить бесконечное количество параллельных Аналитик и данных и бесконечное количество данных.

Забегая вперед, для каждого аналитического разреза и для каждого ресурса (для бумажки с цифрой) мы выделим один – «свой» столбец.

Кстати, таблицы, где есть пересекающиеся измерения – называются «кросc-таблицами», от английского cross – пересечение.

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

Для закрепления построим из нашей двухмерной кросс-таблицы — «плоскую таблицу». Вспомним ее (Рисунок 2)

Вырезаем «контрагентов» – они у нас в отдельной колонке (столбце ли – я до сих пор путаюсь, как правильно). Во вторую колонку (столбец ли) помещаем Товар, и заполняем Товаром 1. И потом на заполняем третью колонку (столбец) данными по продаже. (Рисунок 10) Возможно, это сложно давайте прямо по действиям…

Итак … По действиям …

Выделяем для Аналитики Товар 1-й столбец (колонку) И заполняем ее всеми нашими возможными контрагентами. (перебираем всех наших конрагентов) (Рисунок 11)

Теперь заполняем вторую колонку (столбец) Товаром, но так как товаров у нас много, то мы пока зафиксируем Товар 1. (Рисунок 12)

Теперь заполним (а можно просто вырезать из нашей двухмерной кросс-таблицы данные и подставить к нашим двум столбцам. (Рисунок 13)

И так и идем не переставая, пока не закончится товар. И вот что у нас получится (таблица сильно уйдет вниз, поэтому мы всю ее не будем представлять). ВОТ ОНА НАША «ПЛОСКАЯ ТАБЛИЦА» Пока двухмерная. (Рисунок 14).

Первое, компьютеру не нужно хранить нулевые записи. Мы отфильтруем нулевые записи, и таблица станет намного меньше… Вот так компьютер и будет хранить эти таблицу (Рисунок 15), вместо не поленитесь, поднимитесь к началу статьи и посмотрите сколько было зарезервировано пространства компьютером, (сколько было пустых коробков спичек, в которых не лежало ни одной бумажки с цифрами)?!

Осталось немного… посмотреть как будет выглядеть плоская трехмерная таблица из нашего примера (Рисунок 13), ну правда только для января, но восприятия это уже не испортит, потому что нам нужно всего лишь перебрать таким же способом Февраль, март и т.д.

Вот мы и поняли, что данные бывают сами данные (или «данные-сами данные-цифры-измеряемые величины-ресурсы-цифры-показатели»)

Бывают «аналитики-разрезы-аналитические разрезы-характеристики данных- измерения-характеристики».

И мы всегда теперь отличим плоскую таблицу от кросс-таблицы.

Кстати, а вы всегда отличите данные от аналитических разрезов? Не торопитесь, данные это не всегда цифры, а аналитические разрезы, это не всегда строки. В вопросе: Сколько в классе школьников, у которых средний бал 3, 4, 5? Здесь, 3,4,5 – это разве данные или скорее это аналитические разрезы? Это аналитический разрез, а не «сами данные», хотя они выражены цифровыми значениями. В другую сторону пример привести сложнее, потому что мы измеряем (сами данные) это чаще все-таки цифры. Но мы можем измерять и, например, «счастлив» «не счастлив», в зависимости от аналитических разрезов «пол», возраст (опять цифры в аналитических разрезах данных), национальности, образования…

Eще один интересный момент, а почему мы говорим о «аналитических разрезах». Об этом можете прочесть в ЧАСТИ 2.

Источник

Что такое плоские данные

Типичным примером плоской таблицы является адресно-телефонный справочник, или, например, такая вот таблица:

Здесь атрибутами являются Код заказчика, Предприятие, Представитель, Страна и Город. Названия атрибутов помещаются в заголовке. Первая по счету запись указывает, что представителем предприятия ООО Андрей и К является некий Стасов, и что местоположением предприятия является город Киев, Украина.

ПЛОСКАЯ ТАБЛИЦА КАК МОДЕЛЬ БАЗЫ ДАННЫХ

ПРЕИМУЩЕСТВА ПЛОСКОЙ ТАБЛИЦЫ

2) Удобно хранить неструктурированные данные. В ряде случаев пользователю может быть неизвестно заранее, существует ли между атрибутами какая-либо иерархическая связь. Если так, то данные лучше всего хранить именно в плоской таблице. Например, именно в такой форме ученые начинают накапливать свои знания об окружающем нас мире. В дальнейшем, когда между атрибутами удается выявить взаимосвязи типа «один ко одному», «один ко многим» и «многие ко многим», можно будет преобразовать данные в иерархическую или реляционную базу данных.

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

ЭЛЕКТРОННЫЕ ПЛОСКИЕ ТАБЛИЦЫ

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

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

Источник

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

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

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

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

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

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

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

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

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

Источник

Что такое плоские данные

Реляционная модель описывает, какие данные могут храниться в реляционных базах данных, а также способы манипулирования такими данными. В упрощенном виде основная идея реляционной модели состоит в том, что данные должны храниться в таблицах и только в таблицах. Эта, кажущаяся тривиальной, идея оказывается вовсе не простой при рассмотрении вопроса, а что, собственно, представляет собой таблица? В данный момент существуем много различных систем обработки данных, оперирующих понятием «таблица», например, всем известные, электронные таблицы, таблицы текстового редактора MS Word, и т.п. Ячейки электронной таблицы могут хранить разнотипные данные, например, числа, строки текста, формулы, ссылающиеся на другие ячейки. Собственно, на одном листе электронной таблицы можно разместить несколько совершенно независимых таблиц, если под таблицей понимать прямоугольную область, расчерченную на клеточки и заполненную данными. Таблицы текстовых редакторов вообще могут иметь совершенно произвольную структуру, например, как на рисунке:

Таблица 1 Таблица произвольной формы

Конечно, и электронные таблицы, и текстовые редакторы позволяют хранить и обрабатывать данные очень гибко, но как быть, если требуется хранить информацию обо всех сотрудниках большого предприятия и периодически выдавать ответы на запросы типа «представить список всех сотрудников, принятых на работу не позднее трех лет назад, имеющих по крайней мере одного ребенка, не имеющих взысканий и с зарплатой не выше 1000 р.». Для получения ответов на подобные запросы и предназначены Системы Управления Базами Данных (СУБД).

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

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

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

Учебное пособие имеет следующую структуру.

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

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

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

Источник

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

Содержание

Обзор

История

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

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

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

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

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

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

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

Источник