Дизайн схемы "звезда" [закрывается]
Другое событие NullPointerException возникает, когда объявляется массив объектов, а затем сразу же пытается разыменовать его внутри.
String[] phrases = new String[10];
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
Этот конкретный NPE можно избежать, если порядок сравнения отменяется ; а именно, использовать .equals для гарантированного непустого объекта.
Все элементы внутри массива инициализируются их общим начальным значением ; для любого типа массива объектов, это означает, что все элементы null.
Вы должны инициализировать элементы в массиве перед доступом или разыменованием их.
String[] phrases = new String[] {"The bird", "A bird", "My bird", "Bird"};
String keyPhrase = "Bird";
for(String phrase : phrases) {
System.out.println(phrase.equals(keyPhrase));
}
6 ответов
Используя схемы "звезда" для системы хранилища данных получают Вас несколько преимуществ, и в большинстве случаев уместно использовать их для верхнего слоя. У Вас может также быть хранилище рабочих данных (ODS) - нормализованная структура, которая содержит 'текущее состояние' и упрощает операции, такие как структура данных. Однако существуют разумные ситуации, где это не желательно. Я имел случай к системам сборки с и без уровней ODS и имел определенные причины выбора архитектуры в каждом случае.
, не входя в subtlties архитектуры хранилища данных или запуская Kimball по сравнению с войной пламени Inmon основные преимущества схемы "звезда":
-
Большинство систем управления базами данных имеет средства в оптимизаторе запросов, чтобы сделать 'Звездообразные Преобразования', которые используют Растровые Индексные структуры или Индексное Пересечение для быстрого разрешения предиката. Это означает, что выбор из схемы "звезда" может быть сделан, не поражая таблицу фактов (который обычно намного больше, чем индексы), пока выбор не разрешен.
-
Разделение схема "звезда" относительно проста как, только таблица фактов должна быть разделена (если у Вас нет некоторых с библейской точки зрения больших размеров). устранение Раздела средства, что оптимизатор запросов может проигнорировать разделы, которые не могли возможно участвовать в результатах запроса, который экономит на вводе-выводе.
-
Медленно изменяющиеся размеры намного легче реализовать на схеме "звезда", чем снежинка.
-
схему легче понять и имеет тенденцию включать меньше соединений, чем снежинка или схема E-R. Ваша сообщающая команда будет любить Вас за это
-
, Схемы "звезда" намного легче использовать и (что еще более важно) сделать, выполняют хорошо с инструментами специального запроса такой как Бизнес-объекты или Построитель отчетов . Как разработчик Вы имеете очень мало контроля над SQL, сгенерированным этими инструментами, таким образом, необходимо дать оптимизатору запросов как можно больше справки. Схемы "звезда" дают оптимизатору запросов относительно мало возможности понять его превратно.
Обычно Ваш слой создания отчетов использовал бы схемы "звезда", если у Вас нет определенной причины не к. Если у Вас есть несколько исходных систем, можно хотеть реализовать Хранилище Рабочих данных с нормализованной или схемой "снежинка" для накопления данных. Это легче, потому что ODS обычно не делает истории. Историческое состояние прослежено в схемах "звезда", где это намного легче сделать, чем с нормализованными структурами. Нормализованное или snowflaked Хранилище Рабочих данных отражает 'текущее' состояние и не придерживается исторического взгляда свыше никого, который свойственен от данных.
процессы загрузки ODS касаются очистки данных и приспосабливания, которое легче сделать с нормализованной структурой. Как только у Вас есть достоверные данные в ODS, размер и загрузки факта могут отследить историю (изменения со временем) с универсальными или относительно простыми механизмами относительно просто; это намного легче сделать со схемой "звезда", инструменты Many ETL (например), предоставляют встроенные средства для того, чтобы медленно измениться, размеры и реализовать универсальный механизм относительно просто.
Разделение на уровни системы таким образом providies разделение обязанностей - бизнес и данные с очистительной логикой имеют дело в ODS и соглашении о загрузках схемы "звезда" с историческим состоянием.
Схемы "звезда" используются для включения высокоскоростного доступа к большим объемам данных. Высокая производительность включена путем сокращения суммы соединений, необходимых к satsify любой запрос, который может быть сделан против предметной области. Это сделано путем разрешения избыточности данных в таблицах измерений.
необходимо помнить, что схема "звезда" является шаблоном для верхнего слоя для склада. Все модели также включают схемы подготовки у основания складской стопки, и некоторые также включают персистентный преобразованный объединенный район сосредоточения войск, где все исходные системы объединяются в смоделированную схему на 3 нФ. Различные предметные области находятся выше этого.
Альтернативы схемам "звезда" на верхнем уровне включают изменение, которое является схемой "снежинка". Новый метод, который может подтвердить некоторое расследование также, Хранилище Данных, Моделируя предложенный Dan Linstedt.
Вещь о схемах "звезда", они - естественная модель для видов вещей, которые большинство людей хочет сделать с хранилищем данных. Например, легко представить отчеты с разными уровнями гранулярности (месяц или день или год, например). Также эффективно вставить типичные бизнес-данные в схему "звезда", снова общая и важная функция хранилища данных.
, конечно, можно использовать любой вид базы данных, которую Вы хотите, но если Вы не знаете свой бизнес-домен очень хорошо, вероятно, что Ваши отчеты не будут работать так эффективно, как они могли, если Вы использовали схему "звезда".
Схемы "звезда" являются естественным пригодным для последнего слоя хранилища данных. Как Вы добираетесь существует другой вопрос. Насколько я знаю, существует два больших лагеря, те из Bill Inmon и Ralph Kimball. Вы могли бы хотеть посмотреть на теории этих двух парней, если/когда Вы решаете пойти со звездой.
кроме того, некоторые инструменты создания отчетов действительно как установка схемы "звезда". Если Вы заблокированы в определенный инструмент создания отчетов, который мог бы управлять тем, на что аукционный зал создания отчетов похож на Вашем складе.
Возможно обойтись без. Однако Вы сделаете жизнь трудной для себя - Ваша организация захочет использовать стандартные инструменты, которые живут сверху DWS, и те инструменты будут ожидать схему "звезда" - большое усилие будет потрачено, соответствуя человеку не на своем месте.
Большая оптимизация уровня базы данных предполагает, что у Вас есть схема "звезда"; Вы проведете много времени, оптимизируя и реструктурируя, чтобы заставить DB делать "правильную вещь" с Вашим не совсем звездообразным расположением.
Удостоверяются, что профессионалы перевешивают недостатки..
(Это кажется, что я был там прежде?)
-D
Star schema is a logical data model for relational databases that fits the regular data warehousing needs; if the relational environment is given, a star or a snowflake schema will be a good design pattern, hard-wired in lots of DW design methodologies.
There are however other than relational database engines too, and they can be used for efficient data warehousing. Multidimensional storage engines might be very fast for OLAP tasks (TM1 eg.); we can not apply star schema design in this case. Other examples requiring special logical models include XML databases or column-oriented databases (eg. the experimental C-store)).