курсовая. 4 Лекция Базы данных 22. Вопросы проектирования баз данных
 Скачать 223.53 Kb.
|
|
ВОПРОСЫ ПРОЕКТИРОВАНИЯ БАЗ ДАННЫХ 1. Жизненный цикл информационной системы Как и любая другая, информационная система проходит во времени свой определенный жизненный цикл. В зависимости от целей исследования, в жизненном цикле БД можно определить различные последовательности этапов. С точки зрения проектировщика и пользователя согласно [2] выделим две фазы жизненного цикла базы данных: • анализ и проектирование - начальный (“бумажный”) этап жизни БД. • реализация и эксплуатация системы. Анализ и проектирование. Этап выполняется посредством изучения предметной области и требований, предъявляемых к создаваемой БД. На “бумажной” стадии жизни системы производится выбор: • структур данных и стратегии их хранения в памяти ЭВМ, • технологии обслуживания БД и взаимодействия с ней конечных пользователей, • технических и стандартных программных средств, а также разработка оригинальных программных средств обслуживания системы. Реализация и эксплуатация. Сущность реализации заключается в материализации проекта, в перенесении его в память ЭВМ. На этой стадии разрабатывается и отлаживается программное обеспечение информационной системы, создается отладочный вариант БД. разрабатываются многочисленные приложения. На стадии реализации тестируется и корректируется технология обслуживания информационной системы. Эксплуатация начинается с наполнения системы реальной информацией. Эта стадия жизненного цикла охватывает весь комплекс действий по поддержанию функционирования информационной системы: Очевидно, что стадия эксплуатации включает в себя разработку новых приложений, а также совершенствование и последующее развитие системы. Методы построения моделей. Учитывая, что главной целью данного пособия является знакомство читателя с основными подходами к организации процесса проектирования базы данных как модели предметной области, а основными методами изучения реальности являются методы анализа и синтеза, определим аналитический (метод анализа) и синтетический (метод синтеза) следующим образом. В процессе анализа определяется структура системы, т.е. то, как она устроена. Процедура анализа состоит в последовательном выполнении следующих трех операций: 1. Сложное целое расчленить на более мелкие части, предположительно более простые. 2. Дать полное объяснение полученным фрагментам. 3. Объединить объяснение частей в объяснение целого. Если какая-то часть системы остается непонятной, шаги анализа осуществляются для этой части. Первым продуктом анализа является перечень элементов системы, т.е. модель состава системы. Объяснение целого — это установление его эмерджентных свойств: для этого необходимо установить связи между7 частями. Таким образом, вторым продуктом анализа является модель структуры системы. В процессе синтеза определяется функционирование системы, т.е. ее взаимодействие со средой. Процедура синтеза включает последовательное выполнение трех операций: 1. Выделение большей системы (метасистемы), в которую моделируемая система входит как часть. 2. Рассмотрение состава и структуры метасистемы. 3. Объяснение роли, которую играет моделируемая система в метасистеме, через ее связи с другими частями метасистемы. Конечным продуктом синтеза является знание связей моделируемой системы с другими частями метасистемы, т.е. модель черного ящика. Очевидно, чтобы построить модель черного ящика, необходимо попутно создать модели состава и структуры метасистемы как побочные продукты. Объединение трех моделей в единое целое позволяет сформировать модель белого (прозрачного) ящика. или структурную схему системы. Применение описанных процедур будет рассмотрено ниже при обсуждении этапов проектирования базы данных. 2. Процесс проектирования 2.1. Организационный аспект В роли заказчика, то есть основного носителя сведений о предметной области и требований об информационной системе, при проектировании выступают: - администратор предметной области (.АПО), - администраторы фрагментов предметной области. - коллективы конечных пользователей. .АПО открыта перспектива всей организации (предприятия, банка, вуза, фирмы и т.д.) и он, как правило, совместно с руководителями подразделений (фрагментов ПО) решает вопрос о необходимых ресурсах для эффективного функционирования организации. Поскольку целью создания базы данных, очевидно, является создание информационного хранилища для разрабатываемой автоматизированной информационной системы организации, деятельность .АПО в конечном счете направлена на обеспечение адекватности проекта базы данных интегральным информационным потребностям приложений (прикладных программ), реализующих соответствующие бизнес-процессы. Замечание. Под бизнес-процессом можно понимать связанную совокупность бизнес-функций, в ходе выполнения которой потребляются определенные ресурсы и создается продукт (предмет, услуга и т.д.), представляющий ценность для потребителя. Общение с конечными пользователями позволяет учесть в разрабатываемой модели специфику ПО. проблемы низшего звена организации-заказчика. Группу' проектировщиков возглавляет администратор базы данных (АБД) - специалист по информационным системам. Учитывая, что АБД может не быть специалистом в ПО, ему в помощь организуется группа аналитиков (консультантов), стыкующих (согласующих) работу разработчиков и конечных пользователей. Естественным представляется включение в группу проектировщиков системных программистов и разработчиков приложений. .Администратор баз данных реализует процессы детального планирования и проектирования. Он осуществляет анализ и синтез данных для каждой создаваемой базы данных. .АБД необходимо, чтобы администраторы-заказчики подробно рассмотрели каждую БД с целью сделать ее как можно стабильнее. Все многообразие задач, выполнение которых возлагается на -АБД, можно разделить в соответствии с этапами жизненного цикла БД (для полноты перечислим все этапы жизненного цикла, не ограничиваясь только этапом проектирования). Анализ и проектирование: • работа с заказчиками для установки реальных целей и требований к прикладным программам и базам данных, • управление процессами логического и физического проектирования. • выбор связанного с БД программного обеспечения п оборудования. • долгосрочное планирование, в том числе в определении перспектив расширения БД. Реализация: • реализация проекта инструментальными средствами выбранной СУБД, • создание отладочного варианта БД, • разработка и отладка программного обеспечения информационной системы, • разработка приложений, • тестирование и коррекция технологии обслуживания информационной системы. Эксплуатация и использование: • управление процессами включения новых данных в базу и внесения изменений. • разработка и контроль действий, гарантирующих сохранение целостности БД. включая процедуры ее копирования и восстановления после сбоев, • организация защиты БД с помощью механизмов управления доступом и средств СУБД, • введение стандартов на содержимое и использование БД, • сопровождение специальных средств программного обеспечения для работы с БД (словари-справочники данных, языки запросов). • проведение консультаций пользователей БД. С другой стороны, рассмотренные задачи можно разделить на два класса: • административные и технические, • прикладные и системные. .АБД, таким образом, является лицом, ответственным за достоверность и полноту данных, содержащихся в БД. их согласованность, а также за соблюдение регламента работ по актуализации БД. 2.2. Задачи и структура процесса проектирования Проектирование базы данных - одна из наиболее сложных и ответственных задач, связанных с созданием информационной системы. В результате ее решения должны быть определены содержание БД, эффективный для всех ее будущих пользователей способ организации данных и инструментальные средства управления данными. Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям: • Корректность схемы БД, а именно: - каждому объекту ПО соответствуют данные в памяти ЭВМ, - каждому' процессу ПО соответствуют адекватные процедуры обработки данных. • Обеспечение целостности: - формулировка ограничений, - описание правил применения ограничений. - описание правил обработки данных при нарушении ограничений целостности. • Зашита данных: - защита от разрушений при сбоях оборудования (восстанавливаемость данных), - от некорректных обновлений (согласованность методов модификации данных), - от несанкционированного доступа (безопасность данных). • Обеспечение ограничений на аппаратные и программные ресурсы вычислительной системы. • Эффективность функционирования: - эффективность использования ресурсов, - обеспечение требований ко времени реакции системы на запросы и обновление БД. • Простота и удобство в эксплуатации. • Гибкость - возможность развития и последующей адаптации системы к изменениям в ПО и к новым потребностям пользователей. Удовлетворение первых 4-х требований обязательно для принятия проекта. В структуре процесса проектирования выделим следующие этапы: Этап 1. Формулировка и анализ требований, включающий: Шаг 1. Сбор и анализ априорной информации о ПО, Шаг 2. Анализ и синтез инфологической модели ПО. Этап 2. Проектирование концептуальной схемы. Этап 3. Физическое проектирование. На каждом из этапов решаются следующие основные задачи. Этап 1. Шаг 1. Устанавливаются цели организации, определяются специфические требования к БД. вытекающие из этих целей или сформулированные непосредственно управляющим персоналом организации. Эти требования документируются в форме, доступной как конечном}- пользователю, так и проектировщику БД. Специфические цели и требования к БД необходимо определить на самом высоком уровне организации-заказчика (уровень АПО). Собранные и документированные требования должны включать ограничения, обусловливающие: - безопасность, - надежность, - уровень достигнутой технологии. - политические и бюрократические ограничения. Должна быть также оценена политика организации в отношении персонала, управленческой деятельности и перспектив роста организации. Шаг 2. Описываются и анализируются разнообразные информационные требования пользователей и производится синтез первоначального проекта базы данных. Результатом этого этапа является «бумажное» высокоуровневое представление требований в виде, например. ER-модели (модели сущность-связь»). На этом этапе осуществляется: - определение сущностей, - определение атрибутов сущностей, - идентификация ключевых атрибутов сущностей, - определение связей между сущностями. Требования каждого пользователя анализируются и представляются в некоторой обшей форме. Объекты и события, ассоциированные с представлениями каждого пользователя, моделируются множеством сущностей, атрибутов и связей между7 сущностями. Эти требования, представленные, например, набором локальных ER- моделей, анализируются и сливаются в единое глобальное представление. Очевидно, что в процессе анализа должны быть выявлены и ликвидированы противоречивые и избыточные данные. Этап 2. После построения первоначальной информационной структуры следует ее уточнение и совершенствование. Главная цель - создание СУБД-ориентированной концептуальной схемы с использованием в качестве исходных данных результатов инфологического проектирования и требований обработки данных. На данном этапе проектируются также многочисленные приложения. Результатом проектирования программного обеспечения являются: • интерфейсы приложений. • функциональные характеристики приложений. • наборы возможных запросов к БД, Построенная схема может быть оценена количественно с помощью таких характеристик, как: • число обращений к логическим записям каждого приложения. • объем обрабатываемых в каждом приложении данных, • общий объем хранимых данных. Эти опенки помогают приблизительно определить эффективность функционирования физической БД в терминах затрачиваемого на обработку времени и требуемой физической памяти. Этап 3. Рассмотрению вопросов физического проектирования базы данных посвящена отдельная глава данного пособия. Здесь лишь отметим, что параметры внутренней (физической) модели БД принципиальным образом влияют на эксплуатационные характеристики информационной системы. Процесс проектирования хорошо структурирован, так как каждый его этап завершается четко определенным результатом, и допускает итеративное повторение в случае, если полученный результат не соответствует требованиям заказчиков или сформулированным ограничениям, либо если возникают дополнительные требования. В общем случае это позволяет проектировщику пересматривать проектные решения с любого предыдущего этапа. Схема метода нисходящего (каскадного) проектирования с последовательными итерациями представлена на рисунке ниже. Прямой и итеративный варианты в каскадной методологии 2.3. Формулирование и анализ требований. Мифологическое проектирование Шаг 1. Сбор и анализ априорной информации о ПО Проектирование базы данных — это процесс разработки ее структуры в соответствии с информационными требованиями пользователей, поэтому он включает в себя опрос будущих пользователей для того, чтобы понять и задокументировать их требования. АБД следует выяснить следующие вопросы: • что представляют собой требования пользователей; в какой форме они могут быть выражены; • как требования пользователей могут быть преобразованы в эффективную структуру базы данных; • какие данные используются разными приложениями; смогут ли приложения совместно использовать какие-либо из этих данных; • сможет ли новая система объединить существующие приложения или их необходимо будет кардинально переделывать для совместной работы с новой системой; • кто будет вводить данные в базу и в какой форме; как часто будут изменяться данные; • достаточно ли будет для ПО одной базы или потребуется несколько баз данных с различными структурами; • какая информация является наиболее чувствительной к скорости ее увлечения и изменения; • как часто и каким образом структура базы данных должна перестраиваться в соответствии с новыми и/или изменяющимися требованиями. На этом шаге осуществляется: 1. Определение сферы применения. 2. Сбор информации об использовании данных. 3. Преобразование информационных требований. Рассмотрим каждый из этих пунктов подробнее. Пункт 1. Определение сферы применения баз данных как в настоящем, так и в будущем Лучшим источником такой информации является информационная схема организации. Пример. Фрагмент информационной схемы и системных зависимостей Используя подобную схему в качестве основы, можно определить бизнес-функции и бизнес-процессы, которые следует рассмотреть в рамках проекта. Если информационная схема в организации отсутствует или эта схема не содержит диаграммы зависимостей данных и задач, определение сферы применения проекта возлагается на АБД. Другой фактор, который необходимо принимать во внимание при определении сферы применения - возможные в будущем изменения в деятельности организации. Если обнаружится, что будущие изменения могут оказать воздействие на БД, сфера применения проекта должна быть расширена с тем, чтобы учесть влияние возможных изменений. Пункт 2. Сбор информации об использовании данных. Для полноты обсуждения данного пункта заметим, что информацию об использовании данных можно разделить на два вида: 1. информация, связанная с производственными функциями. 2. информация, связанная с функциями управления. Производственные функции организации. Собранная информация о производственных функциях и об использовании данных является основной исходной информацией процесса проектирования базы данных. Поэтому достоверность и полнота собранной информации являются чрезвычайно важными факторами. Для каждой производственной функции у руководителей подразделении выявляется: - наименование работы, - выполняемая функция. - цель выполняемой работы. Функции управления. На этом шаг определяются: - функции контроля и планирования и требуемые для выполнения этих функций данные. - предположения о возможных изменениях в деятельности организации в будущем. Информация об управляющих функциях должна быть определена путем консультаций с высшим руководством - АПО. В этих обсуждениях АБД должен получить общее представление о следующих вопросах: • основные компоненты деятельности и их взаимодействие друг с другом, то есть вопросы взаимодействия различных фрагментов ПО. • внутренняя среда, включающая: - структуру организации, - правила и политику, определяющие повседневную деятельность. • внешняя среда, прямо или косвенно влияющая на деятельность организации (законодательные органы, рынки сбыта и т.п.), • информация, требуемая для планирования деятельности. • виды информации, используемой для контроля и оценки функционирования. • предполагаемые изменения, которые могут влиять на род или сферу деятельности, либо на способы ведения деятельности. Пример. Выявленная информация о производственных и управленческих функциях может быть задокументирована (представлена) в следующем виде. Наименование работы Функция Цель Комплектация заказов 1) Комплектация товаров со склад; соответствии с заказом Выполнение заказов клиентов Планирование запасов товаров 1) Покупка товаров Поддержка запаса товаров Управление запасами товаров 2) Определение оптимального количества товар и времени для их закупки Минимизация капиталовложения при создании запаса товаров Прием заказов 1) Выписка заказа Прием заказа клиента 1) - основная (производственная) функция, 2) - функция управления. Идентификация производственных задач и задач управления. На этом шаге определяются связи между выявленными функциями и необходимыми для их реализации данными. Здесь функцию определим как самый низкий уровень деятельности, который многократно использует уникальный набор данных. Выделяются следующие характеристики функции: • Это уникальная единица деятельности, состоящая из набора последовательно выполняющихся шагов (операций). • все шаги направлены на достижение одной и той же цели, • на каждом шаге создается или используется один и тот же (уникальный) набор данных. Связь между функцией и данными можно определить как уникальную связь, возникающую между элементами данных при их использовании. Пункт 3. Преобразование информационных требований Процесс преобразования информации, собранной во время собеседований, в форму, используемую при дальнейшем анализе, включает следующие основные шаги: 1. Составление списка всех используемых и создаваемых элементов данных. 2. Определение всех производственных функций, их характеристик и используемых данных. 3. Определение всех функций управления, их характеристик и используемых данных. 4. Составление списка всех явных и неявных правил и линии поведения в управлении деятельностью организации. 5. Составление списка возможных будущих изменений и путей их влияния на деятельность организации. Пример. Список элементов данных может выглядеть следующим образом. Идентификатор Наименование Определение 1 Номер заказа Однозначно определяет каждый заказ 2 Заказанное количество Определяет количество одного вида товара, заказанного одним клиентом Сформированный список элементов данных служит основанием для создания словаря элементов данных. Первичные метаданные (описания и определения данных, то есть данные о данных) необходимы для построения и уточнения инфологической модели, используемой в дальнейшем в качестве обшей основы для сбора и анализа других метаданных. Без такой основы собранные метаданные едва ли будут достаточно надежными: количество метаданных может оказаться больше, чем необходимо, а их структура может оказаться недостаточно эффективной для выявления ошибок. Предполагается, что приложения определяются независимо друг от друга либо аналитиками, либо специалистами ПО. Каждое подразделение решает свои задачи вне каких-либо внешних ограничений. Это означает, что каждая отдельная функция обработки данных будет определена в рамках локального представления данных без учета представлений пользователей других приложений. Таким образом, во время общего анализа требований должны быть определены элементы данных и их связи, которые будут уточняться на последующих этапах проектирования. Здесь же должны быть, по крайней мере, обнаружены все конфликтные ситуации. Дело в том, что представления пользователей о данных и их обработке не всегда могут служить прообразом окончательной структуры базы данных; они .тишь устанавливают формальную основу для накопления метаданных. Интеграция представлений осуществляется на следующих этапах проектирования. Итак, первый шаг предполагает: • сбор данных (результатов измерений, наблюдений, отчетов, документов научно- технического, технико-экономического, бухгалтерского и т.п. характера, опроса экспертов -специалистов в данной предметной области), • выявление перечня задач, которые могуч быть решены с использованием разрабатываемой БД, • содержательный анализ собранной информации. Целью содержательного анализа собранной информации является: • устранение дублирования данных, • выявление и устранение противоречивости данных и неоднозначности их определений и описаний. • выявление и формулирование правил поведения и принятия решений в соответствии с описаниями ситуаций, • выявление возможных изменений в будущем и их влияния на правила поведения и т.п. Другими словами, на этом этапе происходит “погружение” АБД в предметную область и проблемную среду. Именно на этом этапе формулируются цели создания БД. Выходом первого этапа очевидным образом является: • описание целей создания БД, • описание входной и выходной информации, • модель состава системы. Содержательный анализ собранной информации позволяет определить возможные динамические свойства создаваемой модели. Шаг 2. Анализ данных и синтез инфологической модели Общая схема построения инфологической модели предметной области с учетом целей конечных пользователей и информационных требований приложений изображена на рисунке ниже. В этой схеме предусмотрено построение инфологической модели путем объединения информационного описания предметной области (ПО-информация) и информационных требований прикладных программ (ПП- информация). Следовательно, в инфологической модели объединяются два представления: • объективно существующей ПО. • субъективных информационных требований прикладных программистов, выраженных в запросах к базе данных, запланированных в приложениях. ПО- информация отображает объекты (процессы, явления, предметы) реального мира как составные части ПО (элементы ПО), их существенные свойства, а также взаимосвязи между этими элементами. Эта ПО-информация не связана ни с конкретными приложениями, ни с конкретным способом обработки, а описывает естественные концептуальные связи всех данных в БД. ПП- информация описывает данные и связи, используемые в приложениях. В общем случае в методологии построения инфологических моделей ПО- информация должна использоваться для построения первоначальной инфологической модели данных, а ПП-информация - для совершенствования последней с целью повышения эффективности обработки данных. Общая схема инфологического проектирования Без включения ПО-информации созданная БД обеспечивает, в лучшем случае, лишь объединение нескольких пользователей, занятых формированием собственных файлов. Далее в результате анализа собранной информации (в виде первоначальной инфологической модели и выявленной ПП-информации) определяются объекты ПО, их свойства и взаимосвязи, которые необходимо смоделировать в базе данных. Таким образом, в результате сбора и анализа информации о ПО осуществляется: • идентификация функциональной деятельности предметной области, • идентификация объектов, которые осуществляют эту функциональную деятельность, • идентификация всех сущностей и взаимосвязей между ними. • идентификация характеристик этих сущностей. • идентификация взаимосвязей между сущностями и их типов. На основе результатов анализа проводится окончательный синтез структуры инфологической модели, то есть формируется структурная модель БД. Очевидно, что на этом шаге проектирования реализуется свойство эмерджентностп создаваемой модели. Итак, начальной стадией проектирования системы базы данных является разработка модели предметной области, которая базируется на анализе информационных потребностей будущих пользователей разрабатываемой системы. Определение ПО-информация Анализ ПО-информация Выявление ПП-информация Анализ ПП-информация Рассмотрим основные подходы к созданию инфологической модели предметной области. Функциональный подход к проектированию БД Этот метод является наиболее распространенным. Он реализует принцип «от задач» и применяется в том случае, когда известны функции некоторой группы лиц и/или комплекса задач, для обслуживания информационных потребностей которых создается рассматриваемая БД. Предметный подход к проектированию БД Предметный подход к проектированию БД применяется в тех случаях, когда у разработчиков есть четкое представление о самой ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена или определена не полностью. Тогда основное внимание уделяется исследованию ПО и наиболее адекватному ее отображению в БД с учетом самого широкого спектра информационных запросов к ней. Проектирование с использованием метода «сущность-связь» Этот метод является комбинацией двух предыдущих и обладает достоинствами обоих. Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает ее на ряд локальных областей, каждая из которых (в идеале) включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, а затем выполняется их объединение. Выбор локального представления зависит от масштабов ПО. Обычно ПО разбивается на локальные области таким образом, чтобы каждая из них соответствовала отдельному внешнему приложению. Заметим, что выбор сущностей (т.е. объектов, о которых в системе будет накапливаться информация) в отдельных случаях может оказаться затруднительным, поскольку порция информации может быть представлена как сущность, атрибут или связь. Например, информацию об ЭКЗАМЕНЕ можно оформить как: • отдельную сущность, • как атрибут сущности СЕССИЯ, • как связь между сущностями СТУДЕНТ, ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА. Поэтому рекомендуется проработать несколько вариантов, учитывая необходимость совместного использования данных разными пользователями и возможности дальнейшего развития схемы БД. Для каждой сущности выбираются атрибуты, которые делятся на два типа: идентифицирующие и описательные. Идентифицирующие атрибуты входят в состав ключа (или ключей) и позволяют однозначно распознавать экземпляры сущности. Ключ должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности. Спецификация атрибута состоит из его названия, указания типа данных и описания ограничений целостности - множества значений, которые может принимать данный атрибут. Далее осуществляется спецификация связей: выявляются связи между сущностями внутри локального представления. Каждая связь именуется. Кроме спецификации связей типа «сущность-сущность», выполняется спецификация связей типа «сущность-атрибут» и «атрибут-атрибут» для отношений между атрибутами, которые относятся к одной и той же сущности или к одной и той же связи типа «сущность-сущность». При объединении проектировщик может формировать конструкции, производные по отношению к тем, которые были использованы в локальных представлениях. Целью введения подобных абстракций является: • объединение в единое целое фрагментарных представлений о различных свойствах одного и того же объекта; • введение абстрактных понятий, удобных для решения задач системы, установление их связи с более конкретными понятиями, использованными в модели; • образование классов и подклассов подобных объектов (например, класс «изделие» и подклассы типов изделий, производимых на данном предприятии). При небольшом количестве локальных областей объединение выполняется за один шаг. В противном случае объединение обычно выполняется в несколько этапов. При объединении представлений используют 3 основные концепции: • идентичность. Два или более элементов модели идентичны, если они имеют одинаковое семантическое значение. • агрегация. Позволяет рассматривать связь между элементами как новый элемент. Например, связь между сущностями СТУДЕНТ, ДИСЦИПЛИНА, ПРЕПОДАВАТЕЛЬ, ОЦЕНКА может быть представлена агрегированным элементом: сущностью ЭКЗАМЕН с атрибутами ФАМИЛИЯ-СТУДЕНТА, НАЗВАНИЕ-ДИСЦИПЛИНЫ, ФАМИЛИЯ- ПРЕПОДАВАТЕЛЯ, КОД-ОЦЕНКИ. • обобщение. Подчеркивает общую природу объектов, позволяет образовывать многоуровневую иерархию обобщений. Например, в объединяемых представлениях присутствуют следующие сущности: ГРУЗОВЫЕ АВТОМОБИЛИ РОССИЙСКОГО ПРОИЗВОДСТВА ЛЕГКОВЫЕ АВТОМОБИЛИ РОССИЙСКОГО ПРОИЗВОДСТВА КОМПЛЕКТУЮЩИЕ РОССИЙСКОГО ПРОИЗВОДСТВА ИМПОРТНЫЕ КОМПЛЕКТУЮЩИЕ Их можно объединить следующим образом (рисунок ниже). На этапе объединения необходимо выявить и устранить все противоречия. Например, одинаковые названия семантически различных объектов или связей или несогласованные ограничения целостности на одни и те же атрибуты в разных приложениях. Устранение противоречий вызывает необходимость возврата к этапу моделирования локальных представлений с целью внесения в них соответствующих изменений. По завершении объединения результаты проектирования являют собой концептуальную инфологическую модель предметной области. Модели локальных представлений - это внешние инфологические модели. Замечание. Большой объем информации, получаемый как непосредственно от экспертов, так и из документальных источников с помощью экспертов, страдает большой долей субъективности. Это может привести не только к противоречивости хранимых данных в БД но и, что самое важное, к принятию неадекватных решений. Поэтому необходимо в общем случае с целью повышения объективности этого вида информации использовать методы экспертных оценок (простейшим из которых является, например, анкетирование). |