Заметил, что зачастую для интеграции реляционных баз данных используются объектно-ориентированные сообщения. В сущности, это означает лишние расходы на преобразования между реляционным и объектным представлениями данных.
Например, в системе управления заказами клиентов есть логическая сущность заказ, состоящая из "шапки" и строк заказа. В реляционной БД она представляется двумя таблицами.
...животные делятся на
а) принадлежащих Императору,
б) набальзамированных,
в) прирученных,
г) сосунков,
д) сирен,
е) сказочных,
ж) отдельных собак,
з) включенных в эту классификацию,
и) бегающих как сумасшедшие,
к) бесчисленных,
л) нарисованных тончайшей кистью из верблюжьей щерсти,
м) прочих,
н) разбивших цветочную вазу,
о) похожих издали на мух.
Борхес, "Аналитический язык Джона Уилкинса"
Модели данных делятся на
а) концептуальные,
б) реляционные,
в) корпоративные,
г) "сущность-связь",
д) предметной области,
е) незавершенные,
ж) приснившиеся архитектору данных за пять минут до пробуждения.
Ну, вы поняли?
Неоднократно встречал деление данных в информационных системах (далее ИС) на
Этого недостаточно, чтобы представить типичное разнообразие данных с точки зрения их моделирования и задач, возникающих при эксплуатации ИС. Вот мое деление, которым пользуюсь несколько лет и которое кажется довольно удачным:
Опишу эти виды данных неформально, но доходчиво.
Если бы у нас были только агрегатные функции, мы были бы принуждены постоянно делать выбор: видеть детальные данные или агрегированные? Аналитические функции, известные также как оконные функции или over-функции, позволяют одновременно получить и то и другое. С их помощью можно видеть данные, агрегированные по множеству строк, рядом с детальными данными.
Обычные, или скалярные, функции принимают на вход значения столбцов одной — текущей — строки курсора. Агрегатные функции принимают на вход значения столбцов всех строк курсора, определяемых where и group by (или их отсутствием). Оконные функции принимают на вход значения столбцов множества строк, определяемого в предложении over и зависящего от текущей строки.
Рассмотрим оконные функции на примере СУБД PosgreSQL 15.
Это продолжение поста Пробелы и острова, или Gaps and islands. Часть I
Напомню, что задачи вида "пробелы и острова", или "gaps and islands", возникают, когда в некоторой последовательности нужно найти участки (диапазоны, интервалы) непрерывных данных – "острова" – и/или участки отсутствия данных – "пробелы".
Часто последовательность данных – это хронологическая последовательность, то есть, развернутая во времени, например, по датам. Тогда "острова" – это непрерывные периоды, когда некое событие происходит ежедневно, а "пробелы" – это непрерывные периоды, в течение которых это событие не происходит.
Рассмотрим решение задачи "пробелы и острова" на хронологической последовательности данных.
