|
Удаленный раздел
Я удалил раздел «Важные соображения при построении хранилища данных», так как нецелесообразно включать в определение раздел «с практическими рекомендациями». Я написал автору изменения, но не получил ответа и поэтому предпринял это действие. Текст, который был удален, приведен ниже.
Важные вопросы, которые следует задавать при использовании хранилища данных
- Вам нужно хранилище данных? Хранилища данных дороги, кроме того, вам необходимо обучить сотрудников тому, как ими пользоваться, что также требует больших затрат.
- Всем ли сотрудникам нужен доступ к хранилищу данных? Не всем сотрудникам нужен доступ ко всему хранилищу данных, в случае, если им нужна какая-то информация, вы можете подумать о создании витрин данных.
- Как часто нужно его обновлять? Это зависит от характера данных, некоторые из них необходимо обновлять мгновенно, другие можно обновлять еженедельно или ежемесячно.
- Какие инструменты интеллектуального анализа данных вам следует использовать? Конечные пользователи должны быть основными определяющими при выборе инструментов, но самым важным ключом является обучение.
пожалуйста, по английски
Я прочитал эту страницу пару раз, но до сих пор не понимаю, что такое хранилище данных или хранилище данных. Может ли кто-нибудь привести конкретные примеры того, о чем, черт возьми, говорится в этой статье? —Предыдущий комментарий без подписи, добавленный 78.101.133.126 ( обсуждение ) 13:32, 21 марта 2009 г. (UTC)
Мы все еще ждем статьи на английском! Что хорошего в статье в энциклопедии, чтобы что-то объяснить тем, кто это уже знает? Просто чтобы удовлетворить эго?
Сделаны основные правки
Хранилище данных - это просто место хранения, где мы храним данные для наших преимуществ, таких как простой просмотр данных и т. Д. Хранилище данных имеет некоторые преимущества, а также некоторые недостатки. . Преимущество: мы можем легко получить доступ к данным, доступ к данным становится быстрее, данные становятся согласованными и т. Д.
Это общее описание хранилища данных.
Спасибо, лалит бхардвадж
Это в высшей степени неверная характеристика хранилища данных. Мартин Джонс Cambriano Energy - Предыдущий неподписанный комментарий, добавленный MartynInEurope ( обсуждение • вклад ) 11:21, 8 августа 2015 г. (UTC)
Эта страница требует серьезной работы!
Я старший архитектор хранилища данных в компании из списка Fortune 100. У нас 150 человек в штате и годовой бюджет 30 миллионов, и если бы мое руководство зашло на эту страницу, чтобы узнать, за что они платят всему этому персоналу, нас бы уволили !!! Хранилища данных - это ОГРОМНО больше, чем говорится в этой статье. Я вернусь, чтобы значительно улучшить его, но пока не думайте, что это все, что нужно для хранения данных! - [[Пользователь: годовой бюджет в 30 миллионов - это слишком много для хранилища данных. Обычно случается, что есть компании, которым нужны данные для управления своим бизнесом (большинство из них), и компании, для которых данные являются их бизнесом. Я предполагаю, что этот писатель относился ко второй категории. Нил Раден ( выступление ) 23:30, 17 февраля 2008 г. (UTC)
Кроме того, большая часть информации неверна. Определения «datamart» и «OLAP» неверны, и обсуждение «размерных моделей» также некорректно. - Предшествующий неподписанный комментарий добавлен Рэндигренье ( обсуждение • вклад ) 15:46, 10 мая 2015 г. (UTC)
Этот текст не совсем правильный
- Обычные системы баз данных используют сильно нормализованные форматы данных, поэтому они будут выполнять транзакции и запросы как можно быстрее, с минимальными затратами времени и пространства.
Нормализация дает вам огромную гибкость в отношении типов запросов, которые вы можете запускать, но часто за счет времени. (без знака)
tzeh 5.янн.2004 написал (а)
Эта запись «хранилище данных» не является определением, соответственно. описание хранилища данных. Этот текст определяет соотв. описывает систему хранилища данных с некоторыми компонентами системы хранилища данных. Хранилище данных - это только хранилище данных, построенное из отдельных внутренних и / или внешних источников данных, где данные интегрированы согласованным образом. (без знака)
Танк акулы в компьютерном мире
Проект хранилища данных государственного агентства переименован: теперь он официально является «базой данных отчетности административных систем». Почему бы просто не назвать это хранилищем данных? «Некоторые законодатели пригрозили заблокировать проект, если склад не будет построен в их собственных районах», - ворчит на месте лоцман. «Все попытки объяснить, что никакие физические сооружения никогда не будут построены, не увенчались успехом. Законодатели никогда не слышали о складе без здания где-нибудь». [1] 4.250.198.106 14:18, 29 марта 2005 г. (UTC)
Рекомендации
Я удалил название Wiley из библиографии, так как они публикуют много названий по этой теме, и выделение одного из них казалось довольно произвольным. Ссылка, представленная в разделе «Ссылки», включает все заголовки Wiley о хранилищах данных.
Разделы «Ссылки» и «Внешние ссылки» действительно должны быть объединены, поскольку «Внешние ссылки по-прежнему являются« ссылками ». Ringbang 13:15, 22 июля 2005 г. (UTC)
- Для меня это звучит разумно. Вчера я добавил внешнюю ссылку (в базу знаний по хранилищам данных на http://www.datamgmt.com ), но вижу, что кто-то удалил ее без комментариев. Эта база знаний - очень хороший источник информации о хранилищах данных, созданный ведущим ведомством Великобритании по хранению данных, и здесь не менее полезен, чем книга Кимбалла. GreenInker 22:12, 25 мая 2006 г. (UTC)
Причина, по которой я считаю, что это не произвольный выбор книг - хотя обе они от Wiley - заключается в том, что я рекомендую людям начинать с этих двух книг. Один из них представляет собой общий обзор подхода Корпоративной информационной фабрики, а книга Кимбалла представляет собой скорее общий взгляд на вещи. Они не противостоят, но некоторые люди так считают, и это действительно два самых известных имени в области хранилищ данных. Они заслуживают особого внимания. Стивен Пейс 9 августа
- Имеет смысл. Если вы добавите их повторно, я не буду их удалять, но было бы неплохо, если бы списки были каким-то образом уточнены в статье (например, некоторые упоминали, что это стандартные ссылки для начинающих). Еще лучше было бы подразделы по специальным темам в области хранилищ данных, общие заголовки для начинающих и т. Д. Я определенно вижу ценность в помощи людям в изучении огромной библиотеки управления информацией Wiley. - Ringbang 20:22, 10 августа 2005 г. (UTC)
Я нашел статью, в которой обсуждаются два упомянутых подхода к организации данных в хранилище данных (Inmon & Kimball), в журнале ISI: March 2005 / Vol. 48, No. 3 СООБЩЕНИЯ ACM, стр. 79-84, «Сравнение методологий хранения данных», но я не знаю, как поставить ссылку. Я думаю, что эта ссылка может быть в разделе «Архитектура данных - Различные методы хранения данных в хранилище данных». Гета 20:31, 21 декабря 2006 г. (UTC)
Объединить
Рекомендуем объединить статью « Витрина данных» с этой. Комментарии? SqlPac 14:46, 17 мая 2007 г. (UTC)
Точно нет. Витрина данных - это отдельное понятие от хранилища данных. Витрина данных достойна отдельной статьи. Стив, 13 июня 2007 г.
Я согласен с тем, что витрины данных достаточно отличаются от хранилищ данных, чтобы заслужить отдельную статью. Кроме того, эти два термина часто используются как взаимозаменяемые лица, не обладающие знанием, и объединение статей может усилить это заблуждение. Однако витрины данных и хранилища данных часто используются в качестве дополнительных компонентов общего решения Business Intelligence. По этой причине я думаю, что отношения между ними необходимо раскрыть в обеих статьях. Иоанна, 22 июня 2007 г.
Что ж, я видел (как консультант IBM в течение семи лет в Азии и Северной Америке) и использовал (как разработчик уже шесть лет) витрины данных, которые получают данные из хранилищ данных. Значит, они могут быть тесно связаны. Джони 5 июля 2007 г.
- Это может быть тесно связано, но означает ли это, что витрина данных не имеет собственной идентичности, отличной от хранилища данных? Неужели витрина данных не работает без нее? Если не получается, то можно объединить. Но если может, это отдельная концепция, достойная отдельной статьи. - сума разговоры 19:45, 5 июля 2007 (UTC)
Немного неуравновешенный.
Части этой статьи написаны очень про инмон за счет полного описания метода Кимбалла. Я думаю, здесь можно было бы использовать описание метода Кимбалла с точки зрения Ральфа Кимбалла, а не с точки зрения Инмона. Возможно, для каждого метода нужна собственная статья, вместо того, чтобы пытаться добавить небольшой объем информации по каждому из них в эту статью, и в конечном итоге будет немного полагаться на плюсы и минусы подхода.
- И у Кимбалла, и у Инмона есть свои статьи. Я предлагаю вам расширить их POV там. Здесь мы можем провести сравнения. Нил Раден ( разговор ) 22:58, 24 февраля 2008 г. (UTC)
Кроме того, это совершенно неверное описание письма Инмана. Инман не говорит, что данные хранилища данных должны быть 3NF. Более того, так называемый метод Кимбалла фактически включает нормализацию. Правильно составленная таблица фактов - это 3NF, а размеры - 2NF. Обсуждение нормализации необходимо лучше информировать. Я рекомендую "Введение в системы баз данных" от CJ Data, чтобы лучше понять теорию нормализации и реляционных баз данных. - Предыдущий неподписанный комментарий добавлен Рэндигренье ( обсуждение • вклад ) 15:51, 10 мая 2015 г. (UTC)
Я думаю, что «меньше» должно быть «больше»
Я считаю, что предложение ... «Менее сложная информация разбита на самые простые структуры (таблица), где все отдельные элементы атомарного уровня связаны друг с другом и удовлетворяют правилам нормализации». можно было бы лучше обработать как что-то вроде ... «В этом подходе каждый из более сложных информационных элементов разрешается в набор записей в нескольких таблицах, каждая из которых удовлетворяет правилам нормализации». Хотя даже это звучит как полный рот ... какие-нибудь мысли? Kiwi137 ( обсуждение ) При отсутствии возражений внесу поправки в текст в соответствии с вышеизложенным. Kiwi137 ( разговорное ) 11:51, 14 января 2008 (UTC)
Статью нужно переписать
Любая статья о хранилищах данных, которая начинается с принципов Инмона 20-летней давности и десятилетних дебатов с Кимбаллом, является уроком истории, а не информативным материалом. Я даже не могу согласиться с первым предложением: «Хранилище данных - это главное хранилище исторических данных организации, ее корпоративная память». Это только частично, когда это правда, когда есть настоящее корпоративное хранилище данных, что бывает редко. Хранилище данных содержит только структурированные данные, полученные из операционных систем. Это довольно мало для корпоративной памяти.
Кому-нибудь интересно работать со мной над улучшением этой статьи? Мне бы хотелось увидеть больше объяснений того, как хранилище данных интегрируется в сегодняшнюю вычислительную среду, влияние масштабирования и реального времени на дизайн и т. Д. Нил Раден ( доклад ) 23:58, 27 января 2008 г. (UTC)
- Буду рад помочь. Однако в статье нельзя игнорировать Инмона и Кимбалла, поскольку их методологии и мнения широко признаны. SqlPac ( обсуждение ) 20:50, 24 февраля 2008 г. (UTC)
- Я не предлагаю игнорировать их, но они не самая важная проблема, или, скорее, споры по ним не являются. Хранилища данных находятся на грани серьезного переосмысления благодаря конвергенции операционных и аналитических процессов. Как процесс пакетного обновления с высокой задержкой через несколько физических уровней (фабрика корпоративной информации) работает с сегодняшним внешним бизнесом, огромным масштабом и спросом на оперативность? Где мы можем разместить потоковые базы данных и обработку сложных событий и автоматизацию принятия решений? Я полагаю, что моя точка зрения состоит в том, что история создания хранилищ данных интересна, но более важно, чтобы мы сосредоточились на написании статьи, полезной для читателя. Нил Раден ( разговор ) 22:47, 24 февраля 2008 г. (UTC)
- Почему бы вам не добавить последний раздел о будущем хранилищ данных? ( Writerguy71 ( разговор ) 15:27, 26 февраля 2008 (UTC))
- Я сделал удар в кратком разделе о фьючерсах на хранилища данных. ( Writerguy71 ( разговор ) 10:47, 7 марта 2008 (UTC))
- «Складские фьючерсы» - я чувствую, что мне следует позвонить своему биржевому брокеру и вложить большие средства
. SqlPac ( обсуждение ) 17:20, 9 марта 2008 г. (UTC)
- «Складские фьючерсы» - я чувствую, что мне следует позвонить своему биржевому брокеру и вложить большие средства
- Я согласен с тем, что их не следует игнорировать, и я могу согласиться с тем, что обсуждение этих двух личностей, в частности, может быть не самым важным вопросом на тарелке, но чтобы понять будущее, нам нужно знать прошлое, верно? :) Я думаю, что информация об этих двоих важна, потому что их методики сегодня так широко используются. Важно смотреть на то, что принесет будущее, но, возможно, для большинства читателей еще важнее то, что сегодня широко используется. SqlPac ( обсуждение ) 17:20, 9 марта 2008 г. (UTC)
- Я переписал раздел «Кимбалл против Инмона», чтобы он был немного менее догматичным и в большей степени строил обсуждение в терминах методологий проектирования «сверху вниз» и «снизу вверх». Очевидно, что были упомянуты Инмон и Кимбалл, но поскольку эта статья не о них как таковых, а о хранилищах данных в целом, я в основном заявил, что «это подход к дизайну ... и этот парень является одним из ведущих сторонников этого подхода. этот подход ... "Я также добавил ссылки и перечислил некоторые преимущества и риски, связанные с различными методологиями проектирования. Не стесняйтесь настраивать или изменять по своему усмотрению. Я думаю, мы можем добавить еще немного информации об широко используемых подходах к «гибридному дизайну». SqlPac ( обсуждение ) 19:15, 10 марта 2008 г. (UTC)
Один физический репозиторий?
Кто-то вставил туда следующее предложение: «Эти два влиятельных эксперта представляют традиционные взгляды на один аспект хранилища данных - должно ли оно находиться в одном физическом хранилище». Я не согласен с формулировкой, так как я не думаю, что кто-то действительно сказал, что ваши данные должны храниться в одном «физическом репозитории». Что такое «физический репозиторий»? Единая база данных на одном сервере? Один сервер в одной сети? Исключает ли это серверные фермы и географически разделенные системы резервирования? SqlPac ( обсуждение ) 20:50, 24 февраля 2008 г. (UTC)
- Я думаю, дело в том, что Кимбалл и Инмон были в основном сосредоточены на аспектах баз данных для хранилищ данных, что на самом деле не так. Кимбалл много писал об ETL, веб-аналитике и всем жизненном цикле хранилища данных. Инмон основал первую компанию (Prism), которая занималась ETL, и много писал о многих аспектах хранилищ данных. Я думаю, что этот человек имел в виду, что дебаты Инмона и Кимбалла были о том, как построить мега хранилище данных, но на самом деле это не так. Их разногласия заключались в основном в методологии (как действовать), хотя Имон сначала отверг многомерное моделирование, а позже применил его для «витрин данных». Но действительно интересной частью этого утверждения является комментарий об одном физическом репозитории. Сегодня о нем следует думать как о логическом репозитории, поскольку, как вы сказали, он может быть распределенным. Кроме того, происходит быстрый захват баз данных в памяти и федерации запросов через мета-уровень, который продвигается медленно, но неуклонно. Нил Раден ( разговор ) 22:57, 24 февраля 2008 г. (UTC)
Еще один раунд правок
Была предпринята попытка еще одного раунда редактирования. Была попытка сохранить большую часть вещества нетронутой. Эти правки послужат кормом для улучшения статьи. Например, приведенный выше комментарий к физическому репозиторию был правильным. Writerguy71 ( разговор ) 25 февраля 2008 (UTC)
Была попытка включить в суть статьи чью-то личную диаграмму. Честно говоря, диаграмма мало что добавляет. Writerguy71 ( разговор ) 25 февраля 2008 (UTC)
К тому же, надо признать, в статье сильно не хватает аннотации. Если есть неаннотированные спорные утверждения, то, согласно политике Википедии, удалите их. При этом, из-за отсутствия лучшего термина, спорный материал может вращаться вокруг «вопросов религии Инмон - Кимбалла». Была сделана попытка осветить эти вопросы «справедливо и сбалансировано». Writerguy71 ( разговор ) 25 февраля 2008 (UTC)
Наконец, я не знаю, как вышеупомянутый дискуссионер делает вывод о том, что Инмон и Кимбалл сами сосредоточились на проблеме с базой данных. Тем не менее, язык был изменен с попыткой сделать так, чтобы другие читатели не делали такого же вывода. - Эта статья потребовала так много работы, что, вероятно, есть много других моментов, которые можно было бы лучше сказать. Writerguy71 ( разговор ) 25 февраля 2008 (UTC)
- Было бы полезно, если бы вы использовали отступ под комментариями, которые вы комментируете. Кроме того, что бы вы подумали об удалении изображения вверху? Он описывает только один тип среды хранилища данных. Но что еще более важно, он использует термин «хранилище данных», который используется поставщиком. Нил Раден ( разговор ) 21:07, 25 февраля 2008 г. (UTC)
- Как было сказано ранее, я считаю, что диаграмма мало что добавляет. ( Writerguy71 ( разговор ) 11:53, 26 февраля 2008 (UTC))
- Это ушло Нил Раден ( разговор ) 00:16, 27 февраля 2008 (UTC)
Репозиторий
В первом предложении используется слово «хранилище». Действительно ли хранилище данных является репозиторием? На большинстве диаграмм это гораздо больше. Является ли ETL частью склада? Являются ли метаданные частью хранилища (метаданные могут быть размещены в собственном репозитории, но разве сами метаданные не являются чем-то большим, чем просто репозиторием?). Если вы хотите подробно рассказать об этом, разве отчеты, показатели, шаблоны и даже забытые пользователи не являются частью хранилища данных? Нил Раден ( разговор ) 21:12, 25 февраля 2008 г. (UTC)
- Для простоты оставьте первое предложение как «хранилище». Если вы хотите быть технически правильным, включите ETL, метаданные и т. Д. В первый абзац. Нравится видеть ваши правки и то, как вы рисуете границы. Только не называйте хранилище данных корпоративной памятью. ( Writerguy71 ( разговор ) 16:10, 26 февраля 2008 (UTC))
- Я изменил вступление. вокруг, используя два определения - одно определение из часто цитируемой статьи ACM и другое определение из часто цитируемой статьи Inmon. Я также перечислил другие преимущества, указанные в проекте Data Warehousing в Стэнфорде. Вы можете пересмотреть или переставить по мере необходимости. Я думаю, что цитаты во вступлении должны вызывать доверие. хоть. SqlPac ( обсуждение ) 18:59, 9 марта 2008 г. (UTC)
- Я заметил, что другие переставляли контент, и это выглядит неплохо. Я переделал вступление. и первый абзац, чтобы объединить их, и я также вынес преимущества из вступления в отдельный раздел. В основном это было сделано для того, чтобы вступление было коротким, приятным и по существу. Я также немного изменил формулировку «расширенного определения», поскольку оно начиналось с «Предыдущее определение фокусируется на данных ...», а затем продолжаю объяснять, что расширенное определение включает «перемещение * данных *, анализ * данных *, извлечение, преобразование и загрузка * данных * ». Похоже, автор пытался сказать, что предыдущее определение было полностью сосредоточено на «хранении данных». В любом случае, не стесняйтесь менять все, что нужно. SqlPac ( обсуждение ) 02:05, 12 марта 2008 г. (UTC)
- Я изменил вступление. вокруг, используя два определения - одно определение из часто цитируемой статьи ACM и другое определение из часто цитируемой статьи Inmon. Я также перечислил другие преимущества, указанные в проекте Data Warehousing в Стэнфорде. Вы можете пересмотреть или переставить по мере необходимости. Я думаю, что цитаты во вступлении должны вызывать доверие. хоть. SqlPac ( обсуждение ) 18:59, 9 марта 2008 г. (UTC)
Нормализация / денормализация
Это все неправильно. По моему опыту, операционные системы - это самые денормализованные системы. Взгляните, например, на SAP. Это нарушает все правила. Наиболее нормализованной схемой во всей системе являются звездообразные схемы в SAP BI. Совершенно неверно, что размерная схема денормализована. Хорошо спроектированная звездная схема находится во второй нормальной форме, и если вы сделаете снежинку в измерениях, что я всегда делаю для обеспечения разреженной агрегации, они находятся в третьей нормальной форме. Некоторые могут возразить, что дублирование данных (через агрегаты) нарушает правило нормализации, но если вы задумаетесь об этом, то сделает и индекс. Если вы посмотрите на схему со снежинками, вы увидите серию 3-х звезд нормальной формы. Это полный МИФ, что 3-я нормальная форма не обеспечивает хороших результатов. Это зависит от типа схемы. Устраните круговые соединения, и он работает довольно хорошо. Нил Раден ( выступление ) 21:30, 25 февраля 2008 г. (UTC)
- Хорошо, а раздел должен существовать? Или должен быть раздел о «дизайне», который, возможно, объясняет детализацию, что некоторые конструкции хранилищ данных следуют некоторым / всем правилам Кодда и что некоторые хранилища данных следуют многомерному моделированию, которое использует «факты» и «измерения» и которые могут или не могут следовать некоторым правилам Кодда? Если нет, что должно быть в разделе, если вы согласны с тем, что такое должно существовать? ( Writerguy71 ( обсуждение ) 15:56, 26 февраля 2008 (UTC))
- Во многих случаях размерные схемы состоят из денормализованных таблиц. Индексы - это отдельная проблема от «данных» и специфическая деталь реализации. Они управляются внутри системы, обычно не доступны пользователям и не считаются «данными» в большинстве систем. Некоторые индексы не дублируют данные, поэтому я не понимаю, о чем вы говорите. Обеспечивает ли 3NF хорошую производительность, зависит от многих факторов. Некоторые системы лучше работают со схемой «звезда», другие - со схемой «снежинка». Мне было бы интересно увидеть «хорошо продуманную звездную схему в 2NF». Обычно простое измерение времени может быть определяющим фактором того, соответствует ли оно критериям для 1NF, не говоря уже о 2NF или 3NF. Есть ли у вас примеры хорошо продуманных звездообразных схем 2NF (схемы? Что угодно ...)? SqlPac ( обсуждение ) 17:35, 9 марта 2008 г. (UTC)
- Я попытался переписать и переместить информацию в более подходящий раздел. Раздел по-прежнему читается плохо, поэтому мы приветствуем ваши правки ( Writerguy71 ( обсуждение ) 11:57, 4 марта 2008 г. (UTC))
- Большое улучшение Нил Раден ( разговор ) 04:48, 11 апреля 2008 г. (UTC)
- Я попытался переписать и переместить информацию в более подходящий раздел. Раздел по-прежнему читается плохо, поэтому мы приветствуем ваши правки ( Writerguy71 ( обсуждение ) 11:57, 4 марта 2008 г. (UTC))
- Схема «звезда» определяется как «измерения на 2-й нормальной форме и факты на 3-й нормальной форме». Схема снежинки может быть определена как «размеры на 3nf и факты на 3nf». Итак, технически, если вы «Снежинка» ваши измерения, вы не создаете модель звездной схемы.
- Я думаю, что некоторая путаница связана с концепцией «размерное моделирование». В «сеттинге Кимбалла» понятие «размерная модель» обозначает модель звездной схемы (с простыми ключами), хотя, конечно, снежинка также имеет «размеры».
- Я думаю, что на вопрос производительности между двумя моделями сложно ответить. Алгебраически (скажем, необходимое количество флопов) простой запрос, выполняемый на снежинке, должен быть самым быстрым. Хотя ключевым параметром производительности для современных серверов являются не ошибки, а количество «страниц», которые должны быть загружены в память для решения запроса, и это будет иметь прямое отношение к внутренней работе сервера. механизм запросов, как кто-то намекнул выше. F.ex, я был почти уверен, что MSSQL2005-2008 не дает значительного прироста производительности с любой формой снежинок и что SSAS2005-2008 лучше работает на "чистых" звездных схемах (важное соображение, если вы планируете использовать эту технологию в своих реляционных системах). модель) Jomsviking ( разговор ) 21:19, 26 февраля 2010 (UTC).
- Кроме того, я согласен, что раздел странный. Может быть, я полностью упускаю суть автора, под «нормализованным» я понимаю нормализованную модель реляционной базы данных, снежинку. С учетом сказанного:
- F.ex. в нем говорится (Относительно размерных моделей). Чтобы сохранить целостность фактов и измерений, загрузка хранилища данных с данными из различных операционных систем является сложной задачей. Теперь, возможно, верно, что это сложно, но не более сложно, чем в «нормализованной» модели. . На самом деле операции аналогичны, хотя в размерной модели вы пропускаете утомительную часть нормализации.
- Кроме того, сложно изменить структуру хранилища данных, если организация, применяющая многомерный подход, изменит способ ведения бизнеса. Что ж, это всегда правда, вне зависимости от «размерности» или «нормализации».
- А также
- «Основное преимущество этого подхода в том, что легко добавлять информацию в базу данных».
- Нет, это не так. Йомсвикинг ( Обсуждение • вклад ) 22:02, 26 февраля 2010 г. (UTC)
Я полностью согласен с комментариями Jomsviking. —Предыдущий комментарий без подписи, добавленный Eleven one ( обсуждение • вклад ) 16:04, 28 июля 2010 г. (UTC)
Даты ключевых событий в первые годы создания хранилищ данных
Был добавлен список некоторых ключевых дат. Я подумал, что для статьи будет полезно немного исторического контекста. Список спорен, так что редактируйте. ( Writerguy71 ( разговор ) 02:26, 6 марта 2008 (UTC))
- Роенбек ( разговор ) 11:37, 17 февраля 2011 (UTC) Основные даты прекрасны, но, поскольку список составлен сейчас, Дэниел Линдстедт, кажется, был так же важен, как Инмон и Кимбалл. Он действительно был? Более того, если DV будет выпущен в 2000 году, мне кажется, что лишь немногие избранные могли знать, что он начал работу в 1990 году. Если не известно всем, как это может быть ключевым событием?
Статья на витрине данных очень нуждается в помощи!
Я только что посетил то, что можно было бы считать «родственной статьей» этой - статье « Витрина данных» . Это очень нуждается во внимании. Я решил разместить здесь небольшую заметку, поскольку люди, которые редактируют эту, с большей вероятностью будут заинтересованы в ней (по крайней мере, с большей вероятностью, чем большинство редакторов). Спасибо. SqlPac ( обсуждение ) 02:15, 12 марта 2008 г. (UTC)
Внешние ссылки, встроенные ссылки
Может ли кто-нибудь встроить эти ссылки? Я не уверен, какой материал был взят из этих "основополагающих работ" в статье. Если они действительно считаются основополагающими произведениями, должно быть хотя бы одно предложение, на которое стоит ссылаться непосредственно из каждого, верно? :)
- Уильям Х. Инмон, Ричард Д. Хакаторн: Использование хранилища данных, John Wiley & Son's, ISBN 0-471-05966-8 - одна из основополагающих работ Инмона по хранению данных
- Ральф Кимбалл, Марджи Росс: Инструментарий хранилища данных: полное руководство по пространственному моделированию (второе издание), John Wiley & Sons, ISBN 0-471-20024-7 - одна из основополагающих работ Кимбалла (с помощью Росс) по хранению данных
Также я переместил все внешние ссылки на блоги и т. Д. Из раздела «Ссылки» в новый раздел «Внешние ссылки». Кто-то может захотеть пройти по этим ссылкам в какой-то момент и убедиться, что они соответствуют критериям Википедии для включения в статью. Я недостаточно знаком с критериями, чтобы сделать это сам, но там есть пара блогов, с которыми я не знаком, и я бы не стал хорошим судьей относительно того, соответствуют ли они критериям включения. Спасибо. SqlPac ( обсуждение ) 04:00, 12 марта 2008 г. (UTC)
Я в шоке
... насколько хороша эта статья в наши дни :) Я помню, когда она была просто уродливым окурком! Одна вещь, которой стоит уделить немного внимания, - это раздел «Архитектура хранилища данных». Вот некоторые из вопросов, которые приходят на ум из небольшого содержания: 1) Существуют ли какие-либо другие концепции помимо представленной? 2) Как слои «связаны» друг с другом? 3) Существуют ли какие-либо общие рекомендации или общие / лучшие практики в отношении архитектуры хранилища данных? Кажется, что этот раздел можно было бы красиво дополнить некоторым качественным контентом, но сейчас он выделяется как очень минимальный в остальной хорошей статье. Я заметил несколько мелочей, которые я вернусь и исправлю, когда у меня будет время, но в целом вы все улучшили эту статью на несколько порядков по сравнению с тем, с чего она началась! SqlPac ( обсуждение ) 05:10, 24 июня 2008 г. (UTC)
Я тоже в шоке, хотя по другой причине!
В этой статье упоминается, что Ральф является сторонником восходящего подхода, в то время как его книга, над которой я сейчас размышляю, - «Набор инструментов хранилища данных» явно высмеивает этот подход. В разделе «Введение» этой книги он говорит: «Детали диаграммы создают ложное ощущение безопасности.« Если они детализированы, они должны быть хорошими »». И затем он продолжает: «Размерная модель - это нисходящая модель (обратите внимание, что мы начали с разговора с генеральным директором), а модель зависимостей данных - восходящая модель». Могу я попросить знающего волонтера проверить это? —Предыдущий комментарий без подписи, добавленный 12.107.188.130 ( обсуждение ) 17:29, 17 ноября 2008 г. (UTC)
Я полностью согласен. Парень, который написал раздел об Инмон-Кимбалле, явно не понял Кимбалла. В подходе кимбола вы начинаете с разговора с бизнесом, и посредством такого анализа бизнес-требований в сочетании с реальностью имеющихся данных вы приходите к «матрице бизнес-шины», которая представляет собой диаграмму (матрицу), которая показывает бизнес-процессы и пространственный контекст. . Это по определению подход сверху вниз. ЗАТЕМ вы используете свою «матрицу бизнес-шины» в качестве чертежа для фактического моделирования рассматриваемой проблемы. Этот процесс идет снизу вверх. Итак, сначала идет сверху вниз, а затем снизу вверх. Я считаю, что любой программист базы данных в какой-то момент, возможно, в первый же день работы, осознает, что в реальном мире вы должны построить свою базу данных так же, как каменщик строит дымоход, хотя, если конечному пользователю не нравится ваше готовое хранилище данных , или дымоход, вся ваша работа напрасна. Итак, самое важное - соответствовать требованиям конечного бизнеса - и это отражено в методе Кимбалла, который начинается с бизнеса (сверху вниз). Йомсвикинг ( разговорное ) 23:13, 26 февраля 2010 (UTC)
Я согласен с этим утверждением. Подход Инмона против Кимбалла запутан и почти что назад. Это необходимо исправить, потому что они представляют две школы мысли, которые должны быть очень ясны для людей, которые хотят понять, какой архитектурный подход они хотят использовать. —Предыдущий комментарий без знака добавлен 210.54.1.141 ( обсуждение ) 21:03, 24 марта 2010 г. (UTC)
И снова я полностью согласен с комментариями Jomsviking. Это следует исправить как можно скорее. —Предыдущий неподписанный комментарий, добавленный Eleven one ( обсуждение • вклад ) 16:05, 28 июля 2010 г. (UTC)
Подход Инмон был несколько искажен. Это не метод кипячения океана, а хорошо спроектированный, повторяющийся и рентабельный подход. Каким бы способом вы ни строили корпоративную DW, это будет дорого, но итеративный подход - либо Inmon, либо Kimbal и т. Д. - означает, что вы не кипятите океан и не тратите значительные суммы денег на то, что у вас впоследствии появится. выбросить (как не по назначению). MRJ
Примеры гибридного дизайна
Было бы неплохо выделить некоторые из самых популярных методологий гибридного дизайна - Madmonky ( обсуждение ) 16:38, 1 апреля 2009 г. (UTC)
История в разделе "Будущие разработки"
Почему в первом разделе раздела «Будущие события» содержится историческая информация? Хотя я думаю, что информация должна быть где-то в статье, это явно не тот раздел. Кроме того, было бы неплохо, если бы он подробно описал некоторые из этих отклоненных идей. - Мадмонки ( выступление ) 17:06, 1 апреля 2009 г. (UTC)
- В сноске приводятся примеры отклоненных идей. Не уверен, что вы имеете в виду под разделом фьючерсов, включая историческую информацию. Если вы имеете в виду ссылки на 2009 год, то 2009 год закончился всего на четверть. По поводу гибридных методологий, не уверен, что существуют записанные гибридные методологии. - writerguy71 ( обсуждение ) - Предыдущий недатированный комментарий добавлен 00:47, 3 апреля 2009 г.
Нечеткое определение в реальном времени / интегрированное
В чем разница:
Хранилище данных в реальном времени Хранилища данных на этом этапе обновляются каждый раз, когда операционная система выполняет транзакцию (например, заказ, доставку или бронирование). Интегрированное хранилище данных Хранилища данных на этом этапе обновляются каждый раз, когда операционная система выполняет транзакцию.
Я думаю, это требует переутомления.
RAWR (UTC).
- Я исправил второе определение (интегрированное хранилище данных). Crysb ( разговор ) 20:35, 27 сентября 2010 (UTC)
Насколько мне известно, список вымышленный. Во-первых, мне не нравится раздел «на уровне сложности хранилища данных»: «То, что хранилище данных находится в автономном режиме, не означает, что оно менее сложное, чем (псевдо) хранилище данных в реальном времени. Вы (должны) строить хранилище данных в реальном времени или строить части DW как в реальном времени, когда есть определенные бизнес-требования, которые, кстати, никогда не являются «реальным временем», а являются указанием длительности задержки данных (ну, по крайней мере, когда вы познакомили покупателя с реальностью). Стратегия или метод, применяемый для создания (псевдо) реального времени DW, может быть более или менее сложным, что обычно связано с тем, насколько «в реальном времени» должен быть ваш DW; другими словами, продолжительность задержки. Так или иначе, список смешивается в "интегрированном" DW в драку. Это просто странно. интегрированный DW может быть в реальном времени или нет, DW в реальном времени может быть интегрирован или нет. Это не имеет смысла ранга , как , что ДГ йомсвикинги ( разговор ) 10:25, 5 января 2011 (UTC).
Недостатки
Это ужасный раздел;
* Хранилища данных не являются оптимальной средой для неструктурированных данных. * Поскольку данные должны быть извлечены, преобразованы и загружены в хранилище, в данных хранилища данных присутствует элемент задержки. * В течение срока службы хранилища данных могут иметь высокие затраты. * Хранилища данных могут устареть относительно быстро. Доставка неоптимальной информации в организацию обходится дорого. * Часто существует тонкая грань между хранилищами данных и операционными системами. Могут быть разработаны дублирующие дорогостоящие функции. Или в хранилище данных могут быть разработаны функциональные возможности, которые, оглядываясь назад, следовало разработать в операционных системах.
То , что « Хранилище данных не является оптимальной средой для неструктурированных данных. »
Совершенно не имеет значение; Одним из основных моментов DW является превращение неструктурированных данных в структурированные (консолидация данных). DW не должен содержать «неструктурированные данные» (кроме промежуточного репозитория).
« Поскольку данные должны быть извлечены, преобразованы и загружены в хранилище, в данных хранилища данных присутствует элемент задержки ».
Это верно, а также верно для большей части всех сложных операционных систем (возьмем финансовую операционную систему, которая отслеживает платежи; Клиент оплачивает свой счет в банке. Банк отслеживает этот платеж в своих собственных системах и каким-то образом информирует финансовую операционную систему о платеже, которая затем обрабатывает этот платеж "на каждой ссылке или стыке, где есть Ключевым моментом является то, может ли DW удовлетворить бизнес-требованиям по длительности задержки? Если да, то проблем нет.
« В течение срока службы хранилища данных могут иметь высокие затраты». По сравнению с чем ??? На мой взгляд, методы хранения данных намного превосходят и намного дешевле в предоставлении НЕОБХОДИМОЙ бизнес-аналитики на платформе, будь то простые плоские отчеты или сложные многомерные онлайн-данные, чем, например, попытки создать эти НЕОБХОДИМЫЕ отчеты в операционной системе. (даже стандартные системы, такие как Axapta, конечно, совершенно невозможны с пользовательскими системами сборки, которые обычно могут понять только оригинальные программисты, не тратя бесконечные часы). Я знаю, что некоторые люди, которые обычно не понимают сложности, истории и слабости данных более крупной организации, думают, что предоставление деловой информации - это «всего лишь» вопрос программирования некоторых «веб-частей», веб-сервисов. "хорошо, на бумаге, смотреть" SOA "и получать данные - это" просто "писать некие" SQL-запросы "к операционной системе. Они ошибаются, и этот подход всегда заканчивается бесчисленными часами (дорогостоящего) программирования (и перепрограммирования). Конечным результатом может быть то, что информация доставляется в хорошем виде, но затраты частично составляют относительно много часов программирования ( приятно для людей вроде меня), но если серьезно, то это «сеть беспорядка» из взаимозависимых, взаимоблокирующих веб-сервисов, веб-страниц и тому подобного, что примерно через месяц никто не может понять. Что создает ряд проблем для организации, среди которых: критическая зависимость от тех, кто ее создал; Неудача при гибкой интеграции данных организаций; Священные «черные ящики», которые никто не осмеливается трогать или чинить (что, например, очень хорошо подходит для замораживания будущего естественного развития ИТ-инфраструктуры организаций).
Что можно сказать, так это то, что хранилища данных могут иметь высокие «начальные затраты», которые должны быть оплачены / выполнены до того, как информация может быть доставлена бизнесу, что доказывает (или опровергает) ценность хранилища данных.
« Хранилища данных могут устареть относительно быстро. Доставка неоптимальной информации в организацию обходится дорого ». Что верно для всех «ИТ-усилий». Конечно, если одна операционная система изменена или заменена, что создает потребность в обновлении DW, а также всех других систем (включая людей), зависящих от этой измененной системы, - это часть жизни.
« Часто существует тонкая грань между хранилищами данных и операционными системами. Могут быть разработаны дублирующие дорогостоящие функции. Или в хранилище данных могут быть разработаны функциональные возможности, которые, оглядываясь назад, следовало бы разработать в операционных системах ».
Верно, но « в хранилище данных могут быть разработаны функциональные возможности, которые, оглядываясь назад, следовало бы разработать в операционных системах». По моему опыту, почти всегда бывает наоборот. Дорогие «надстройки» встроены в операционную систему, чтобы облегчить бизнес-требования. Но это могло быть сделано либо в DW (часто по значительно более низкой цене), либо надстройка могла быть (возможно, простой) автономной системой, которая интегрируется с данными организации через DW. (что, кстати, в большинстве случаев является более гибким решением) Jomsviking ( разговор ) 12:42, 5 января 2011 г. (UTC)
- Неплохое убийство той части, Йомсвикинг . Раздел не был получен, требуется несколько "по сравнению с X ..." и еще больше нюансов. Бьюсь об заклад, Кимбалл и Инмон потратили пара абзацев на «не делай этого, это неправильно или неэффективно». Что теперь делать? Я должен сказать, что ваши аргументы здесь, какими бы правдоподобными они ни были, тоже ИЛИ. Могу я предложить вам удалить текущий текст и заменить его новым списком, включая исходные аргументы? Imo новый текст может быть структурирован по аспектам «экономия», «функциональность», «качество». Или, может быть, я сам посмотрю в Кимбалле (книга должна открыться на нужной странице ;-)). - Депип ( разговор ) 18:15, 5 января 2011 г. (UTC)
- Я не думаю, что можно говорить о «недостатках» (хранилища данных), однако можно говорить о «требованиях». Требуется ли хранилище данных для рассматриваемого бизнеса? и до какой степени? Если есть требование и оно выполняется хранилищем данных, то получить его, вероятно, было преимуществом, или наоборот.
При этом «практическое» хранилище данных - это множество вещей, от дюжины отчетов и небольших «витрин» до «настоящих» хранилищ данных. Конечно, вы можете начать обширную архитектурную дискуссию о том, как можно (или не использовать) DW в ИТ-инфраструктуре, что выходит за рамки данной статьи и одной из тех дискуссий, которые не заканчиваются. ИЛИ вы можете обсудить pro et con с ИТ-отделом старой школы, который считает, что «эти бизнес-ребята должны изучать SQL, если они хотят запрашивать данные», или с новым поколением недоумков «веб-программистов», которые не только думают, что все можно сделать в архитектуре SOA, но также подумайте, что все должно быть сделано в архитектуре SOA.
Лично я бы просто удалил раздел Jomsviking ( talk ) 20:06, 5 января 2011 (UTC).- Верно, еще раз. Текущий раздел можно удалить, хотя бы по причине ИЛИ / без источника. После этого, я думаю, можно было бы описать компромиссы: полезно ли это (эффективность) и стоит ли оно того (эффективность) в бизнесе. Это будет иметь нюансы, поскольку это более постепенная шкала, а не черный / белый. (Кстати, лично для меня полезными границами являются «они должны выучить SQL» и «просто создать его в БД транзакций».) Теперь вы удаляете. :-) - Депип ( разговор ) 20:52, 5 января 2011 (UTC)
- Я не думаю, что можно говорить о «недостатках» (хранилища данных), однако можно говорить о «требованиях». Требуется ли хранилище данных для рассматриваемого бизнеса? и до какой степени? Если есть требование и оно выполняется хранилищем данных, то получить его, вероятно, было преимуществом, или наоборот.
- Сделанный! Йомсвикинг ( разговорное ) 21:45, 5 января 2011 (UTC)
Открытие
Я действительно думаю, что мы должны попытаться написать вступление к статье, в котором объясняется, что такое «хранилище данных», а также что такое хранилище данных. Вроде как: какой смысл, зачем люди строят хранилища данных и т. Д. Я думаю, что люди, которые посещают эту статью, задаются вопросом, что такое хранилище данных (и хранилище данных). Они не заинтересованы в первую очередь в абстрактной чепухе или теоретическом расширении.
Текущее открытие
Хранилище данных поддерживает свои функции на трех уровнях: промежуточный, интеграция и доступ. Промежуточное хранение используется для хранения необработанных данных для использования разработчиками (анализ и поддержка). Уровень интеграции используется для интеграции данных и для некоторого уровня абстракции от пользователей. Уровень доступа предназначен для вывода данных для пользователей.
Это просто чушь, я этого не понимаю (и, при всей скромности, если я не понимаю тему Datawarehousing, очень немногие обычные люди понимают, что вроде как противоречит цели вики-статьи, imo). Хотя я догадываюсь о значении:
«Промежуточное хранение используется для хранения необработанных данных для использования разработчиками (анализ и поддержка)»
Нет, оставаясь с «картинкой» ETL, промежуточная стадия используется для хранения и подготовки данных для окончательной загрузки. Теперь вы можете проводить «анализ и поддержку» промежуточных данных, но это не основная причина, по которой они у вас есть.
«слой интеграции»
Никогда об этом не слышал. Возможно, некоторые люди думают о своих хранилищах данных с «уровнем интеграции», и меня это устраивает. Но это не часть стандартных «священных» моделей, предложенных Кимбаллом и (насколько я помню) Инмоном, которые все люди в этой отрасли слышали и уважают (если не поклоняются). Не то чтобы Кимбалл и Инмон сказали последнее слово, которое стоит сказать о хранилище данных, но когда дело доходит до структуры хранилища данных и системы ETL, я предлагаю, чтобы мы придерживались их как точек отсчета из-за большого уважения, которое они испытывают к промышленность.
подписать Jomsviking ( разговор ) 10:20, 7 января 2011 (UTC)
Пожалуйста, обновите эту статью.
Эта статья устарела и не совсем отражает суть статьи. Он просто перечисляет два из многих известных способов нормализации и сохранения данных в хранилище данных (репозиторий данных, используемый для отчетности).
Я мог бы добавить, что два пользователя вступили в сговор, чтобы предотвратить доступ информации к остальному миру, основываясь на том, что они считают конфликтом интересов; поскольку я изобретатель концепции. Тем не менее, эти же пользователи создали страницу, на которой есть прямые ссылки на веб-сайты, где владельцы продают книги, и другие материалы для продвижения своих концепций.
Хотя я пытался представить миру новую (по состоянию на июль 2012 года) схему, называемую Spider Schema для хранения данных на этой странице, эти пользователи удалили все ссылки на нее, предполагая, что кому-то еще нужно добавить контент, а не создатель. Интересно, кто более осведомлен, чем создатель, особенно когда он новый?
Хотя моя попытка перечислить что-то новое на этой странице удалена, на сайте, на который я ссылался, нет рекламы или ссылок, не относящихся к схеме Spider. Все могут потреблять и комментировать мир бесплатно.
Внедрение чего-то нового, когда существующее старше 30 лет (схема звездочки), не является спамом, рекламой или конфликтом интересов; это называется нововведением, в чем остро нуждается сообщество хранилищ данных.
MHargraves ( разговор ) 14:06, 16 июля 2012 (UTC)
- Я (и другие) объяснил мистеру Харгрейвсу на его личной странице обсуждения, что статья будет обновлена и будет включать в себя его изобретение «схемы паука», когда надежные сторонние источники охватят новый материал. Студерби ( разговор ) 17:00, 18 июля 2012 (UTC)
Введение требует обновления
В третьем абзаце говорится: «База данных хранилища данных, где данные организованы в иерархические группы, часто называемые измерениями, а также в факты и агрегированные факты. Комбинацию фактов и измерений иногда называют звездной схемой ». Это устранило бы необходимость в уровне доступа, о котором очень кратко говорится в следующем предложении.
Я думаю, что приведенная цитата является описанием уровня доступа, а не хранилища данных. Хранилище данных должно быть организовано таким образом, чтобы абстрагироваться от какого-либо конкретного использования данных и быть ближе к описанию «реального» мира. «Реальный» мир практически не меняется, тогда как использование данных меняется очень часто. Обычно это приводит к тому, что логическая модель данных хранилища данных находится в 3NF.
Я предлагаю сделать последние три предложения третьего абзаца похожими на следующий абзац.
Затем интегрированные данные перемещаются в еще одну базу данных, часто называемую базой данных хранилища данных, где данные хранятся независимо от любого текущего или будущего использования данных, как правило, в третьей нормальной форме (3NF). Уровень доступа помогает пользователям извлекать данные, которые организованы в иерархические группы, часто называемые измерениями, а также в факты и агрегированные факты. Комбинацию фактов и измерений иногда называют звездообразной схемой. Уровень доступа может быть реализован как представления в хранилище данных или как физически созданные объекты, заполненные данными из хранилища данных.
Это описывает лучшую архитектуру согласно моему более чем 20-летнему опыту работы с хранилищами данных. Эхаар ( разговор ) 15:16, 29 января 2013 (UTC)
кажется, OLTP - это не склад, а «операционная система»
из описания здесь неясно, чем OLTP отличается от обычной базы данных CRUD . Кроме того, операционная система претензии статьи , что «иногда операционные системы упоминаются как оперативные базы данных, система обработки транзакций, или онлайновые системы обработки транзакций (OLTP).» Итак, похоже, что OLAP - это тип хранилища, а OLTP - это тип операционной системы, а вовсе не тип «хранилища», если «склад» не означает любое приложение базы данных в целом. 76.119.30.87 ( разговорное ) 20:04, 14 февраля 2015 (UTC)
Нужна помощь
эта статья не помогает мне как студенту, которому нужна полная информация о хранилищах данных. - Предыдущий неподписанный комментарий добавлен Садау Суле ( обсуждение • вклад ) 11:32, 28 августа 2015 г. (UTC)
Внешние ссылки изменены
Привет, друзья Википедии,
Я только что изменил одну внешнюю ссылку на хранилище данных . Пожалуйста, найдите время, чтобы просмотреть мою правку . Если у вас есть какие-либо вопросы или вам нужно, чтобы бот игнорировал ссылки или страницу в целом, посетите этот простой FAQ для получения дополнительной информации. Я внес следующие изменения:
- Добавлен архив https://web.archive.org/web/20080708182105/http://www.computerworld.com/databasetopics/data/story/0,10801,70102,00.html на http: //www.computerworld. ru / databasetopics / data / story / 0,10801,70102,00.html
Когда вы закончите просмотр моих изменений, установите для отмеченного ниже параметра значение true или не сообщите другим (документация по адресу ).{{Sourcecheck}}
По состоянию на февраль 2018 г. разделы страницы обсуждения «Изменены внешние ссылки» больше не создаются и не отслеживаются InternetArchiveBot . В отношении этих уведомлений на странице обсуждения не требуется никаких специальных действий, кроме регулярной проверки с использованием приведенных ниже инструкций инструмента архивации. Редакторы имеют разрешение удалить эти разделы «Внешние ссылки изменены» на странице обсуждения, если они хотят убрать беспорядок на страницах обсуждения, но перед массовым систематическим удалением просматривают RfC . Это сообщение динамически обновляется с помощью шаблона (последнее обновление: 15 июля 2018 г.) .{{sourcecheck}}
- Если вы обнаружили URL-адреса, которые бот ошибочно считал мертвыми, вы можете сообщить о них с помощью этого инструмента .
- Если вы обнаружили ошибку в каких-либо архивах или самих URL-адресах, вы можете исправить их с помощью этого инструмента .
Ура. - InternetArchiveBot ( Сообщить об ошибке ) 08:16, 7 декабря 2016 г. (UTC)
нормализация - денормализация
для объяснения этих двух терминов требуется сноска с объяснением или вики-ссылка. Я абсолютный новичок в этом предмете (хотя и с заделом в области ИТ-программирования) и не понимаю, что означают эти два слова. 2.32.219.16 ( разговорное ) 23:38, 1 марта 2017 (UTC)
Ссылка 16 сомнительна.
Я новичок во всем этом, но, читая, я нашел сомнительную ссылку. Речь идет о «Ссылке 16». Он переходит на следующую страницу: https://svrtechnologies.com/datastage-training/data-warehouse-online-training/ . Я говорю это, потому что страница представляет собой беспорядочную неразбериху html. Более того, может показаться, что это маркетинговое направление обучения и не имеет ничего общего с цитатой из «(Kimball, Ralph 2008)». Это ставит под сомнение действительность ссылки и связанного с ней утверждения (по ассоциации). У меня нет ссылки, чтобы заменить ее, и я действительно не знаю, что с ней делать (что касается редактирования).
KValk ( разговор ) 13:57, 1 августа 2019 (UTC)
- Он был добавлен спамером, я его отменил. - MrOllie ( разговор ) 14:41, 1 августа 2019 г. (UTC)