Хороший вопрос.
Фон
Я реализовал одну очень большую и сложную банковскую базу данных, более 500 таблиц, для которой заказчик купил БО. Комплекс заключен в кавычки, потому что, хотя я создал чистую 5NF (правильно нормализованную до 5NF) RDB, и большинство разработчиков и опытных пользователей не сочли ее сложной, некоторые разработчики и пользователи сочли ее сложной. Первый консультант BO не смог даже создать работающую Вселенную и превысил отведенный ему месяц. Второй консультант БО создал всю Вселенную за 10 дней. Вся структура (одна 5NF RDB, 5 приложений, одна вселенная, веб-отчеты) работала прекрасно.
Но в результате этого упражнения мне стало ясно, что, хотя Вселенная очень мощная, от нее требуется только преодолеть препятствия ненормализованной базы данных или хранилища данных, в котором есть таблицы из множества разных исходных баз данных, которые то их нужно рассматривать вместе как одну логическую таблицу. Первый консультант просто повторял то, к чему он привык, занимаясь своим техничным делом, и не понимал, что значит Normalized db. Второе осознание заключалось в том, что BO Universe просто не требовался для истинной (нормализованной) RDB.
Поэтому в следующем крупном банковском проекте, в котором RDB составляла почти 120% от предыдущей RDB, я посоветовал отказаться от BO и вместо этого купил Crystal Reports, который был намного дешевле. Он предоставлял все отчеты, которые требовались пользователям, но у него не было возможности срезов и кубиков или куба данных на локальном ПК. Единственная дополнительная работа, которую мне нужно было сделать, это предоставить несколько представлений, чтобы облегчить сложные биты RDB, и все это за день работы.
С тех пор я участвовал в заданиях, использующих BO, и исправлял проблемы, но я не использовал XI (и его автоматически сгенерированную вселенную). Безусловно, перевес в сторону простых инструментов отчетности, и вообще избегание Вселенной, что многократно доказано.
В общем, да, графический интерфейс BO Query (даже до XI) будет абсолютно напрямую читать каталог RDB, и вы можете создать и выполнить любой отчет, который вы хотите, без юниверса. Ваш пример совсем не пот. Перекрестные ссылки вообще не проблема. Пользователи, не являющиеся техническими специалистами, могут сами создавать и запускать такие отчеты. Я сделал десятки таких, это занимает минуты. Иногда (например, для структур супертип-подтип) создание представлений еще больше упрощает это упражнение.
Ваш вопрос
Выявляет проблемы, которые мешают этому.
Сталкиваюсь с тем, что у вас нет реляционной базы данных. Помещение некоторых данных в контейнер, называемый реляционной СУБД, не преобразует это содержимое в реляционную базу данных.
- one aspect of a true RDB is that all definitions are in the ISO/IEC/ANSI standard SQL catalogue.
- если наших внешних ключей нет в каталоге, то у вас нет внешних ключей, у вас нет ссылочной целостности, которая определяется и поддерживается сервером.
- у вас, вероятно, также нет правил и контрольных ограничений; поэтому у вас нет целостности данных, которая определяется и поддерживается сервером.
Отмечая ваши комментарии относительно изменения структуры базы данных. Очевидно, вы не нормализовали данные.
- If the data was normalised correctly, then the structure will not change.
- Конечно, структура будет расширена (добавлены столбцы, добавлены новые таблицы), но существующая структура сущностей и атрибутов не изменится, потому что они были (а) правильно смоделированы и (б) нормализованы.
- поэтому любой написанный код приложения или любая созданная BO Universe (и созданные на ее основе отчеты) не уязвимы для таких расширений RDB; они продолжают весело бежать.
- Да, конечно, они не могут получить доступ к новым столбцам и новым таблицам, но при условии, что это часть расширения; дело в существующей структуре, и все, что от нее зависело, стабильно.
- Отмечая ваш пример запроса. Это на первый взгляд свидетельствует о полном отсутствии нормализации: столбец Student.ClassroomName является денормализованным столбцом. Вместо того, чтобы существовать один раз для каждого ученика, он должен существовать один раз для каждого класса.
- Я отвечаю только на ваш вопрос, но следует отметить, что отсутствие нормализации приведет ко многим другим проблемам, не связанным напрямую с вашим вопросом: массовое дублирование данных; Обновление аномалий; отсутствие независимости между базой данных и приложением (изменения в одном повлияют на другое); отсутствие целостности (данной и справочной); отсутствие стабильности и, следовательно, проект, который никогда не заканчивается.
Поэтому у вас есть не только какая-то структура, которая меняется почти ежедневно, у вас нет структуры в той структуре, которая не меняется. Этот уровень постоянных изменений является классическим для стадии прототипа в проекте; она еще не достигла стадии Развития.
Если вы используете BO или автоматически сгенерированную вселенную, вам придется ежедневно автоматически генерировать вселенную. Затем ежедневно заново создавайте определение отчета. Пользователям может не понравиться идея переделывать вселенную плюс их ежедневные отчеты. Обычно они ждут стадии UAT проекта, если не стадии производства.
- if you have Foreign Keys, since they are in the Standard SQL catalogue, BO will find them
- если у вас нет внешних ключей, но у вас есть какая-то связь между файлами и какое-то соглашение об именах, из которого можно вывести такие отношения, BO имеет флажок где-то в автоматическом создании окно, которое будет выводить внешние ключи из имен столбцов. Конечно, он найдет отношения, которые вы, возможно, не планировали.
- если у вас нет соглашений об именах, то BO ничего не может использовать для вывода таких отношений. есть только так много волшебства, которое может выполнить продукт
- и у вас по-прежнему есть проблема с постоянно меняющейся структурой, поэтому любая магия, на которую вы полагаетесь сегодня, может не сработать завтра.
Ответить
Business Objects, отчеты Crystal и все инструменты отчетов высокого и низкого уровня в основном написаны для реляционных баз данных, которые находятся в стандартной СУБД SQL ISO/IEC/ANSI. это означает, что если определение есть в каталоге, они его найдут. Инструменты более высокого класса имеют различные дополнительные опции (это то, за что вы платите), чтобы помочь преодолеть ограничения нестандартного содержимого СУБД, кульминацией которых является Вселенная; но, как вы знаете, для реализации требуется немало усилий и технической квалификации.
Поэтому лучший совет, который я могу вам дать, — это найти квалифицированного специалиста по моделированию и смоделировать ваши данные; чтобы он был стабильным, без дублирования, и ваш код был стабильным и т.д. и т.п.; таким образом, простые (или мощные) инструменты отчетов могут использоваться для (а) простого определения отчетов и (б) запуска этих определений отчетов без их ежедневного изменения. Вы обнаружите, что структура, которая меняется ежедневно, не меняется. Что меняется ежедневно, так это ваше понимание данных.
Тогда ваше желание сбудется, отчеты можно будет легко определить один раз, пользователями, перекрестными ссылками и всем остальным, без юниверса, и их можно будет запускать в любое время.
Похожий материал
Это ваш колледж или проект не первый во вселенной, который пытается либо (а) смоделировать свои данные, либо (б) внедрить базу данных, реляционную или нет. Вас может заинтересовать работа, которую другие уже проделали в этой области, так как часто много информации доступно бесплатно, чтобы не изобретать велосипед, особенно если в вашем проекте нет квалифицированного персонала. Вот упрощенная версия (они рады, что я опубликую общую версию, но не полную версию для конкретного клиента) недавнего проекта, который я сделал для местного колледжа; Я написал RDB, они написали приложение.
Упрощенная модель данных колледжа< /сильный>
Читатели, не знакомые со стандартом реляционного моделирования, могут найти Нотация IDEF1X полезная.
Ответ на комментарии
Чтобы было понятно тогда. Сначала определение.
- Реляционная база данных представлена в хронологическом порядке в контексте последних нескольких дней 2010 года с более чем 25 летами общедоступной настоящей реляционной технологии [более 35 лет сложной в использовании реляционной технологии]. , для которых существует множество применимых стандартов, и с использованием таких определений (Википедия не может предоставить указанные определения из-за отсутствия технической квалификации у участников):
придерживается реляционной модели как принципа
Нормализован как минимум до третьей нормальной формы (вам нужно 5NF, чтобы полностью избавиться от дублирования данных и аномалий обновления)
соответствует различным существующим стандартам (применительно к каждой конкретной области)
смоделирован квалифицированным и способным моделистом
реализован в стандарте SQL ISO / IEC / ANSI (это декларативная ссылочная целостность аля определения внешнего ключа; правила и ограничения проверки; домены; типы данных)
это открытая архитектура (для использования любым приложением)
рассматривается как корпоративный актив, имеющий значительную стоимость
и, следовательно, достаточно защищены от несанкционированного доступа; данные и ссылочная целостность; неконтролируемое изменение (незапланированные изменения, затрагивающие других пользователей и т. д.).
Без этого вы не сможете насладиться мощью, производительностью, простотой изменения и простотой использования реляционной базы данных.
- Что это не так, так это содержимое платформы РСУБД. Помещение неструктурированных или неорганизованных данных в контейнер с меткой Relational Database Engine не приводит к волшебному преобразованию содержимого в метку контейнера.
Следовательно, если это разумно (не идеально, не на 100% стандартная жалоба) реляционная база данных, BO Universe определенно не требуется доступ и использование ее всех возможностей (ограниченных только функциями инструмента отчета).
Если у него нет DRI (определений FK), и нет ключей, определенных в старом стиле, и нет соглашений об именах (из которых могут быть получены отношения) и нет совпадающих типов данных, то ни один инструмент отчета (или человек) не сможет ничего найти.
Это не просто определения FK.
В зависимости от того, какие именно биты реляционной базы данных были реализованы в куче данных, и от возможностей инструмента создания отчетов (сколько стоит лицензия), некоторые возможности где-то в пределах двух концов спектра, возможно. BO без Universe — лучший инструмент для создания отчетов; их элемент Crystal Reports примерно вдвое меньше. Universe требуется предоставить определения базы данных для не-базы данных.
Затем возникает проблема дублирования. Представьте, что почувствует пользователь, когда обнаружит, что данные, до которых он, наконец, дошел через 3 месяца, оказались дубликатом, который никто не поддерживает в актуальном состоянии.
Определение объекта базы данных
Если у вас есть неквалифицированные разработчики или конечные пользователи, реализующие таблицы в базе данных, то препятствиям и противоречиям, которые они сами себе ставят, нет предела. (Здесь у меня есть СУБД, но нет контента; у меня есть BO, но он не может; у меня есть шифрование, но я скопировал данные платежной ведомости в пять мест, чтобы люди могли получить это когда они забывают свой ключ шифрования.) Каждый раз, когда я думаю, что увидел предел безумия, кто-то публикует вопрос на SO и снова учит меня, что безумию нет предела.
BO через соединение ODBC может выполнять JOIN (перекрестную ссылку) без Universe, если определены правильные FK?
(ODBC здесь ни при чем, он будет работать одинаково через родное соединение или через браузер.)
В тот раз, когда FK определились правильно, да. Но цель моего длинного ответа состоит в том, чтобы выявить множество других факторов.
Это не вопрос BO или BO Universe, это просто то, насколько безумны определения и дублирование пользователей. ФК иногда могли работать, а другие нет; может работать сегодня, а не завтра.
person
PerformanceDBA
schedule
25.12.2010
