Группировки запросов

#sql #database #mdx #graph-databases #database-theory

#sql #База данных #многомерные выражения #граф-базы данных #база данных-теория

Вопрос:

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

  1. Реляционный
    Пример: SQL
  2. Документ
    Пример: XQuery, JSONPath, MQL (MongoDB)
  3. График
    Пример: Cypher (Neo4j)
  4. Другие возможности (?)
    Dataframe / pandas? многомерные (многомерные выражения)?

Какая группировка высокого уровня может быть наилучшей для описания различных языков запросов?

Комментарии:

1. Ваш список представляет собой смесь различных типов данных. Относительные и нереляционные — это типы баз данных, SQL и NoSQL — это языковые типы, а document, graph, column и т. Д. — Это просто подкатегории баз данных на основе NoSQL (нереляционных)

2. @SvenEschlbeck понял, но я думаю, что это слишком широко и не очень помогает. Это почти как разделение тегов stackoverflow на «База данных» и «Не-база данных». Кроме того, разве sql-server, postgres, oracle не поддерживают типы json, xml? пространственные данные? отношения графа (на сервере sequel даже есть две категории таблиц для данных графа для «Узлов» и «Ребер»).

3. Да, конечно, такие типы существуют. Но вы просили «группировку […] языков запросов». В противном случае, что вы действительно хотите знать, так это то, как данные могут быть классифицированы внутри SQL или NoSQL. Если вы перейдете по некоторым из моих ссылок ниже, вы сможете узнать об этом больше.

Ответ №1:

Одним из вариантов является группирование языка запросов в зависимости от категорий базы данных.

  • реляционные (Microsoft SQL Server, Oracle, MySQL, MariaDB)
  • объектно-реляционный (PostgreSQL)
  • NoSQL
    • Ключ-значение (Riak, Redis, Couchbase Server, MemcacheDB)
    • Столбчатый (HBase)
    • Документ (MongoDV, CouchDB)
    • График (Neo4j)

Пока все хорошо, но на самом деле граница между категориями становится все тоньше и тоньше.

Например, у нас есть поддержка graph в Microsoft SQL Server, а в T-SQL у нас есть синтаксис, подобный следующему:

 -- Find Restaurants that John's friends like
SELECT Restaurant.name 
FROM Person person1, Person person2, likes, friendOf, Restaurant
WHERE MATCH(person1-(friendOf)->person2-(likes)->Restaurant)
AND person1.name='John';
  

В MongoDB у нас тоже есть график, использующий поиск по графу:

 {
   $graphLookup: {
      from: <collection>,
      startWith: <expression>,
      connectFromField: <string>,
      connectToField: <string>,
      as: <string>,
      maxDepth: <number>,
      depthField: <string>,
      restrictSearchWithMatch: <document>
   }
}
  

Итак, возможно, группировка самого высокого уровня — это просто группа системы управления базами данных, соответствующая стандартам Американского национального института стандартов (ANSI) (реляционным и объектно-реляционным) и другим.

Комментарии:

1. Ваш ответ правильный, но ваш список сбивает с толку. Это действительно возможный способ различать языки в зависимости от типа базы данных. Однако вы не можете смешивать реляционный и NoSQL, один — математическая модель, другой — язык запросов. Кроме того, он попросил группировку высокого уровня. В этом случае объектно-реляционный по-прежнему является реляционным, а не его собственной категорией.

Ответ №2:

Я попытаюсь ответить на этот вопрос с точки зрения аналитики.

Реляционная база данных (СУБД):

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

  • С точки зрения анализа данных, мы используем GROUP BY предложение для обобщения наших данных;

Важный компонент для аналитика для обобщения таких данных, как продажи, прибыль, затраты и зарплата. Обобщение данных очень полезно для аналитика при создании визуализации, выводе выводов и написании отчета. В SQL предложение GROUP BY является одним из инструментов для обобщения или агрегирования рядов данных. Например, суммируйте ежедневные продажи и объедините их в один квартал и покажите его высшему руководству. Аналогично, если вы хотите посчитать, сколько сотрудников в каждом отделе компании. Он группирует базы данных на основе одного или нескольких столбцов и объединяет результаты., Предложение GROUP BY и HAVING в SQL от Avinash Navlani

Подробнее:

Группировка в SQL используется для объединения идентичных данных в группы с помощью некоторых функций. т.е., если определенный столбец имеет одинаковые значения в разных строках, он упорядочит эти строки в группу.(1)

Простой синтаксис

 SELECT column1, function_name(column2)
FROM table_name
WHERE condition
GROUP BY column1, column2
ORDER BY column1, column2;
  
 function_name: Name of the function used for example, SUM() , AVG().
table_name: Name of the table.
condition: Condition used.
  

Документы

  • Наш пример здесь будет о MongoDB.

Когда мы говорим о группировке в MongoDB, мы должны упомянуть процесс агрегации, когда мы имеем дело с несколькими документами.

  • Операции агрегирования обрабатывают записи данных и возвращают вычисленные результаты. Операции агрегирования группируют значения из нескольких документов вместе и могут выполнять различные операции с сгруппированными данными для получения единого результата. В SQL count(*) и с group by является эквивалентом агрегации MongoDB. (2)

В чем разница между GROUPing таблицей и документом?

  • Для ответа на этот вопрос должно быть 3 ключа: (3)

    1- Какие данные вы используете?

    • Если вы используете связанные данные, лучшим подходом, который вы можете использовать, является SQL.

    2- Какой тип процесса вы хотите выполнить?

    • Базы данных SQL лучше подходят для многорядных транзакций, NoSQL лучше для неструктурированных данных, таких как документы или JSON.

    3- Какова ваша масштабируемость данных?

    • Базы данных SQL масштабируются по вертикали, базы данных NoSQL масштабируются по горизонтали. Это означает, что с точки зрения высокоуровневой группировки SQL будет выигрышной картой с точки зрения объема и глубины grouping , а также большей гибкости в нормализации.

График

Пример: Cypher (4)

Cypher, как и SQL, является декларативным, текстовым языком запросов, но для графиков.

Он состоит из предложений, ключевых слов и выражений, таких как предикаты и функции, многие из которых будут знакомы (например WHERE , , ORDER BY , SKIP LIMIT , AND , p.unitPrice > 10 ).

  • В отличие от SQL, Cypher предназначен для выражения шаблонов графов.

  • Группировка в Cypher фокусируется на аспекте виртуализации данных, чтобы дать вам общую картину. Но это бесполезно в аспекте обработки. С точки зрения больших объемов данных, это будет не очень эффективно, как реляционные таблицы, но, с другой стороны, данные будут виртуализированы.

  • Группировка с высоким уровнем, cypher не рекомендуется для этого.


Другие возможности

Пример: Фрейм данных / pandas

Python — отличный язык для анализа данных, в первую очередь из-за фантастической экосистемы пакетов python, ориентированных на данные. Pandas является одним из таких пакетов и значительно упрощает импорт и анализ данных.

Функция Pandas dataframe.groupby() используется для разделения данных на группы на основе некоторых критериев. объекты pandas можно разделить по любой из их осей. Абстрактное определение группировки заключается в обеспечении сопоставления меток с именами групп.(5)

Синтаксис

 Syntax: DataFrame.groupby(by=None, axis=0, level=None, as_index=True, sort=True, group_keys=True, squeeze=False, **kwargs)
  
 Parameters :

by: mapping, function, str, or iterable

axis: int, default 0

level: If the axis is a MultiIndex (hierarchical), group by a particular level or levels

as_index: For aggregated output, return an object with group labels as the index. Only relevant for DataFrame input. as_index=False is effective “SQL-style” grouped output

sort: Sort group keys. Get better performance by turning this off. Note this does not influence the order of observations within each group. groupby preserves the order of rows within each group.

group_keys: When calling apply, add group keys to an index to identify pieces

squeeze: Reduce the dimensionality of the return type if possible, otherwise return a consistent type

Returns: GroupBy object
  
  • Если мы сравним between pandas и другие методы, которые мы упомянули выше, с точки зрения анализа данных, Python pandas определенно станет зеленой картой.

    • Масштабируемость pandas ОГРОМНА !.

    • Легкий по сравнению с любым функциональным программированием.

    • Он идеально подходит для большого объема данных.


Заключение

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

  1. Какие данные вы используете.

  2. Какой тип процесса вы хотите выполнить.

  3. Какова ваша масштабируемость данных.


Ссылка

Ссылки были прикреплены к каждому разделу, чтобы быть доступными.

Ответ №3:

Вероятно, у вас уже есть ответ…

Я имею в виду, что эта группировка — это тоже то, о чем я могу думать.

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

В случае Document-based или NoSQL отличительной особенностью является то, что схема очень гибкая, также обычно связанные данные хранятся внутри того же документа.

Граф, я мало что о них знаю. Но, насколько я знаю, это просто NoSQL с возможностью запрашивать отношения. Сочетание отличительных особенностей RBDMS и не-RBDMS (NoSQL).

Фреймы данных обычно используются для быстрых операций, необходимых при обработке данных. Они являются хранилищем данных в памяти. У них нет возможности самостоятельно извлекать отношения. Мы должны выполнять операции над ними с нуля.

Ответ №4:

На самом высоком уровне вы можете спросить, что такое база данных на самом деле. Это все формы накопленных данных? Большинство людей согласны с тем, что база данных — это сортировка данных, которые каким-то образом организованы или структурированы.

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

Сами базы данных в основном можно разделить на реляционные / нереляционные или последовательные / непоследовательные. Реляционные базы данных следуют цели, согласно которой каждая таблица или объект должны / могут быть каким-либо образом связаны или связаны с любой другой таблицей или объектом. Это позволяет легко увидеть отношения или зависимости между различными записями. Кроме того, поиск, фильтрация или отладка данных становятся проще. Тем не менее, отслеживание всех взаимосвязей требует больших усилий, и часто администраторам баз данных или разработчикам трудно учитывать все комбинации и ссылки при редактировании кода или документов. Кроме того, в реляционных базах данных используются сложные системы управления базами данных (СУБД), которые содержат некоторую сложную алгебру. Реляционными базами данных являются, например, Oracle, PostgreSQL, MySQL. Все они зависят от языка структурированных запросов (SQL). С небольшими различиями, все они используют одни и те же базовые команды для изменения, редактирования, поиска или записи данных. Существуют и другие подкатегории, такие как type-relational, object-relational и т. Д., Но различия довольно незначительны.

Нереляционные базы данных менее сложны, проще в обслуживании и не так чувствительны к логическим или математическим ошибкам, как реляционные. Но они могут быть менее полезны для больших объемов данных или для таких целей, как интеллектуальный анализ данных, быстрый поиск или хранение личной информации. Данные в основном хранятся в виде различных типов данных. Вместо того, чтобы строго придерживаться концепции строки таблицы, они могут содержать пользователей, заказы, документы различных форм и форм. Самым большим недостатком этих баз данных является отсутствие у них «интеллектуального соединения». Из-за несуществующих связей между документами выполнение определенных запросов или поисковых действий может занять много времени. Кроме того, двойные записи, пропущенные записи или ошибки с меньшей вероятностью будут немедленно обнаружены программной системой. Нереляционные базы данных могут быть подразделены на типы пар ключ-значение, таблицы широких строк, хранилища документов, базы поисковых систем или базы данных графиков / изображений. Примеры включают Neo4J, Datastax Enterprise Graph, некоторые базы NoSQL, такие как Couchbase и MongoDB или Scyalla и Cassandra. Как вы можете догадаться, они используют не SQL, а NoSQL. Вы получаете данные легко и быстро, но медленно, а иногда и с осложнениями.

Итак, чтобы конкретно ответить на ваш вопрос, реляционные и нереляционные — это два (только) больших и официальных типа (под большими я подразумеваю серьезные математические различия в обработке данных). Таким образом, SQL и NoSQL являются самыми большими языками запросов с огромными различиями. Document, graph и т. Д. — Это просто формы структур данных, которые часто ассоциируются с базами данных NoSQL, но они не являются отдельным типом языка или базы! Точно так же формы баз данных (например, симметричные, снежинка, дерево, звезда и т.д.) являются лишь способом описания их базовой иерархии или структуры. Они тоже не образуют свои собственные категории… Фреймы данных, озера данных и хранилища данных (в конечном счете хранилища данных) состоят из множества баз данных и могут быть реляционными, нереляционными или сочетать оба!

Я хочу пояснить, что все сводится к реляционным и нереляционным. Особенно с базами данных, я слышу много глупостей и людей, которые различаются в деталях, они путают формы, формы, языки, имена баз данных и еще много чего. Document, MongoDB или snowflake не являются ни языками, ни математическими моделями.

PS: Я добавляю несколько ссылок на случай, если вы захотите узнать больше.

https://www.oracle.com/database/what-is-a-relational-database/

https://www.pluralsight.com/blog/software-development/relational-vs-non-relational-databases

https://www.oracle.com/database/what-is-database.html

https://www.guru99.com/data-warehousing.html