Comments 9
Потенциальные ключи таблицы (candidate key) - это наборы столбцов, которые обеспечивают уникальность каждой строчки таблицы. ...
Первичный ключ таблицы (primary key) - это то, про что рассказывает плоская таблица. ... Первичный ключ обеспечивает уникальность каждой строчки. Т.е. первичный ключ - это один из потенциальных ключей. ...
Это не совсем правильно. Вот простейший пример, который противоречит написанному:
CREATE TABLE test (id TEXT, PRIMARY KEY (id(10)));Потенциальным ключом может быть не только набор столбцов, но и включающее их выражение. Да, не каждое выражение может быть первичным ключом, есть ограничения... но кандидатом - запросто.
Функциональные зависимости (functional dependencies).
Пардон, а какое отношение это имеет к понятию "Архитектура плоской таблицы"? То, что вы описываете - это внешние ключи, связи между таблицами, понятие уровня схемы данных... да элементарно требует минимум двух таблиц (даже в случае self-reference, когда это две копии одной таблицы).
Потенциальным ключом может быть не только набор столбцов, но и включающее их выражение. Да, не каждое выражение может быть первичным ключом, есть ограничения... но кандидатом - запросто.
Определение потенциальных ключей я беру классическое, т.е. не привязанное к базам данных. Определение из википедии: "A candidate key, or simply a key, of a relational database is any set of columns that have a unique combination of values in each row, with the additional constraint that removing any column could produce duplicate combinations of values. ".
Т.е. в части прикладных инструментов (реляционных БД) вы, думаю, правы. Но классика все-таки предполагает, что ключи - это подмножества столбцов. В моей практике классика удобнее. Если бы я работа много с SQL думаю статья была бы совершенно о другом :)
Пардон, а какое отношение это имеет к понятию "Архитектура плоской таблицы"? То, что вы описываете - это внешние ключи, связи между таблицами, понятие уровня схемы данных... да элементарно требует минимум двух таблиц (даже в случае self-reference, когда это две копии одной таблицы).
Термин "архитектура плоской таблице" не официальный. Т.е. эталонного определения, насколько я знаю, нет. В статье я описываю случай именно одной таблицы. Это связано со спецификой данных, с которыми я работаю. Обычно в фокусе одна таблица. Часто сильно денормализованная и сложная.
Внешние ключи, схемы данных - это другая область. Я это не рассматривал. Опять же, потому, редко встречаю именно базы данных (нормализованные взаимосвязанные таблицы). Чаще - отдельные сложные таблицы.
Определение потенциальных ключей я беру классическое, т.е. не привязанное к базам данных.
Тем более. Именно привязка к базам данных и порождает ограничения, которых в случае классического определения быть и не должно. Просто классическое определение, как я понимаю, совсем не против переопределения данных и статических вычисляемых столбцов, а потому полагает, что любое выражение-кандидат нашло воплощение в виде отдельного столбца. То есть рассматривает вопрос с точки зрения "провёл глазом, и сразу заметил".
SQL у меня на начальном уровне, в работе активно использую python и excel.
Вопрос: есть ли в реляционных базах данных инструменты, аналогичные тому, что я описываю в статье? Например, инструмент помогающий найти функциональные зависимости, которые явно не видны. Или например рекомендующие нормализацию таблиц.
Подозреваю, что я не первый кто задается такими вопросами) Почти уверен, что есть нечто такое, но ни разу не встречал.
Вообще это интересно, что решая обычные бизнес задачи мы часто оперируем терминами реляционных баз данных, сами того не подозревая. Т.е. базы данных - это важно. Одна из целей статьи - это как раз донести важность понимания основ баз данных и хранения информации.
есть ли в реляционных базах данных инструменты, аналогичные тому, что я описываю в статье? Например, инструмент помогающий найти функциональные зависимости, которые явно не видны. Или например рекомендующие нормализацию таблиц.
Реляционные БД предназначены для того, чтобы принимать данные, хранить их, обрабатывать и возвращать. И делать это эффективно. Так что указанный вами функционал никакого отношения к СУБД не имеет.
И да, такой инструмент на поверх СУБД вполне может быть создан. Как в составе ПО, которое включается в состав всего программного комплекса (возможности встроенного клиента, например), так и в виде создаваемого пользователем SQL-приложения либо независимого приложения, использующего СУБД в соответствии с его назначением.
Я работаю над разработкой BI системы, которая выполняет анализ данных по запросу на естественном языке.
Сейчас тестируем агентов на базе langchain. Вы не рассматривали данные решения? Там уже есть готовый агент, который может собрать всю необходимую информацию по схеме и данным в БД.
Вообще у меня были идеи прикрутить к инструмент языковую модель, чтобы результаты анализа выглядели как отчет для человека. Идея очень логичная. Т.е. сочетание алгоритмической логики и первичная интерпретация этого через LLM может дать отличную начальную точку для анализа человеком.
Еще раз уточню, что мой инструмент фокусируется на одной большой сложной таблице (такие часто возникают в бизнес среде). Интересно, но такого инструмента я ни разу не видел (только FDtool).
А вот анализ связанных таблиц (база данных, схемы данных) - думаю другая история.
Тема анализа таблиц интересная, она пока не закрыта полностью. Поэтому я буду развивать эту библиотеку. Если есть желания поучаствовать - пишите.
Также интересна обратная связь, пишите комментарии по применению FlatTableAnalysis или просто мысли по анализу плоской таблицы.
Её величество Плоская таблица