Обсуждение
Читать и комментировать в ЖЖ ↗
Насчет свинов - клиника "Белый клык" в Волковом переулке.
Комментарий
Белый клык? Они сделают это ЗУБАМИ????
Комментарий
Не знаю, чем, но лечат хорошо там :-) Они возле Зоопарка, так что ветеринары приходят и оттуда, и лечат все живое, в том числе, гадов (что редкость).
Для дитенка подойдет?
http://community.livejournal.com/klein0_vvi/58291.html
Phun — замечательная программа для имитации физических процессов с простым интерфейсом и «мультяшной» графикой. С ее помощью можно создавать как различные реалистические двухмерные модели по физике так и просто баловаться. :) Интерфейс Phun прост и напоминает немного интерфейс графических редакторов. Слева размещена панель инструментов, с помощью которой можно создавать различные модели физических тел и механизмов. В верхнем левом углу находиться главное меню программы, а около него — некоторые настройки создаваемого «мира». Если нажать правой кнопкой мышки по любому обьекту в окне программы появиться еще одно меню в котором можно изменить некоторые его физические свойства. Смотреть всем обязательно!!! К слову, эта программа появилась как дипломная работа Эмиля Энерфельдта, выпускника факультета вычислительной математики университета Умео в Швеции.
Оказывается в ноябре уже learn21 писал
:0(
Re: Оказывается в ноябре уже learn21 писал
У нас давно есть :)
Комментарий
Действительно, морские свины -- гады! Именно про них было намертво заученное в школе "И гад морских"... Но я не понял, не внял...
Скажу жене, спасибо.
Комментарий
3.1.7 data warehouse -- data store in which related data are merged to provide an integrated set of data containing no duplication or redundancy of information, and which supports many different application viewpoints
чушь какая.
Комментарий
Скорее уж ваше альтернативное определение (какое бы оно ни оказалось, особенно с учетом выбранной вами для его обсуждения лексики) чушь. Я знаком с реальными проектами авторов этого стандарта, и склонен этим авторам в их определениях верить более, чем вам.
Комментарий
чушь. например, откуда взялось "no duplication or redundancy"? задача data warehouse - OLAP/BI. там всегда есть "duplication or redundancy" (как говорил Мюллер, действия и поступки - это одно и то же). хотя бы в виде превращения snowflakes в stars, не говоря уже о materialized views.
каким образом ваше знакомство с авторами стандарта может понизить маразматичность этого определения, тоже не совсем понятно.
конечно, для полного формального доказательства чушности нужно ещё посмотреть, как они определяют термины "duplication or redundancy", но я надеюсь, что маразм авторов не заходит так далеко.
Комментарий
Кстати, авторы стандарта и про денормализацию знают. А duplication и redundancy относят к совсем другому -- их учет очень заботит.
Авторы стандарта профессионально работают с омонимией, вы за их маразм не бойтесь. Бойтесь того, как ваше умение воспринимать вдруг превратится в умение только вспоминать, а вы сами этого не заметите.
Насчет избыточности имеются вполне определенные мнен
Bill Inmon’s approach to data warehousing is a holistic data management approach, not an approach for providing stovepipe solutions. In other words, a holistic data management approach recognizes the many different types of decision support requirements all organizations have, such as operational reporting, operational ad hoc querying, tactical management reporting and strategic trend analysis reporting. It also includes many different types of applications, an implementation strategy for the organization, and data standards to avoid uncontrolled redundancy. The "drawback" (although I would not call it that) is that it takes longer to build a holistic decision support environment than to build stovepipe data marts for different sets of requirements without any consideration of standardization or integration (which includes reducing redundancy) across the organization. The end effect of stovepipe solutions is that they add to the non-integrated spaghetti chart of systems (thus adding to the redundancy) that already exist in most organizations. And the large the spaghetti chart the harder it will be to manage your data as a true corporate asset.
Кстати, дальше дискуссия как раз разивается в сторону, что считать избыточностью:
"The single most dramatic way to affect performance in a large data warehouse is to provide a proper set of aggregate (summary) records ... in some cases speeding queries by a factor of 100 or even 1,000. No other means exist to harvest such spectacular gains."
Those are Ralph Kimball's words from "Aggregate Navigation With (Almost) No Metadata" (DBMS magazine, August 1996). If the results are so spectacular - and I don't hear anyone arguing they aren't - why then is aggregation so underused?
First, I believe that the answer lies in our relational database culture or folklore. We were all taught not to redundantly store what could be calculated. This, by the way, is a restriction that users of multidimensional databases have happily ignored. Second, many of us are not clear on what constitutes a good set of aggregates.
One way to get more comfortable with aggregate tables, and to see how mandatory they are, is to think of them as indexes. We would not dream of implementing any significant OLTP or data warehouse database without indexes. These traditional indexes usually duplicate the information content of indexed columns, yet we don't disparage this duplication as "redundancy," because of the benefits.
Re: Насчет избыточности имеются вполне определенные мн
Авторы стандарта ISO 15926 вообще не связывают data warehouse с OLTP. У них совсем другие системы в голове -- например, хранилище данных о морской нефтяной платформе, порядка 10 млн. индивидуальных деталей с данными по их чертежам, контрактам, срокам годности, ценам, материалам, эксплуатационным параметрам и т.д. Это не про OLTP и BI.
Re: Насчет избыточности имеются вполне определенные мн
вообще говоря, приведённый отрывок показывает, что человек сам не особенно уверен в том, что он говорит. только конец более-менее consistent: One way to get more comfortable with aggregate tables, and to see how mandatory they are, is to think of them as indexes. We would not dream of implementing any significant OLTP or data warehouse database without indexes. These traditional indexes usually duplicate the information content of indexed columns, yet we don't disparage this duplication as "redundancy," because of the benefits.
Что, собственно, я и сказал - duplication and redundancy всегда присутствуют в data warehousing, потому что benefits way outweight the cost. То есть определение data warehousing, содержащее фразу "no duplication or redundancy" - чушь.
Комментарий
Волны перекатывались через мол и падали вниз стремительным домкратом
похоже, что вы не знаете, что такое OLTP.
Комментарий
Бойтесь того, как ваше умение воспринимать вдруг превратится в умение только вспоминать, а вы сами этого не заметите.
п-поясните, пожалуйста.
Комментарий
Я думаю, что это вы не знаете платформ промышленной интеграции данных.
Комментарий
вы перепутали с OLAP, признайтесь.
Комментарий
В этих платформах слова on line не используются вообще. Ни analitical, ни transaction. Ни кубов, ни транзакций, ни онлайна. Решаются другие задачи.
Intergraph SmartPlant Foundation, AVEVA Vnet, Bentley ProjectWise, и более мелкие типа PKS Solutions и прочих.