Теория и практика построения баз данных (1088289), страница 145
Текст из файла (страница 145)
Рассмотрим пример извлеченных данных, представленный в табл. 17А и 17.5. Одна таблица представляет собой выдержку из данных о заказах, а вторая— выдержку из данных о выписанных продавцам премиальных. Предположим, пользователь информационного хранилища хочет исследовать связь между эффективностью работы продавца и его премиальными. Как может показаться на первый взгляд, все, что для этого нужно сделать — это сложить суммы заказов каждого продавца н сравнить итоговый результат с суммой его премиальных. Эту задачу может выполнить следующий Бьг!.-код: 674 Глава 17.
Совместное использование данных предприятия Информационные хранилища 676 Поскольку данные извлекались из разных информационных систем, то неизвестно, согласованы ли они между собой по врелгени. Возможно, данные о заказах были достоверными ло состоянию на последнюю пятницу месяца, а данные о премиальных — на последний день месяца.
В данных нет ничею, что указывало бы на это различие, а в реальности о цсм может никто и не знать. Однако оно может оказать существенное влияние на результаты анализа. Кроме времени, различаться может также тил данных (домен). Рассмотрим табл. 17.6 и 17.7 н предположим, что требуется составить отчет о совокупных продажах по каждому региону. Для этого погрсбус гся следующий 5О1.-код: 5ЕЕЕСТТорговаяЗока.
5ия1(Соаокупкмепродажи) ГВОНРЕГИОН. ПРОДАВЕЦ ННЕНЕРЕГИОН.ТорговаяЗока = ПРОДАВЕЦ. ТорговаяЗока ВВООР ВУРЕГИОН Для приведенных на рисунке данных результатом запроса будет таблица с тремя строками, по одной на каждую из торговых зон НрУ, НЕ и СО. Поскольку ни зона 5Е, нп зона 5УУ не указаны в таблице РЕГИОН, опн не появились в соединении, и продажи из этих зон не будут учтены в результате. Скорее всего, в намерения пользователя входило нечто другое. Таблица 17.6. ПРОДАВЕЦ Номерпродаеца Регион Год Соеекулныепродежи Таблица 17.7. РЕГИОН ТоргоеаяЗона Менеджер Аллен Брэндлманн Кьюррид 1ЧИ/ НЕ 80 В реальности дело обстояло так; в период между 2000 и 2001 годами компания внесла изменения в карту торговых зон, объединив зоны 5Е и 5рУ в одну зону 50.
Соответственно, в строку 50 результата запроса следовало добавить суммы продаж всех продавцов из зон 5Е и 5рУ. Если выразить это в терминах теории баз данных, домены атрибутов ТорговаяЗона и Регион различаются. Домен атрибута Джонсон Ву 0'Коннор ркбернати Лопес Джонсон Ву 0'Коннор Абернати Лопес 80 мяч НЕ ЯЕ яуу 80 нуу НЕ 80 80 2000 2000 2000 2000 2000 2001 2001 2001 2001 2001 $175,988 $223,445 $337,665 $276,889 $334,557 $225,988 $276,445 $389,737 $362,768 $419,334 Интеграция средств Еше она серьезная проблема, связанная с информационными хранилшцами, касается интеграции разнообразных средств, необходимых пользователям для работы.
Парадигмы различных продуктов и категорий продуктов, как правило, различаготся. СУБД оперируют таблицами, средства 01 АР— кубами, программы обработки электронных таблиц — электронными таблицами, пакеты финансового планирования — планами и т. д. В результате пользовательские интерфейсы этих продуктов оказываются непохожими. Обучение пользователей работе с несколькими продуктами, принадлежащими к различным категориям, может потребовать существенных затрат, и зачастую у самих пользователей на это нет ни времени, ни желания. Еше более серьезную проблему представляет экспорт и импорт данных между лродуктамц из различных категорий.
Рассмотрим электронную таблилу. В ней содержатся данные по трем различным темам; отделы, менеджеры и сотрудники. Телефон- КодМенеджера Отделе Номер- Менеджер Отдела Номер- НмяСотрудника Сотрудника 232-1000 244-7788 232-1000 244-7788 1000 2000 3000 4000 Ву 0'Коннор Абернати Лопес 10 20 10 20 А47 087 А47 087 Мерфи Джоплин Мерфи Джоплин Чтобы импортировать зту таблицу в норыалпзованноьг ниде в базу данных, каждую тему нужно будет вынести в отдельные таблицы: СОТРУДНИК (Ноилс,р~ ..и с.ррр„„,л ро р,ротлллгн„.яо~„,,к„о,- ко Р рР Икккяжкр(йу ~~,т ф И р ЕЛ р зацию не проводить, результатом будет значительное дублирование данных, как описано в главе 5. Однако обычный пользователь базы данных, во-первых, не поймет, для чего требуется нормализация, а во-вторых, не будет знать, как ее выполнить.
Наконец, при совместном использовании продуктов от разных производителей зачастую трудно выявить источник возникающих проблем. Например, производитель продукта, из которого экспортируются данные, может считать, ТорговаяЗона — зто множество торговых зон на настоящий момент, а домен атрибута Регион — название торговой зоны, в которой была произведена продажа, на момент этой продажи. Для небольших объемов данных, как в табл. 17.4, 17.5, 17.6 и 17.7, эти проблемы имеют очевидньш характер.
Но когда таблицы содержат тысячи строк данных, такое несоответствие может ускользнуть от внимания аналитика, и принимаемые решения будет основываться на недостоверных данных. Для решения этой проблемы должны создаваться метаданные, оппсываюшие временные характеристики и домены исходных данных. Эти метаданпые должны быть легко доступными для пользователей информационного хранилища, а пользователей необходимо научить уделять серьезное внимание этим вопросам. 676 Глава 17. Совместное использование данных предприятия Информационные хранилища 677 что в некорректном экспорте-импорте виновата программа, осуществляющая импорт, а производитель этой програмлгы может заявлять прямо противоположное.
Поскольку у производителей нет ни опыта эксплуатации продуктов друг друга, ни желания способствовать использованию чужих решений, техническая поддержка может превратиться в кошмар. Отсутствие средств управления данными информационного хранилища Хотя есть множество продуктов и средств, предназначенных для извлечения информации из источников данных, и множество ориентированных на конечного пользователя средств анализа данных и создания запросов и отчетов, на настоящий момент наблюдается отсутствие средств управления самим информационным хранилищем.
Если бы информационное хранилище состояло только из выдержек из реляционных баз данных, а проблемы различия временных характеристик и доменов могли быть разрешены путем обучения и четкого определения процедур, задача управления ресурсами информационного хранилища была бы под силу коммерческим СУБД. В большинстве случаев, однако, это не так. Большая часть информационных хранилищ содержит выдержки не только из баз данных, но также из файлов, электронных таолиц, изображений и внешних источников данных. Поэтому управлять ресурсами информационного хранилища средствами одной только коммерческой СУБД невозможно, и организации, создающие информационное хранилище, вынуждены разрабатывать собственное программное обеспечение.
Обычно ядром такого программного обеспечения является СУБД, а штатный персонал информационного хранилища осуществляет реализацшо дополнительных возможностей и функций, необходимых для управления ресурсами хранилища. Другая, сходная проблема касается управления метаданныьш. Лишь в немногих СУБД возможности словарей данных отвечают потребностям информационного хранилища в сфере у~гравленця метаданными. Как уже говорилось, пользователям необходимо знать не только то, что содержится в информационном хранилище, но и происхождение данных, их временные характеристики, домены, предположения, сделанные при извлечении данных, и т. д. Персоналу информационного хранилища необходимо разрабатывать собственное программное обеспечение управления метаданными, дополняющее возможностн СУБД и других средств управления словарями данных.
Разработка программного обеспечения управления данными является сложным и дорогостоящим делом. Созданное программное обеспечение должно поддерживаться. Производители программ извлечения и анализа данных постоянно совершенству|от свои продукты, и для поддержки новых интерфейсов придется вносить изменения в собственное программное обеспечение. Более того, будут меняться и требования пользователей, что приведет к необходимости создания новых программ, которые нужно будет затем интегрировать в программное обеспечение управления информационным хранилищем. Особый характер требований Информационные хранилища предназначены для поддержки принятия управленческих решений. В то время как значительная часть принимаемых управленческих решений имеет стандартный и повторяющийся характер, многие решения имеют особенную природу.
Вопросы о том, следует ли объединить торговые зоны и склады. продавать определенную линию продуктов, внедрить новые стратегии интернет-продаж и маркетинга, не относятся к числу стандартных и возникающих регулярно. Компьютерные системы, подобно системам бюрократическим, неповоротливы и дороги в настройке, и наиболее эффективно они работают, когда потребности отвечают определенному шаблону.
Поэтому зти системы отлично выполняют такие задачи, как ввод заказов и бронирование мест. Сложнее разработать систему, которая бы оперативно приспосабливалась к нестандартному изменению требований и нужд, 1 аким образом, информационные хранилища успешнее всего работают в приложенгшх, где изменение требований следует определенному шаблону. Если новое требование сходно по структуре с предыдущим, например «консолидация серверной торговой зоны будет похожа на консолидапию южной торговой зоны», то информационное хранилигце сможет быстро приспособиться к этому требованию.
Если же нет, понадобятся значительные затраты времени, средств и усилий. Информационные лавки В связи с описанными выше неудобствами некоторые организации решили ограничить область охвата информационных хранилищ, чтобы взамен получить большую управляемость. Онфоригщионная лавка (нага шагг) — это то же информационное хранилище, но с более узкой направленностью. Информационные лавки могут быть ориентированы на определенный тип входных данных, конкретную бизнес-функцию, отдельную организационную единицу или некоторую географическую область. Ограничение содержимого ивформаццонной лавки определенным типом данных (например, базы данных и электронные таблицы) облегчает управление информационным хранилищем и потенциально позволяет использовать для этих целей обычную коммерческую СУБД.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
