Архитектура Аудит Военная наука Иностранные языки Медицина Металлургия Метрология Образование Политология Производство Психология Стандартизация Технологии |
Сравнительный анализ методологий функционального моделирования.
Несмотря на то, что методология IDEF0 получила широкое распространение в российских компаниях, на наш взгляд DFD гораздо больше подходит для проектирования информационных систем вообще и баз данных в частности. DFD позволяет уже на стадии функционального моделирования определить базовые требования к данным (этому способствует разделение потоков данных на материальные, информационные и управляющие). Вообще интеграция DFD и ER (entity-relationship, " сущность-связь" ) моделей не вызывает затруднений. Например, можно определить список атрибутов хранилищ данных, последние на стадии информационного моделирования однозначно отображаются в сущности модели " сущность- связь". В свою очередь, как уже отмечалось, IDEF0 больше подходит для решения задач, связанных с управленческим консультированием (перепроектированием деловых процессов, бизнес - реинжинирингом). Этому способствует также тесная связь IDEF0 с методом функционально - стоимостного анализа ABC (Activity Based Costing), позволяющим определить схему расчета стоимости выполнения той или иной деловой процедуры. Однако, существует ряд CASE - систем, предлагающих методологию IDEF0 на этапе функционального обследования предметной области. В таких системах на следующий этап передается просто список всех объектов IDEF0-модели (входы, выходы, механизмы, управление), которые затем рассматриваются на предмет включения в информационную модель. На этом мы закончим рассмотрение способов функционального моделирования предметной области, поскольку эта тема должна быть гораздо полнее освещена в курсе, касающегося проектирования информационных систем. Подробнее о методологии SADT / IDEF0 можно узнать из книги Д.Марки и К. МакГоуэна, DFD описана в книге Г.Н. Калянова. Более полный сравнительный анализ рассмотренных здесь методологий сделан в статье Г.Н.Калянова, А.В.Козлинского и В.Н.Лебедева, указанной в списке литературы. В предыдущей главе мы кратко рассмотрели методы функционального моделирования, которые позволяют выделить первичные информационные объекты, из которых затем строятся концептуальная и реляционная модели данных. Однако, в случае достаточно простой предметной области выделение информационных объектов можно произвести и без функционального анализа. Один из способов такого проектирования структуры реляционной базы данных описан в этом и следующем разделах. В параграфе 5.6 будет рассмотрен другой способ проектирования реляционной структуры, основанный на декомпозиции универсального отношения. 5.4.Концептуальное моделирование. Пример построения модели " сущность-связь". Один пример построения модели " сущность-связь" был приведен в разделе 2.1, где были введены основные понятия этой модели. Здесь мы рассмотрим другой пример, связанный с проектированием базы данных publucations, которая использовалась для практических занятий при изучении языка SQL. БД publications должна хранить сведения о печатных изданиях, а также ссылки на интересные ресурсы в Internet. И те и другие источники информации будут касаться одной темы, а именно " баз данных". Попробуем выделить интересующие нас сущности и определить связи между ними. Прежде всего займемся понятием " печатное издание". Что это такое? Мы знаем, что объект " печатное издание" воплощается в виде книги, которую можно полностью описать с помощью следующих характеристик: название, автор, год издания и издатель (издательство). Можно ли на основании этого ввести сущность " книга", а названные характеристики определить в качестве ее атрибутов? Прежде чем сделать это рассмотрим более внимательно отношения между книгой и ее харакетристиками:
Таким образом, мы определили, что у сущности " книга" имеется два атрибута " название" и " год издания". Как уже говорилось, название, скорее всего, будет однозначно определять данную книгу, чего не скажешь о годе издания. Поэтому объявим ключом сущности атрибут " название" (или " имя_книги" ). Что касается всех возможных авторов, то нас интересует только одна их харакетристика - имя. Поэтому, сущность " автор" имеет только один атрибут " имя_автора", который и является ключом. С сущностью " издатель" дел обстоит несколько сложнее. Практически все крупные издательства имеют сейчас собственные web-страницы, которые могут содержать информацию полезную для пользователей проектируемой базы данных. Поэтому, нужно рассматреть две характеристики этого объекта: " имя_издателя" и " URL" (uniform resource locator - универсальный указатель ресурсов, с помощью которого в Internet определяется путь к web - странице). Ясно, что каждый издатель имеет уникальное имя и уникальный url, но прежде чем внести их в список атрибутов, вспомним, что наша база данных должна также содержать ссылки и на другие Internet-ресурсы. Возможно, при дальнейшем анализе возникнет необходимость во введении отдельной сущности " URL". Поэтому " имя_издателя" внесем в список атрибутов сущности " издатель", а " URL" будем считать атрибутом отдельной сущности " web - страница", ассоциируемой с " издателем" связью (1, 1): (1, 1). Теперь настала пора занятся объектом " ресурс Internet". Его мы можем описать с помощью понятий " имя ресурса", " url", " автор". Внимательно рассмотрев связи этих понятий с описываемым объектом, можно прийти к заключению, что " имя_ресурса" и " url" однозначно с ним связаны, т.е. являются атрибутами. В то же время, " автор" является отдельной сущностью (один ресурс может иметь много авторов, и один автор может быть создателем многих web - страниц). Т.к. мы уже ранее вввели сущность " автор" просто определим характеристики ее связи с сущностью " Internet-ресурс". Из сказанного выше следует, что эти сущности объединяются связью n: m, в то же время, автор какой-либо книги может не иметь собственной web - страницы, а авторы некоторых Internet ресурсов не указывают своих имен (т.е. можно формально сказать, что эти ресурсы не имеют авторов). Следовательно, класс принадлежности обеих сущностей будет необязательным. Прежде чем объявить нашу модель готовой, проверим еще раз определение каждой сущности. Внимательный анализ покажет, что построенная модель имеет несколько ошибок:
5.5.Правила порождения реляционных отношений из модели " сущность-связь". Бинарные связи
N - арные связи. Общее правило: для представления n-сторонней связи всегда требуется n+1 отношение. Например, в случае трехсторонней связи необходимо использовать четыре отношения, по одному для каждой сущности (причем ключ сущности служит первичным ключом соответствующего отношения), и одно для связи. Отношение, порождаемой для связи, будет иметь среди своих атрибутов ключи от каждой сущности.
Иерархические связи. К сожалению, надо признать, что реляционная модель мало подходит для отображения отношений наследования между сущностями (иерархических связей). Напомним, что в таких связях дочерние сущности наследуют все атрибуты родительской, и каждая из них обладает своим уникальным набором дополнительных атрибутов. В параграфе 2.2 приведен пример такой связи между родительской сущностью ЗАКАЗЧИК и дочерними - ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ. В этом случае возможны два варианта построения реляционных отношений. Согласно первому для иерархической структуры создается одно отношение, которое содержит атрибуты связи и всех сущностей. Для примера из параграфа 2.2 мы должны создать отношение ЗАКАЗЧИК(НАЦ_ПРИНАДЛЕЖНОСТЬ, ВАЛЮТА, ЯЗЫК, ФОРМА_СОБСТВЕННОСТИ). Недостаток такого способа - для каждого кортежа часть атрибутов всегда будет неопределена. Т.е. для отечественного предприятия всегда будут иметь значения NULL атрибуты ВАЛЮТА и ЯЗЫК, а для зарубежного атрибут ФОРМА_СОБСТВЕННОСТИ. Более того, этот факт является требованием целостности сущности, следовательно для СУБД должны быть явно указаны несколько списков атрибутов (по числу дочерних сущностей), причем определенные значения могут быть присвоены только членам одного из них. Реляционная модель не поддерживает такого ограничения, на практике его реализуют с помощью триггеров. По второму способу генерируется по одному отношению для каждой дочерней сущности. Каждое из этих отношений включает атрибуты родительской сущности и связи кроме атрибутов - дискриминантов т.е. ЗАРУБЕЖНОЕ_ПРЕДПРИЯТИЕ(ВАЛЮТА, ЯЗЫК) и ОТЕЧЕСТВЕННОЕ_ПРЕДПРИЯТИЕ( ФОРМА_СОБСТВЕННОСТИ ). Недостатком данного способа является невозможность получить в одном запросе список всех заказчиков. Оба описанных способа представлены на рисунке: Следует отметить, что построенные таким образом реляционные отношения, не являются окончательной схемой базы данных. Их необходимо проверить на избыточные функциональные зависимости и привести к NFBK или нормальной форме более высокого порядка. Применив все эти правила к модели " сущность-связь" базы данных publications, построенной в предыдущем параграфе, получим следующую реляционную структуру:
Синим цветом на диаграмме выделены первичные ключи, красным - внешние. Отношения, созданные для представления связей, обозначены серыми прямоугольниками, для сущностей - желтыми прямоугольниками. |
Последнее изменение этой страницы: 2017-05-05; Просмотров: 559; Нарушение авторского права страницы