Хороший вопрос.
Фон
Я внедрил одну очень большую и «сложную» банковскую базу данных, более 500 таблиц, для которой клиент купил BO. «Сложное» заключено в кавычки, потому что хотя я создал чистый 5NF (правильно нормализованный к 5NF) Rdb, и большинство разработчиков и опытных пользователей не сочли его «сложным», некоторые разработчики и пользователи сочли его «сложным». Первый консультант BO даже не смог создать работающую вселенную и перебил свой бюджет на один месяц. Второй консультант BO создал всю вселенную за 10 дней. Вся структура (одна 5NF Rdb; 5 приложений; одна вселенная; веб-отчеты) работала прекрасно.
Но в результате этого упражнения мне стало ясно, что, хотя Вселенная очень мощная, требуется лишь преодолеть препятствия ненормализованной базы данных или хранилища данных, в котором есть таблицы из множества разных исходных баз данных, которые затем необходимо рассматривать вместе как одну логическую таблицу. Первый консультант просто повторял то, к чему он привык, занимаясь своими техническими делами, и не понимал, что означает нормализованный БД. Вторая реализация заключалась в том, что для истинного (нормализованного) Rdb Вселенная BO просто не требуется.
Поэтому в следующем крупном банковском проекте, в котором Rdb составлял почти 120% от предыдущего Rdb, я посоветовал против BO и вместо этого купил Crystal Reports, намного дешевле. Он предоставил все отчеты, которые требовались пользователям, но у него не было возможности «нарезать кубиками» или куба данных на локальном ПК. Единственная дополнительная работа, которую я должен был сделать, - предоставить несколько представлений, чтобы облегчить «сложные» биты Rdb, все за несколько дней работы.
С тех пор я принимал участие в заданиях, использующих BO, и исправлял проблемы, но я не использовал XI (и его автоматически генерируемую вселенную). Конечно, преобладание простых инструментов отчетности и вообще избегание Вселенной, что было доказано много раз.
В общем, да, GUI запроса Qu (даже до XI) будет абсолютно считывать каталог Rdb напрямую, и вы можете создавать и выполнять любой отчет из этого, без юниверса. Ваш пример совсем не потеет. «Перекрестные ссылки» совсем не потеют. Нетехнические пользователи могут сами создавать и запускать такие отчеты. Я сделал множество из них, это занимает минуты. Иногда (например, для структур Supertype-Subtype) создание представлений еще более облегчает это упражнение.
Ваш вопрос
Выявляет проблемы, препятствующие этому.
То, что вы видите, это то, что у вас нет реляционной базы данных. Загрузка некоторых данных в контейнер, называемый «реляционная СУБД», не преобразует этот контент в реляционную базу данных.
- один аспект настоящего Rdb состоит в том, что все определения находятся в стандартном каталоге SQL ISO / IEC / ANSI.
- если наши «внешние ключи» отсутствуют в каталоге, то у вас нет внешних ключей, у вас нет ссылочной целостности, которая определяется и поддерживается сервером.
- вы, вероятно, также не имеете правил и проверочных ограничений; следовательно, у вас нет целостности данных, которая определяется и поддерживается сервером.
,
Принимая во внимание ваши комментарии по поводу изменения структуры "db". Очевидно, что вы не нормализовали данные.
- Если данные были нормализованы правильно, то структура не изменится.
- Конечно, структура будет расширена (добавлены столбцы; добавлены новые таблицы), но существующая структура сущностей и атрибутов не изменится, поскольку они были (а) правильно смоделированы и (б) нормализованы
- поэтому любой написанный код приложения или любой созданный BO Universe (и отчеты, созданные на его основе) не уязвимы для таких расширений Rdb; они продолжают весело бегать вместе.
Да, конечно, они не могут получить новые столбцы и новые таблицы, но при условии, что это является частью расширения; дело в существующей структуре, и все, что от нее зависело, стабильно.
Принимая во внимание ваш пример запроса. Это очевидное доказательство полного отсутствия нормализации: Student.ClassroomName - это денорализованный столбец. Вместо того, чтобы существовать один раз для каждого ученика, он должен существовать один раз для каждого класса.
- Я отвечаю только на ваш вопрос, но следует отметить, что отсутствие нормализации приведет ко многим другим проблемам, не связанным непосредственно с вашим вопросом: массовое дублирование данных; Обновить аномалии; отсутствие независимости между «базой данных» и «приложением» (изменения в одном будут влиять на другие); отсутствие целостности (данные и ссылки); отсутствие стабильности и, следовательно, проект, который никогда не заканчивается.
,
Поэтому у вас есть не только какая-то «структура», которая меняется почти ежедневно, у вас нет структуры в «структуре» того, что не меняется. Этот уровень постоянных изменений является классическим для стадии прототипа в проекте; оно еще не дошло до стадии разработки.
Если вы используете BO или автоматически сгенерированную вселенную, вам придется ежедневно автоматически генерировать вселенную. А затем ежедневно создавайте определение отчета. Пользователям может не понравиться идея повторной разработки Вселенной плюс их отчеты ежедневно. Обычно они ожидают этап проекта UAT, если не этап производства.
- если у вас есть внешние ключи, так как они находятся в каталоге стандартного SQL, BO найдет их
- если у вас нет внешних ключей, но у вас есть какое-то «отношение» между файлами, и какое-то соглашение об именах, из которого можно вывести такие «отношения», у BO есть флажок где-то в окне авто-генерации, которое будет "выводить внешние ключи из имен столбцов". Конечно, он найдет «отношения», которые вы, возможно, не предполагали.
- если у вас нет соглашений об именах, то BO ничего не сможет использовать для вывода таких «отношений». магия настолько велика, что продукт может ее выполнять
- и у вас все еще есть проблема изменения структуры, поэтому любая магия, на которую вы полагаетесь сегодня, может не сработать завтра.
Ответ
Бизнес-объекты, отчеты Crystal и все инструменты верхнего и нижнего уровня предназначены в основном для реляционных баз данных, которые находятся в стандартной СУБД SQL ISO / IEC / ANSI. это означает, что если определение есть в каталоге, они его найдут. У инструментов более высокого уровня есть различные дополнительные опции (это то, за что вы платите), чтобы помочь преодолеть ограничения нестандартного содержимого СУБД, кульминацией которого является Вселенная; но, как вам известно, для его реализации требуются значительные усилия и техническая квалификация.
Лучший совет, который я могу дать вам, - это найти квалифицированного модельера и смоделировать ваши данные; такой, что он стабилен, без дублирования, а ваш код стабилен и т. д .; таким образом, что простые (или сверхмощные) инструменты отчетов могут использоваться для (а) простого определения отчетов и (б) запуска этих определений отчетов без ежедневного изменения. Вы обнаружите, что «структура», которая меняется каждый день, не меняется. Что меняется ежедневно, так это ваше понимание данных.
Тогда ваше желание сбудется, отчеты могут быть легко определены пользователями один раз, "перекрестными ссылками" и всем без Вселенной, и они могут запускаться в любое время.
Материалы по теме
Это, ваш колледж или проект, не первый в юниверсе, который пытается (а) моделировать свои данные или (б) внедрить базу данных, реляционную или нет. Возможно, вас заинтересует работа, которую другие уже проделали в этой области, поскольку часто большая часть информации предоставляется бесплатно, чтобы избежать повторного изобретения колеса, особенно если в вашем проекте нет квалифицированного персонала. Вот упрощенная версия (они рады, что я опубликовал общую версию, но не полную версию для конкретного клиента) недавнего проекта, который я сделал для местного колледжа; Я написал Rdb, они написали приложение.
Упрощенная модель данных колледжа
Читатели, которые не знакомы со стандартом реляционного моделирования, могут найти нотацию IDEF1X полезным.
Ответ на комментарий
Чтобы было ясно. Сначала определение.
1) Реляционная база данных в хронологическом порядке, в контексте последних нескольких дней 2010 года, с более чем 25-летней общедоступной истинной реляционной технологией [более 35 лет труднодоступных использовать относительную технологию], для которой существует множество применимых стандартов, и использовать такие определения (вики не в состоянии предоставить эти определения из-за отсутствия технической квалификации у участников):
придерживается реляционной модели в качестве принципа
Нормализуется как минимум до третьей нормальной формы (вам нужно 5NF, чтобы полностью избежать дублирования данных и аномалий обновления)
соответствует различным существующим стандартам (в зависимости от конкретной области)
по модели квалифицированным и способным модельером
реализован в стандарте ISO / IEC / ANSI SQL (это декларативная ссылочная целостность и определения внешнего ключа; ограничения Rule и Check; домены; типы данных)
- открытая архитектура (будет использоваться любым приложением)
рассматривается как корпоративный актив существенной стоимости
и поэтому разумно защищены от несанкционированного доступа; целостность данных и ссылок; неконтролируемые изменения (незапланированные изменения, влияющие на других пользователей и т. д.).
Без этого вы не сможете насладиться мощью, производительностью, простотой изменения и простотой использования реляционной базы данных.
2) То, что это не так, это содержимое платформы СУБД. Слив неструктурированных или неорганизованных данных в контейнер, помеченный «Relational Database Engine», магическим образом не преобразует содержимое в метку контейнера.
Поэтому, если это разумно (не идеально, не на 100% стандартная жалоба), реляционная база данных, BO Universe определенно не обязана обращаться к ней и использовать ее в полной мере (ограничено только функциями инструмента отчета). ).
Если у него нет DRI (определения FK), и нет "определенных ключей" старого стиля * и нет соглашений об именах (из которых могут быть получены "отношения") и нет подходящих типов данных, тогда ни один инструмент отчетов (или человек) не сможет ничего найти.
Это не только определения ФК.
В зависимости от того, какие именно биты реляционной базы данных были реализованы в куче данных, и от возможностей инструмента отчетов (сколько стоит лицензия), некоторые возможности где-то в двух концах спектра, возможно. БО без Вселенной - лучший в своем роде инструмент для отчетов; их предмет Crystal Reports составляет около половины ворчания. Вселенная обязана предоставлять определения базы данных для не-базы данных.
Тогда возникает проблема дублирования. Представьте, что пользователь почувствует, когда узнает, что данные, через которые он наконец-то получил, через 3 месяца, оказываются дубликатами, которые никто не обновляет.
Определение объекта "База данных"
Если у вас есть неквалифицированные разработчики или конечные пользователи, внедряющие «таблицы» в «базу данных», тогда нет никаких ограничений для препятствий и противоречий, которые они создают для себя.(«Здесь у меня есть RDBMS, но контента нет; у меня есть BO, но не может; у меня есть шифрование, но я скопировал данные о заработной плате в пять мест, чтобы люди могли получитьна это, когда они забывают свой ключ шифрования ".) Каждый раз, когда я думаю, что видел предел безумия, кто-то отправляет вопрос на SO и снова учит меня, что нет предела безумия .
BO через соединение ODBC способно выполнять JOIN (перекрестную ссылку) без юниверса, если определен правильный FK?
(ODBC не имеет ничего общегос ним; он будет работать так же через собственное соединение или через браузер.)
В этот раз, правильно определены FK, да.Но цель моего длинного ответа - определить множество других факторов.
Это не вопрос BO или BO Universe, а "насколько безумны определения и дублирование пользователей".ФК могли работать иногда, а не другие;мог работать сегодня, а не завтра.