Введение в системы БД (542480), страница 216
Текст из файла (страница 216)
В первом случае автоматически поддерживается согласованность между данными базы и производными данными, поскольку и те, и другие обновляются в одной и той же транзакции. (Она может либо выполниться, либо не выполниться, но даже если транзакция завершится успешно, для сохранения согласованности может оказаться критически важным наличие в системе высокого уровня изоляции транзакций.) В последнем случае, вероятнее всего, устранение возможной несогласованности будет возложено на пользователя. В Впзмпжен и другой подход, при катарам вычивлвннпе значение является производным ат значений в нескпльких строках таи жв таблицы или даже в других таблицах. Однако в этом случае обновление одной строки.мажет навлечь абнавление лзнагих других строк, в частнпспт мажет очень негативно атразитьпя на операциях загрузки и абнавлення базы данных.
824 Часть 1г. Дополнительные аспекты Распространенные ошибки проектирования В этом подразделе мы вкратце прокомментируем ошибки проектирования в среде поддержки принятия решений, которые широко распространены на практике. ° Дублирование строк. Проектировщики систем поддержки принятия решений часто утверждают, что их данные просто не имеют уникальных идентификаторов, и поэтому допускается дублирование строк. В )5.3) и )5.6) подробно обьясняется, почему разрешение дубликатов является ошибкой. Здесь же мы просто отметим, что эта "необходимость" возникает иэ-за того, что физическая схема не являешься производной от логической схемы, которая, возможно, никогда и не создавалась. Также заметим, что в таком проекте строки часто имеют неоднородное значение, в особенности если в них присутствуют Х1ЛЛ.-значения.
Иначе говоря, не все строки являются экземплярами одного и того же предиката (см. раздел 3.4 главы 3, а также главу 18). Замечание. Иногда дубликаты допускаются преднамеренно, особенно если проектировщик использует обьектно-ориентированную среду (см. последний абзац в разделе 24.2 главы 24). ° Денормализация и связанные с ней действия. При необоснованном стремлении исключить соединения и тем самым сократить количество операций ввода-вывода проектировщики часто выполняют предварительные соединения таблиц, вводят различного рода производные столбцы и т.д.
Такая практика может быть приемлемой на физическом уровне, но только не тогда, когда все это проявляется на логическом уровне. ° Схемы типа "звезда". Схемы типа "звезда", или так называемые мнаэдмерные схемы, чаще всего возникают в результате попытки "предельно упростить" корректные методы проектирования. Однако от таких упрощений нельзя ожидать какого-либо выигрыша. В результате при росте базы данных часто снижается производительность и теряется гибкость, а разрешение возникающих трудностей посредством физического перепроектирования требует внесения изменений и в приложения, поскольку схемы типа "звезда" — это в действительности чисто физические схемы, хотя они и открыты для приложений. В общем случае проблема заключается в произвольной и необоснованной природе созданного проекта.
Замечание, Схемы типа "звезда" будут подробно рассматриваться в разделе 2 !.5. ° ХШ):значения. Проектировщики часто пытаются сберечь пространство, допуская наличие в столбцах Х!)!.!.-значений. Этот прием мозкет сработать, если столбец имеет тип данных переменной длины, а М!)! !.-значения на физическом уровне представляются пустыми строками. Однако в общем случае такие попытки будут неправильными.
Не только просто возможно (и желательно) проектировать так, чтобы избежать появления Х!Ш-значений !!8.20), но это часто и существенно выгоднее, поскольку в результате память используется более эффективно и достигается более высокая производительность операций ввода-вывода. ° Проектирование итсеовых таблиц. Логическое проектирование итоговых таблиц нередко игнорируется, вследствие чего возникают неконтролируемая избыточность и трудности с поддержанием согласованности данных в базе. В результате пользователи сталкиваются с затруднениями при интерпретации суммарных значений и формули- Глава 21, Поддержка принятия решений 825 ровке запросов с их участием.
Чтобы избежать подобных проблем, все итоговые таблицы, относящиеся к одному и тому же уровню обобщения (раздел 21.6), необходимо спроектировать так, как если бы они составляли отдельную базу данных. В этом случае определенные проблемы цикэического обповлекия могут быть решены посредством запрещения обновлений на уровне обобщенных данных и организации синхронизации итоговых таблиц исключительно на основе данных детального уровня. ° Миожествепкые пути доступа. Проектировщики систем поддержки принятия решений и их пользователи часто ошибочно говорят о "множественности путей доступа" к некоторым необходимым им данным, подразумевая, что одни и те же данные могут быть получены несколькими разными реляционными выражениями.
Иногда такие выражения действительно равносильны, как в случае, например, А г01К (В 301Ы С) и (й 101В В) 101В С (см. главу 17). Иногда они равносильны благодаря действию некоторого ограничения целостности (снова см. главу 17), а иногда на самом деле они оказываются вовсе не равносильными. Для иллюстрации последнего случая предположим, что таблицы А, В и С имеют общий столбец К. Тогда "путь следования по значениям в столбце К от й к В, а оттуда к С", определенно, ке то же самое, что "путь следования по значениям в столбце К напрямую от А к С".
Ясно, что в таких ситуациях пользователи могут быть поставлены в тупик. Они не знают, какое именно выражение необходимо применять и будут ли одинаковыми полученные результаты. Конечно, частично зта проблема может быть решена за счет дополнительного обучения пользователей. Еще часть проблемы можно решить за счет обеспечения правильной работы оптимизатора. Однако часть проблемы возлагается и на проектировщиков, которые разрешают избыточность в логической схеме и/или предоставляют пользователям непосредственный доступ к физической схеме, Следует отметить, что эта часть проблемы может быть решена только за счет правильного проектирования. В заключение отметим, что, по нашему мнению, многие затруднения при проектировании, якобы возникающие из-за специфических требований систем поддержки принятия решений, могут быть успешно преодолены в результате строгого следования правильному полходу.
В действительности большинство подобных проблем вызвано именно отказом от строгого следования правильному подходу, но, по правде говоря, зти затруднения часто усугубляются еще и проблемами, свойственными самому языку ЬО) . 21.4. Подготовка данных Многие из вопросов, связанных с системами поддержки принятия решений, в первую очередь, касаются задач получения и подготовки ланных. Эти данные следует извлечь из разных источников, очистить, преобразовать и консолидировать, после чего загрузить в базу данных поддержки принятия решений. Впоследствии загруженные данные должны периодически обновляться. Каждая операция засдуживает отдельного обсужденият. Рассмотрим каждую из них поочередно, а затем завершим раздел кратким обсуждением банков оперативных данных.
~ Отметим, между прочим, чта в этих операциях часто могли бы использоваться првимумзества обработки ка уровне множеств, свойственные реляционным системам, хотя на практике это происходит редко. Часть гг. дополнительные аспекты Извлечение данных Извлечение данных — это процесс выборки данных из оперативных баз данных и других источников. Для извлечения данных существует множество инструментов, включая утилиты, предоставляемые системой, пользовательские программы извлечения и коммерческие продукты извлечения данных (общего назначения).
В процессе извлечения обычно интенсивно используется система ввода-вывода, что может послужить помехой для выполнения критически важных операций. Поэтому извлечение данных часто осуществляется в параллельном режиме (т.е. как множество параллельно выполняемых подпроцессов) и на физическом уровне. Однако такое "физическое извлечение" может вызвать проблемы при последующей обработке, поскольку они могут сопровождаться потерей информации (особенно — данных о связях), которая представляется каким-либо физическим способом, например с помощью указателей или физической смежности. По этой причине программы извлечения иногда предоставляют средства зашиты такой информации с помощью полей последовательных номеров записей и замены указателей значениями внешнего ключа. Очистка данных Лишь немногие источники данных обеспечивают удовлетворительный контроль информации.
Вследствие этого, прежде чем данные будут введены в базу данных поддержки принятия решений, обычно требуется выполнить их очистку (как правило, это пакетная операция). Обычно очистка предусматривает заполнение отсутствующих значений, корректировку опечаток и других допущенных при вводе данных ошибок, определение стандартных сокрашений и форматов, замену синонимов стандартными идентификаторами и т.д. Данные, которые определяются как ошибочные и не могут быть исправлены, отбрасываются.
Замечание. Полученная при выполнении очистки информация иногла используется для выявления ошибок в источниках данных и последующего повышения качества содержащейся в них информации. Преобразование и консолидация данных После очистки данных полученная информация, скорее всего, еше не будет отвечать требованиям системы поддержки принятия решениИ и, следовательно, будет нуждаться в соответствующем преобразовании. Обычно данные подготавливаются в виде набора файлов, по одному файлу для каждой таблицы, определенной в физической схеме. Поэтому процедура преобразования данных будет предусматривать построчное разбиение или объединение исходных записей, как объяснялось в разделе 1.5 главы 1. Замечание. Ошибки, которые не были исправлены во время очистки, иногда всплывают в процессе преобразования данных. Как и при очистке, любая некорректная запись в общем случае отбрасывается.
Аналогичным образом информация об Ьшибках, полученная в холе преобразования данных, может использоваться для повышения качества источников данных. Процедура преобразования приобретает особую важность, когда необходимо слить данные, поступившие из нескольких разных источников. Этот процесс называется консолидацией. В таком случае любая неявная связь между данными из отдельных источников должна быть преобразована в явную путем введения явных значений. Кроме того, 827 Глава 21. Поддержка принятия решений если значения дат и времени связаны н имеют определенный деловой смысл, они должны быть проконтролированы и приведены в соответствие между отдельными источниками. Этот процесс называется синхронизацией времени.
По соображениям производительности операции преобразования часто выполняются параллельно. Они могут интенсивно использовать как систему ввода-вывода, так и центральный процессор. Замечание. Синхронизация времени может оказаться довольно сложной задачей. Предположим, например, что необхолимо найти средний доход от заказчика на одного продавца за квартал. Предположим также, что данные о доходах от заказчиков ведутся по финансовым кварталам в базе данных бухгалтерии, а данные о пролавцах, обслуживающих каждого заказчика, ведутся по календарным кварталам в базе данных отдела сбыта. Очевидно, что необходимо слить данные двух указанных баз.
Консолидация данных о заказчиках не сложна — она предусматривает простую проверку соответствия идентификаторов заказчиков. Однако вопрос синхронизации времени значительно сложнее. Мы можем вычислить доходы заказчика за финансовый квартал (из базы данных бухгалтерии), но мы не можем сказать, какие продавцы обслуживали каждого из заказчиков в конкретное время, как не можем определить доходы от заказчика за календарный квартал. Загрузка данных Разработчики СУБД придают большое значение эффективности операций загрузки данных. В нашем случае "операцию загрузки данных" разобьем на следующие этапы: а) пересылка преобразованных и консолидированных данных в базу данных поддержки принятия решений; б) проверка согласованности данных (т.е.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
