|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
В Oracle BI есть готовые функции кластеризации методами K-means и O-means, по Кохонену, вроде бы, нет. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 13:57 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
iv_an_ruтранзитивные запросы и плюс хоть какая-то возможность на каждом шаге сделать временную табличку и при этом залезть в табличку, сделанную на предыдущем шаге. Но вот как вы это потом отлаживать будете? таки это все есть практически на любой СУБД. отладка без вопросов - через менеджер или VS ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 14:06 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
LucreciaВ Oracle BI есть готовые функции кластеризации методами K-means и O-means, по Кохонену, вроде бы, нет. пожалуйста, прочтите первый пост - "без использования" интеллектуальных надстроек/расширений СУБД ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 14:08 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikLucreciaВ Oracle BI есть готовые функции кластеризации методами K-means и O-means, по Кохонену, вроде бы, нет. пожалуйста, прочтите первый пост - "без использования" интеллектуальных надстроек/расширений СУБДТогда оцените "разработку без использования" в человеко-часах и покажите заказчику, пусть сравнит с опцией "купить надстройки/расширения". Думаю, он выберет второе. Если не дурак. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 14:22 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
Павел ВоронцовNikNikNikNikпропущено... пожалуйста, прочтите первый пост - "без использования" интеллектуальных надстроек/расширений СУБДТогда оцените "разработку без использования" в человеко-часах и покажите заказчику, пусть сравнит с опцией "купить надстройки/расширения". Думаю, он выберет второе. Если не дурак. Если это не какаянить курсовая :) А по делу, действительно непонятен метод закручивать гвозди когда можно забить( красивый каламбур вышел ) :) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 14:42 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikLucreciaВ Oracle BI есть готовые функции кластеризации методами K-means и O-means, по Кохонену, вроде бы, нет. пожалуйста, прочтите первый пост - "без использования" интеллектуальных надстроек/расширений СУБД Если ситуация такая, что готовых инструментов нет, а сделать надо, например, чтобы вообще проверить подходит ли метод для решения задачи. Ну и делайте, чем рабочее место позволяет. Я делал в Access (k-means, иерархические и проч.), можно и на PL/SQL. Но вот чистым SQL - а нафига??? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:10 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
Lecter, спасибо за комплимент про возраст - уже проверяю. a, "а на фига" - для универсальности переноса процедуры/функции с СУБД на СУБД Если не трудно - чиркните каркас k-means на SQL, спасибо ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:22 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikLecter, спасибо за комплимент про возраст - уже проверяю. a, "а на фига" - для универсальности переноса процедуры/функции с СУБД на СУБД Если не трудно - чиркните каркас k-means на SQL, спасибо только на SQL, да еще и универсальном (ANSI?) - не знаю как. И знать не хочу) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:39 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikдля универсальности переноса процедуры/функции с СУБД на СУБДДля универсальности пишут не sql-запросы, а прослойки между пользователем и данными. Их часто называют "Приложение". ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:39 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikдля универсальности переноса процедуры/функции с СУБД на СУБДБД используется только как хранилище ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:41 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikLecter, спасибо за комплимент про возраст - уже проверяю. a, "а на фига" - для универсальности переноса процедуры/функции с СУБД на СУБД Если не трудно - чиркните каркас k-means на SQL, спасибо Нет единого стандарта для всех СУБД. Есть АНСИ который полностью не поддерживает ни одна СУБД. А вот написав приложение на Ява... ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:53 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNik"а на фига" - для универсальности переноса процедуры/функции с СУБД на СУБДЭто в высшей степени идиотизм. Рекомендую ознакомится с расшифровкой SQL и подумать хорошо ли он подходит для реализации нейронных алогоритмов. Ты же если остро нуждаешься в универсальности - напиши на C++ и читай про: Oracle Calling External Procedures MSSQL How to: Create and Run a CLR SQL Server User-Defined Function Как там в других СУБД я не в курсе... З.Ы. Наглость поражает. Пример данных и результата привести не потрудился зато алгоритм ему набросай. Все побежали тебе писать Kohonen clustering algorithm based on Oracle model clause. ... Хотя тебе ж это не подойдет, потому как model clause в других СУБД нет. Так что придется выкручиваться рекурсивными запросами, но не думаю что они спасут. З.З.Ы. Ах да, скажу по секрету, что в каждой СУБД свой диалект SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.07.2011, 15:55 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
NikNikNikNikЕсли не трудно - чиркните каркас k-means на SQL, спасибоЯ тут решил заняться твоим вопросом исключительно из академического интереса. И все-таки пришел к выводу, что рекурсивным with задача не разрешима. Рассмотрим пример Numerical Example of K-Means Clustering . Реализация алгоритма укладывается в довольно компактную функцию Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60.
Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11.
Если посмотреть код функции, то может возникнуть мысль, что можно копнуть в сторону рекурсивного with, но при дальнейшем рассмотрении сразу сталкиваешься со следующими ограничениями: 1. В рекурсивной части запроса нельзя ссылаться на самого себя в inline view. Код: plaintext
Код: plaintext 1. 2. 3. 4.
Безусловно на model clause все решаемо, но тоже не особо изящно и эффективно. :) ... |
|||
:
Нравится:
Не нравится:
|
|||
24.07.2011, 23:41 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
dbms_photoshop, спасибо, круто бум потетсировать ... |
|||
:
Нравится:
Не нравится:
|
|||
28.07.2011, 08:44 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
С 2011 прошли заметные улучшения, может кому-нибудь будет полезно. 1. Кластеризовать можно вообще не создавая никаких моделей 12с Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64.
2. Можно использовать функции cluster_* c указанием модели, но имеется только 3 алгоритма кластеризации: k-Means, O-Cluster, or Expectation Maximization . Есть возможность конфигурировать небольшое число настроек для каждого. 3. Если хочется полной гибкости - есть возможность прикрутить абсолютно любой алгоритм на R language с помощью ORE ( 11.2.0.3/4 или 12с ). Oracle R Enterprise Embedded SQL Scripts . В том числе Self-Organising Maps by Kohonen . Кроме того получить визуализацию результата из R и отобразить с помощью, например, OBIEE. ... |
|||
:
Нравится:
Не нравится:
|
|||
30.01.2016, 22:47 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
dbms_photoshop, Спасибо. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 09:11 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
dbms_photoshopесть возможность прикрутить абсолютно любой алгоритм на R language с помощью OREТут стоит уточнить, что хотя R и называют языком программирования, но он является всего лишь крайне скудным (имхо) интерпретируемым языком. Все "умные алгоритмны" написаны как правило на С и могут быть использованы в R через библиотеки. ... |
|||
:
Нравится:
Не нравится:
|
|||
31.01.2016, 19:37 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
dbms_photoshop3. Если хочется полной гибкости - есть возможность прикрутить абсолютно любой алгоритм на R language смотря еще, какой объем данных.. возможно, проще будет воспользоваться Python, выгрузить в панду (pandas), а дальше уже гибкость максимальная - и кластеризация, и классификация, и визуализация, и универсальность БД ) ... |
|||
:
Нравится:
Не нравится:
|
|||
05.02.2016, 14:23 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
Uchastnegсмотря еще, какой объем данных.. возможно, проще будет воспользоваться Python, выгрузить в панду (pandas), а дальше уже гибкость максимальная - и кластеризация, и классификация, и визуализация, и универсальность БД )Насколько я понимаю pandas - дополнительный пакет/библиотека к python, который содержит только базовые вещи для анализа и выгрузки/загрузки данных. Она не содержит, например, "Self-Organising Maps by Kohonen" о чем шла речь в этом топике. И хоть этот пакет (kohonen) можно скачать в дополнение к python, но все равно не совсем понятно какой это дает профит по сравнению с использованием R. С одной стороны при наличии Advance Analytics option, использование R достигается через вызов extproc from Oracle, можно сохранять определения R функций прямо в базе для дальнейшего вызова и прочее. Но с другой стороны, опция стоит 23к и если цель только использовать внешние библиотеки анализа данных, то вряд ли имеет смысл платить. В конце концов написать свою библиотеку, вызывающую любую необходимую библиотеку python это дело пары дней, так что выбор R vs python для меня не очень очевиден. Хотя если в python нет дефолтных ограничений по памяти и параллельности как в R (которые обходятся танцами с бубном), то это ему большой плюс. ... |
|||
:
Нравится:
Не нравится:
|
|||
10.02.2016, 16:52 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
Нижесказанное имеет некоторое отношение к сравнению СУБД, надеюсь модераторы меня простят. Акцент таки на возможностях Оракла. Это был достаточно интересный пример для анализа возможностей rec CTE. Что по сути требуется - это выполнять в рекурсивном члене аналитику и группировку. Группировка невозможна ни в одной из имеющихся у меня под рукой СУБД (Oracle, MSSQL, PG), но агрегатные функции можно корявенько заменить на аналитика + distinct или аналитика + фильтр по row_number. dbms_photoshop Если посмотреть код функции, то может возникнуть мысль, что можно копнуть в сторону рекурсивного with, но при дальнейшем рассмотрении сразу сталкиваешься со следующими ограничениями: 1. В рекурсивной части запроса нельзя ссылаться на самого себя в inline view. Код: plsql 1.
dbms_photoshop 2. В рекурсивной части не могут быть использованы аналитические функции: Код: plsql 1. 2. 3. 4. 5.
Вообще, насколько мне известно, в плане возможностей rec with ничего не поменялось с 11.2 до 21с. (однако в плане производительности и оптимизации много изменений) Итак, в плане ограничений в рекурсивном члене можно привести такую таблицу ORA PG MSSQLdistinct - + -group by - - -subquery - + +analytics + + +(*) Или чуть подробнее - distinct реализован только в PG - агрегатные функции недопустимы нигде - использование имени CTE в подзапросе невозможно только в Оракл, что сильно ограничивает потенциал - использование аналитики возможно везде но в МССКЛ работает кривовато. про кривоватоВ МССКЛ аналитика работает над набором строк полученным от конкретного родителя а не над всем набором строк на данном шаге. Это согласно документации, но всё равно имеет мало смысла на мой взгляд. В примере ниже сумма на третьем уровне посчитана для каждого из родителей отдельно в случае МССКЛ. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.
PG Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33.
Oracle Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35.
Итого, в МССКЛ задача нерешаема из-за кривости с аналитикой, в Оракл задача нерешаема т.к. нельзя ссылаться на имя CTE в подзапросе. А вот в PG решение может быть, например, таким. Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48.
dbms_photoshop Безусловно на model clause все решаемо, но тоже не особо изящно и эффективно. :) Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37.
... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2022, 16:23 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
Если кратко, два основных тезиса 1. PG явный лидер в плане возможностей для рекурсивных запросов т.к. позволяет реализовывать более сложную логику в рекурсивном члене. 2. Я не вижу фундаментальных причин запрещать агрегатные функции в рекурсивном члене. Может я что-то упускаю, а возможно это появится в будущем. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2022, 16:26 |
|
Кохонен на SQL
|
|||
---|---|---|---|
#18+
dbms_photoshop Я не вижу фундаментальных причин запрещать агрегатные функции в рекурсивном члене. Может я что-то упускаю, а возможно это появится в будущем. Достаточно часто, когда может возникнуть мысль о группировке в recursive member referring CTE name, можно группировку выполнить уже после того как иерархия построена. Например, когда надо посчитать агрегат для каждого узла путём соединения построенной иерархии с какой-то детализирующей таблицей. Если же требуется группировка в recursive member query block which does not refer CTE name, то это вполне возможно в Оракл. Парочку примеров тут Пятничная задача: работнички. ... |
|||
:
Нравится:
Не нравится:
|
|||
03.01.2022, 16:38 |
|
|
start [/forum/topic.php?fid=52&msg=37361199&tid=1879630]: |
0ms |
get settings: |
16ms |
get forum list: |
6ms |
check forum access: |
1ms |
check topic access: |
1ms |
track hit: |
41ms |
get topic data: |
2ms |
get forum data: |
1ms |
get page messages: |
373ms |
get tp. blocked users: |
1ms |
others: | 278ms |
total: | 720ms |
0 / 0 |