Продолжается подписка на наши издания! Вы не забыли подписаться?

Информационные системы, Базы данных и Модели

В этой статье речь пойдет о создании моделей данных и проектировании баз данных при помощи одного из самых лучших на сегодняшний день CASE – средств компании LogicWorks — Erwin 3.5. Редакция благодарит компанию INTERFACE LTD, официального дистрибьютора продуктов компании LogicWorks, за предоставленный материал при подготовке этой статьи.


Информационные системы могут принести огромную пользу для корпораций, за счет автоматизации задач, которые раньше решались вручную. Если говорить коротко, то преимущества информационных систем сводятся к следующим ключевым понятиям: быстрее, лучше и больше. Тем не менее, для того, чтобы осознать пользу информационных систем, вы должны иметь возможность разрабатывать их вовремя и с минимальными затратами. Другими словами, информационные системы должны удовлетворять интересам бизнеса, а также быть легко модифицируемыми и недорогими. Плохо спроектированная система, в конечном счете, требует больших затрат и времени для ее содержания и обновления.

Одним из самых важных инструментов для уменьшения затрат на управление и изменение информации, стали системы управления реляционными базами данных (RDBMS). RDBMS предоставляют надежные и удобные средства для хранения, поиска и обновления данных. Важным также является использование методики, уменьшающей затраты на разработку и обслуживание баз данных. Среди таких методик самой популярной и наиболее широко используемой является моделирование данных.

Что такое моделирование данных?

Моделирование данных – это процесс описания информационных структур и бизнес-правил для определения потребностей информационной системы.

Модель данных представляет собой разумный компромисс между потребностями конкретного RDBMS проекта и основными запросами области бизнеса, нуждающейся в реализации этой модели.

Структурная системная разработка и, в особенности, проектирование с учетом централизации данных, заключаются, в основном, в стратегическом планировании и всестороннем анализе требований. Большая часть этих подходов к разработке реализуется в ERwin моделировании данных в качестве метода, определяющего и документирующего ту часть системных требований, которая непосредственно связана с данными. Модели процессов (диаграммы потоков данных, модели распределения, модели событий/состояний) могут быть созданы при помощи Logic Works BPwin и других инструментов для документирования требований процессов. На разных стадиях разработки используются различные уровни этих моделей.

Создание модели данных с непосредственным участием профессионалов в области бизнеса и системного анализа, имеет большие преимущества. Эти преимущества можно разбить на два основных класса: связанные с моделью, как таковой (результатом прилагаемых усилий), и связанные собственно с процессом создания модели.

er1.GIF (6597 bytes)

1. Уровни проектирования базы данных IDEF1X

Примеры преимуществ получаемой модели

Модель данных независима с точки зрения реализации, т. е. ее реализация не зависит от конкретной базы данных или языка программирования.

Модель данных дает однозначное определение того, что требуется получить.

Модель управляется пользователем. Другими словами, содержание и структура модели контролируется, в основном, клиентом, а не системным разработчиком. Ударение делается, скорее, на требования, нежели на ограничения и конкретные решения.

Терминология, используемая моделью, определяется языком бизнеса, а не организации, занимающейся разработкой системы.

Модель позволяет фокусировать внимание на самых важных на текущий момент аспектах бизнеса.

Примеры преимуществ, связанных с процессом создания модели

На ранних стадиях работы над проектом собрания разработки модели объединяют представителей различных подразделений для обсуждения стратегии бизнеса и политики деловой активности. На протяжении этих сессий, персонал часто взаимодействует с другими подразделениями организации, занимающимися решением тех же проблем.

Сессии приводят к разработке общего делового языка с точными и емкими определениями используемых терминов. На ранней стадии сессии предоставляют механизм для обмена большим количеством информации между участникам проекта, и, одновременно, обеспечивают нужной информацией разработчиков системы. На поздней стадии сессии продолжают передавать информацию персоналу, который и будет претворять конкретные решения в жизнь.

Участники сессии, в общем случае, имеют возможность увидеть, как их деятельность вписывается в общую картину проекта. Отдельные части проекта также можно рассмотреть в общем контексте. Одним словом, ударение ставится именно на кооперацию, а не на разделение разработки проекта на отдельные независимые части.

Проектирование структур данных для поддержки определенной области бизнеса является лишь одной из частей разработки системы. Анализ процессов (функций) также имеет большое значение. Функциональные модели описывают, каким образом что-либо создается. Они могут быть реализованы в виде иерархических декомпозиционных диаграмм, диаграмм потоков данных и др. На практике вы обнаружите, что важно разрабатывать модели функций и данных одновременно. Обсуждение функций, реализуемых системой, дает представление о требованиях к данным. В то же время, анализ данных раскрывает дополнительные требования к функциям. Функции и данные являются разными сторонами одной медали (разработки данных).

ERwin непосредственно поддерживает моделирование процессов и может прекрасно работать с различными технологиями. Например, Logic Works, среди прочего, предлагает инструмент для моделирования функций - BPwin, поддерживающий методы моделирования процессов IDEF0, IDEF3, методы диаграмм потоков данных. BPwin может использоваться в сочетании с ERwin для анализа процесса в ERwin-проекте (моделирующем данные).

Сессии моделирования данных

Создание модели данных включает в себя, также, сессии по анализу факторов, определяющих данные и процессы, используемые для нужд бизнеса. Проведение удачных сессий, как и проведение любого рода плодотворных встреч, зависит от их подготовки и используемых вспомогательных технических приемов. Сессии моделирования должны оптимально сочетать в себе работу технических и бизнес-экспертов. В этом случае, они будут правильно составлены, тщательно спланированы для охвата нужного материала и, тем самым, обеспечат достижение нужных результатов.

Настоятельно рекомендуется, чтобы, по возможности, моделирование функций и данных проводилось в одно и тоже время. Это связано с тем, что функциональные модели пытаются подтвердить достоверность модели данных и раскрывают новые требования к данным. Этот подход также обеспечивает поддержку моделью данных функциональных требований. Для создания функциональной модели и модели данных в одной сессии важно использовать не только моделер данных, но и моделер процессов, имеющий возможность использовать изучаемые функции.

Роли в сессии

Следует проводить формальные, управляемые сессии с определенными для участников ролями и согласованными процедурами и правилами.

Руководитель сессии играет вспомогательную роль. Он отвечает за организацию встреч и мероприятий, предоставляет сопутствующую документацию и участвует в сессии для того, чтобы держать всех участников в курсе событий.

Проектировщик модели данных отвечает в группе за процесс разработки модели данных и подтверждает ее правильность. Проектировщик разрабатывает модель, взаимодействуя с группой. Он задает уточняющие вопросы для выявления важных деталей и изменяет структуру модели на глазах у группы. В отдельных случаях существует возможность объединить роль руководителя и проектировщика модели данных в одном лице.

Аналитик(и) (специалист(ы) по анализу данных) выполняет роль секретаря сессии. Он записывает определения всех объектов и их атрибутов, образующих модель. Он также может объединять объекты и атрибуты в подобласти (subject areas) значимые и управляемые подмножества модели данных.

Бизнес-консультант(ы) предоставляют информацию о бизнесе, требующуюся для создания модели. Это, скорее, люди бизнеса, а не системщики...

Менеджер, либо из “системщиков”, либо из “бизнесменов”, участвует в сессии в какой-либо определенной заранее роли (руководитель, бизнес-консультант, и.т.д), но, одновременно с этим, выполняет общее руководство над проектом для его успешной реализации. Менеджер имеет полномочия (в крайних случаях, конечно) решать спорные вопросы на свое усмотрение.

Пример IDEF1X-методик моделирования

ERwin был разработан с учетом поддержки IDEF1X и IE стандартов моделирования, однако, не имеет строгих ограничений на использование других методик моделирования. Несмотря на это, использование различных уровней моделей в методе IDEF1X, может оказаться очень полезным для разработки системы. Основные уровни модели выделяются в IDEF1X стандарт и представлены ниже. На практике, для решения конкретных задач вы можете увеличить количество уровней.

Более общие (высокие) уровни модели в основном содержат информацию об объектах, важных для бизнеса. Более низкие уровни содержат информацию для разработки базы данных, используя терминологию DBMS. Это означает, что модели зависят от конкретной технологии, т.е. модель базы IMS будет сильно различаться от модели базы данных DB2. На более высоких уровнях модели не зависят от применяемой технологии, и могут даже предоставлять информацию, не отсортированную какой-либо системой автоматизации.

Уровни моделирования, представленные ниже, хорошо приспособлены для использования на протяжении всего жизненного цикла разработки системы. Другими словами, нужные уровни детализации создаются на каждом конкретном этапе развития проекта.

Самые общие уровни модели можно разделить на два вида. Диаграмма зависимостей сущностей (Entity Relationship Model, ERD) определяет основные бизнес-объекты и их взаимосвязи. Модель, основанная на ключах (KB), определяет рамки требований бизнес информации и начинает раскрывать подробности.

Низкие уровни модели можно также разделить на два вида. Полностью определенная (Fully Attributed, FA) модель – является третьим видом модели, который содержит все детали для конкретной реализации. Модель трансформации (Transformation Model, TM) представляет собой трансформацию модели зависимостей в структуру соответствующую DBMS.

В большинстве случаев модель трансформации не относится к третьей нормальной форме.

Дизайн базы данных содержится в модели DBMS для системы. В зависимости от уровня интеграции информационной бизнес-системы, DBMS модель может быть моделью уровня проекта или уровня области для всей интегрированной системы.

Эти уровни представлены на иллюстрации 1. Обратите внимание на то, что DBMS модель может отображать или область (“Area”) или проект (“Project”). Возможен вариант использования по одной ERD и KB модели для бизнеса и нескольких DBMS моделей, по одной на каждую среду разработки, и еще по набору моделей в пределах среды для уровня “проектов”, не разделяющих базы данных. В идеале, должен существовать набор DBMS моделей уровня “Области”, по одной на каждую среду, с полным разделением данных во всех проектах в этой среде.

Логические Модели

Существует три уровня логических моделей, используемые для охвата требований бизнес информации: Диаграмма зависимостей сущностей (ERD), Модель основанная на ключах (Key Based, KB) и Полностью определенная модель (FA). ERD и KB модели также называются “моделями данных области” потому, что охватывают обширные области бизнеса. Полной противоположностью является модель FA – “модель данных проекта” потому, что она, как правило, описывает только часть всей структуры информации.

Диаграмма зависимостей сущностей (ERD)

Диаграмма зависимостей сущностей является моделью данных высокого (более общего) уровня.

Основной задачей Диаграммы зависимостей сущностей является обзор требований к бизнес-информации, достаточной для планирования разработки информационной системы. Эти модели не являются очень детализированными (в них включены только основные сущности), и почти отсутствуют атрибуты. Разрешены отношения многие-ко-многим, а ключи, в основном, не включаются. Одним словом, ERD является презентационной моделью, удобной для обсуждения.

Модель, основанная на ключах (KB).

KB-модель описывает основные структуры данных, которые охватывают обширные области бизнеса. Все сущности и первичные ключи включены вместе с примерами атрибутов.

Основной целью модели, основанной на ключах, является широкий обзор структур данных и ключей, нужных для поддержки определенной области. Эта модель определяет контекст, в котором могут созданы подробные модели, пригодные для конкретного воплощения.

Модель показывает ту же область что и область ERD, но, вместе с тем, отображает больше деталей.

Полностью определенная модель (FA).

Полностью определенная модель – это модель данных в третьей нормальной форме, которая включает в себя сущности, атрибуты и зависимости, требуемые для конкретного проекта.

Физические модели

Существует два уровня физических моделей: Модель трансформации и DBMS модель. Физические модели отображают всю информацию, нужную разработчикам системы для воплощения логической модели в систему БД. Модель трансформации является также “моделью данных проекта”, описывающей отдельную часть всей структуры данных, предназначенную для обеспечения конкретного участка автоматизации. ERwin поддерживает индивидуальные проекты в области бизнеса, позволяющие разработчику разделять область с более общей моделью на подобласти, называемые тематическими областями (subject areas).

Модель трансформации

Основными задачами модели трансформации являются: обеспечение администратора базы данных (DBA) информацией, нужной для создания рациональной физической базы данных, а также предоставление контекста для определений и записей в словаре данных и записей, образующих базу данных. Модель также может быть полезна команде разработчиков в определении физической структуры программы, осуществляющей доступ к данным.

Эта модель может также предоставить возможность для сравнения проекта физической базы данных и изначальных требований к бизнес информации, а также для оценки и корректировки расширяемости и ограничений базы данных.

DBMS модель

Модель трансформации напрямую переводится в DBMS модель, которая, в свою очередь, получает определения объектов физической базы данных в схеме RDBMS или каталоге базы данных. ERwin напрямую поддерживает эту модель с функцией генерации схемы. Первичные ключи становятся уникальными индексами. Альтернативные ключи и инверсные вхождения (Inversion Entries, IE) также могут стать индексами.

Преимущества моделирования в ERwin

Вне зависимости от используемого вами типа DBMS и модели данных, моделирование вашей базы данных в ERwin имеет разнообразные преимущества. Наиболее очевидным преимуществом является наличие документации по системе, которая может быть использована персоналом, разрабатывающим базы данных и приложения как для определения требований системы, так и для контактов с конечным пользователем.

Вторым преимуществом является предоставление ясной картины ограничений. Поддержание ссылочной целостности существенно для реляционной модели, где отношения задаются косвенным образом.

Третьим преимуществом является возможность получения логической RDBMS-независимой картины вашей базы данных, которая может быть использована автоматическими средствами для генерации информации, специфичной для конкретной СУБД. Таким образом, вы можете использовать единственную Erwin-диаграмму для генерации как схем таблиц DB2, так и схем других реляционных DBMS.

Самым главным преимуществом моделирования при помощи ERwin является простота с которой происходят суммирование результатов моделирования структур данных и генерация схем баз данных из этих моделей.

Создание логической модели

Первым шагом при создании логической модели является создание диаграммы зависимостей сущностей (the Entity Relationship Diagram, ERD) – модели данных высокого уровня, описывающей широкие области бизнеса.

ERD состоит из трех основных блоков: сущностей, атрибутов и связей. Если рассматривать диаграмму как некий графический язык, то можно заметить, что объекты являются существительными, атрибуты – прилагательными, а зависимости – глаголами этого языка. Построение модели данных в ERwin заключается в, как бы, нахождении правильного набора существительных, глаголов и прилагательных и в правильном их сочетание.

Основная задача ERD – оценить, какие требования к бизнес-информации будут достаточными для обеспечения нужд планирования разработки информационной системы. Эти модели не очень подробны (включены только основные сущности), атрибуты тоже слабо детализируются. Разрешены отношения многие ко многим, ключи, как правило, не включаются. Эта модель, в основном, предназначена для презентации и обсуждения.

ERD разделяются на предметные области, в которых более детально описываются различные бизнес-функции. Наличие предметных областей позволяет представлять большие модели в более компактной форме. В результате модель становится легко управляемой и редактируемой.

Существует несколько способов разработки ERD. Они варьируют от формальных сессий моделирования (описанных в предыдущей статье) до индивидуальных интервью с менеджерами, обладающими большой сферой ответственности.

В этой статье речь пойдет о методе моделирования данных, используемом ERwin, и о мощности и удобстве этого метода для описания информационных структур вашего бизнеса.

Диаграмма зависимостей сущностей (диаграмма “сущность-связь”)

er2.GIF (3075 bytes)

2. Пример диаграммы зависимостей сущностей

Если вы знакомы с реляционными базами данных, то вам, конечно, известно, что основным компонентом этих баз данных является таблица. Таблицы используются для управления и хранения информации. Таблицы, как известно, состоят из строк и столбцов.

В реляционной базе данных в каждой ячейке может храниться только один объект. В базе данных существует также взаимосвязь между таблицами. Каждая взаимосвязь представлена в RDBMS (РСУБД) за счет совместного использования одной или нескольких колонок двумя таблицами.

Так же, как таблицы и колонки образуют физическую модель реляционной базы данных, Диаграмма зависимостей сущностей (и другие логические модели) включают в себя компоненты, которые позволяют смоделировать структуры данных для вашего бизнеса. Логическим эквивалентом таблицы является сущность, а логическим эквивалентом колонки является атрибут.

er3.GIF (4128 bytes)

3. ERD с атрибутами

В ERD сущность представлен рамкой с именем этой сущности. Названия сущностей могут быть только в единственном числе – потребитель (а не потребители), фильм (а не фильмы), страна (а не страны). Если вы всегда будете использовать существительные в единственном числе, то можете получить единый стандарт для всех названий, и тем самым, сделать диаграмму более читаемой.

На диаграмме 2 отображен гипотетический видеомагазин, который нуждается в отслеживании покупателей, фильмов, которые могут быть приобретены или сданы на прокат, а также копий фильмов, находящихся в фильмотеке.

Взаимосвязи между таблицами являются жизненно важными компонентами реляционных баз данных.

Эти связи создаются за счет использования общих ключей, т. е. записи в одной таблице ссылаются на записи в другой таблице. В ERD взаимосвязи отображены в виде линии между сущностями, входящими в модель. Связь между двумя сущностями также включает то, что факты одной сущности ссылаются или ассоциированы с фактами другой сущности.

В диаграмме 3, показанном выше, для фильмотеки требуется механизм отслеживания информации о потребителях и прокатных копиях фильмов. Информация этих двух сущностей взаимосвязана, и эта связь может быть выражена так: Потребитель берет напрокат одну или более Прокатных копий фильма.

Определение сущностей и атрибутов

Сущности могут быть определены в виде какого-либо лица, места, предмета, события, о которых содержится соответствующая информация. Если говорить точнее, то сущность можно представлять как набор отдельных экземпляров (записей). Экземпляр – это конкретная реализация сущности. Каждый экземпляр должен быть отличен от остальных.

В предыдущем примере сущность Потребитель представляет собой всех существующих потребителей, т. е. все экземпляры этой сущности. Вы можете составить список экземпляров в виде таблицы 1, изображенной ниже.

В примере показанном выше, каждый экземпляр сущности Потребитель содержит следующую информацию: Id потребителя, имя потребителя, адрес потребителя. В логической модели эти свойства называются атрибутами сущности. Каждый атрибут содержит только часть информации о сущности.

Вы можете включить атрибуты в ERD для того, чтобы более полно описать объекты в модели. (см. Рис. 3).

Логические связи

Связи играют роль ссылок, соединений и ассоциаций между сущностями.

Связи – это, собственно, глаголы, которые показывают, как соотносятся сущности между собой.

Простые для понимания правила помогают профессионалам в области бизнеса определять ограничения, накладываемые на данные, а также точно определять атрибуты связей.

Вот несколько примеров:

Команда <состоит из> нескольких Игроков

Автобус <перевозит> нескольких Пассажиров.

Продавец <продает> разные продукты.

Парный теннис <требует> точно 4-х Игроков.

Домом <владеет> один или несколько Владельцев.

er4.GIF (1619 bytes)

4. Пример связи

Во всех перечисленных примерах взаимосвязи между сущностями соответствуют схеме один ко многим. Это означает, что один экземпляр первой сущности связан с несколькими экземплярами второй сущности. Причем первая сущность называется родительской, а вторая – дочерней. В приведенных примерах глаголы заключены в скобки (т. е. <...>). (см. Рис. 4)

Взаимосвязи отображаются в виде линии между двумя сущностями с точкой на одном конце и глагольной фразой, отображаемой над линией. На рис. 4 приводится диаграмма связи между Автобусом и Пассажирами.

Отношение многие - ко - многим

Отношение многие ко многим, также называемое неопределенным отношением, отображает ситуацию, когда экземпляр в одной сущности относится к одному или нескольким экземплярам второй сущности, а экземпляр во второй сущности относится к одному или нескольким экземпляров первой сущности. В примере видеомагазина отношение многие ко многим возникает между экземплярами ПОТРЕБИТЕЛЬ и КОПИЯ ФИЛЬМА. В данном случае отношение многие ко многим показывает, что “ПОТРЕБИТЕЛЬ <берет напрокат> несколько КОПИЙ ФИЛЬМОВ” и “КОПИЯ ФИЛЬМА <сдается напрокат> нескольким ПОТРЕБИТЕЛЯМ”.

5. Пример отношения многие ко многим в IDEF1X (вверху) и IE (внизу)

5. Пример отношения многие ко многим в IDEF1X (вверху) и IE (внизу)

Отношения многие ко многим обычно используются на начальной стадии разработки диаграммы, например, в диаграмме зависимости сущностей (ERD) и отображаются в IDEF1X в виде сплошной линии с точками на обоих концах.

Так как отношения многие ко многим могут скрыть другие бизнес правила или ограничения, они должны быть полностью исследованы на одном из этапов моделирования. Например, иногда отношение многие ко многим на ранних стадиях моделирования идентифицируется неправильно, на самом деле представляя два случая отношений один-ко-многим между связанными сущностями. Или, в случае необходимости хранения дополнительных сведений о связи многие-ко-многим, например, даты или комментария, такая связь должна быть заменена дополнительной сущностью, содержащей эти сведения. Вы должны быть уверены в том, что все отношения многие-ко-многим будут подробно обсуждены на более поздних стадиях моделирования для обеспечения правильного моделирования отношений.

Подтверждение достоверности логической модели.

Если вы правильно назначили глагольную фразу, вы должны суметь “прочесть” связь от родительской сущности к дочерней, используя “активную” глагольную фразу. Один из предыдущих примеров гласил – ПОТРЕБИТЕЛЬ <берет на прокат> несколько КОПИЙ ФИЛЬМОВ.

Глагольные фразы могут быть также прочитаны со стороны дочернего объекта. Например: Несколько КОПИЙ ФИЛЬМОВ <сдаются на прокат> ПОТРЕБИТЕЛЯМ.

Так как модель данных раскрывает большое количество бизнес-правил, описывающих моделируемую область, чтение зависимостей помогает убедиться в достоверности модели. Глагольные фразы предоставляют краткое изложение бизнес-правил, воплощенных при помощи отношений. И, несмотря на то, что они не точно описывают правила, они, тем не менее, позволяют человеку, смотрящему на модель, получить первоначальное представление о взаимосвязях между сущностями. Правильным будет убедиться в том, что каждая использованная в модели глагольная фраза превращается в правильное утверждение. Обратный перевод вашей модели на деловой язык – один из главных способов проверки корректности отраженных в модели бизнес-правил.

Пример модели данных

er6.GIF (15236 bytes)

6.Модель данных для видеомагазина

В ERwin содержится модель базы данных, созданной для гипотетического видеомагазина. Копия логической модели в диаграмме MOVIES представлена на рис.6.

Модель данных Видеомагазина вместе с представленными в ней объектами, утверждает следующее:

ФИЛЬМ находится на складе в качестве одной или нескольких КОПИЙ ФИЛЬМА. Информация о фильме включает его название, рейтинг и цену проката. Каждая КОПИЯ ФИЛЬМА имеет определенные условия проката.

ПОТРЕБИТЕЛИ данного магазина берут на прокат КОПИИ ФИЛЬМА. A ЗАПИСЬ О ПРОКАТЕ ФИЛЬМА записывает подробности о прокате КОПИИ ФИЛЬМА определенному ПОТРЕБИТЕЛЮ. Одна и та же КОПИЯ ФИЛЬМА впоследствии может быть отдана в прокат нескольким ПОТРЕБИТЕЛЯМ.

Каждая ЗАПИСЬ О ПРОКАТЕ ФИЛЬМА содержит информацию о сроке проката фильма, а также о превышении срока проката.

ПОТРЕБИТЕЛЬ, в зависимости от опыта его (ее) предыдущего сотрудничества с магазином, получает тот или иной статус кредита, регламентирующий, примет ли магазин чеки или кредитную карту ПОТРЕБИТЕЛЯ, или же будет настаивать на оплате наличными.

Служащие магазина участвуют во многих ЗАПИСЯХ О ПРОКАТЕ ФИЛЬМОВ, как определено в типе занятости. Должен быть по крайней мере один СЛУЖАЩИЙ, занятый каждой записью. Так как один и тот же СЛУЖАЩИЙ может заниматься записью неоднократно в течении того же дня, занятость определяется по времени записи.

Иногда за просрочку проката КОПИИ ФИЛЬМА берется пеня. В этом случае необходимо ОПОВЕЩЕНИЕ ОБ ОКОНЧАНИИ СРОКА ПРОКАТА для напоминания ПОТРЕБИТЕЛЮ о том, что нужно вернуть пленку. В это оповещение может включаться СЛУЖАЩИЙ, сделавший эту запись.

В магазине хранится информация о жаловании и адресе СЛУЖАЩЕГО. Иногда требуется найти ПОТРЕБИТЕЛЯ, СЛУЖАЩЕГО по именам или ФИЛЬМ по названию, а не по присвоенным им “номерам”.

Эта модель данных относительно невелика, однако содержит полную информацию о видеомагазине.

Из этой модели можно получить представление не только о том как должна выглядеть база данных, но и об общую картину работы. В этой диаграмме находится несколько разных типов графических “объектов”. Сущности, атрибуты и взаимосвязи вместе с другими символами описывают наши бизнес-правила. В следующих главах вы узнаете несколько больше о различных графических объектах и как использовать ERwin для создания собственных логических и физических моделей.

Модель основанная на ключах

Модель основанная на ключах (KB) – это модель полностью описывающая основные структуры данных, связанные с широкими областями бизнеса. Основным преимуществом KB модели является то обстоятельство, что она содержит практически все нужные для интересов бизнеса сущности и атрибуты.

KB модель содержит ключи, которые являются элементами модели данных, использующимися для идентификации уникальных экземпляров в сущности. При использовании в физической модели эти ключи предоставляют удобный доступ к данным.

В целом, KB модель отображает ту же область что и ERD, но делает это более подробно, включая контекст в котором могут быть созданы детальные модели уровня реализации.

Понятие о ключах

Давайте посмотрим на предыдущий пример (рис. 3).

Каждый объект разделяется горизонтальной линией на часть, в которой расположены ключевые поля и часть, где расположены не ключевые поля. Верхняя часть называется ключевой областью, а нижняя часть областью данных. Ключевая область объекта ПОТРЕБИТЕЛЬ содержит поле “Номер потребителя”, в области данных находятся поля “Имя потребителя”, “Адрес потребителя” и “Телефон потребителя”.

Ключевая область содержит первичный ключ для сущности. Первичный ключ – это набор атрибутов, выбранных для идентификации уникальных экземпляров сущности. Первичный ключ может включать в себя один или несколько атрибутов первичного ключа, составляющих уникальный идентификатор для каждой записи в сущности.

Атрибуты первичного ключа располагаются над линией в ключевой области. Как следует из названия, не ключевой атрибут – это атрибут, который не был выбран ключевым. Не ключевые атрибуты располагаются под чертой в области данных.

При создании сущности в вашей модели данных, одним из главных вопросов, на который вам нужно ответить, является: “Как можно идентифицировать уникальную запись?”. Вам требуется уникальная идентификация каждой записи в сущности для того, чтобы правильно создать логическую модель данных. Напомним, что сущности в ERwin всегда имеют ключевую область и, поэтому в каждой сущности вы должны определить ключевые атрибуты.

Выбор первичного ключа

Выбор первичного ключа для сущности является очень важным шагом, и требует большого внимания. В качестве первичных ключей могут быть использованы несколько атрибутов или наборов атрибутов. Атрибуты или группы атрибутов, которые могут быть выбраны первичными ключами, называются кандидатами в ключевые атрибуты (потенциальные атрибуты). Кандидаты в ключи должны уникально идентифицировать каждую запись сущности. В соответствии с этим, ни одна из частей ключа не может быть NULL, не заполненной или отсутствующей. Пользователь, чаще всего, лучше, чем кто-либо другой находит кандидаты в ключи, так как лучше всех разбирается в бизнесе и данных, использующихся в его области деятельности.

Например, для того, чтобы корректно использовать сущность СЛУЖАЩИЙ в модели данных (а позже в базе данных), вы должны иметь возможность уникально идентифицировать записи. Правила по которым вы выбираете первичный ключ из списка предполагаемых ключей очень строги, однако могут быть применены ко всем типам баз данных и информации. Правила устанавливают, что атрибуты и группы атрибутов должны:

Давайте рассмотрим следующий пример:

er7.GIF (2450 bytes)

пример выбора ключа

Если вы руководствуетесь вышеописанными правилами для нахождения потенциальных ключей для таблицы СЛУЖАЩИЙ, то можете произвести следующий анализ для каждого атрибута:

После проведенного анализа можно назвать два потенциальных ключа – первый “Номер служащего” и комбинация, включающая поля “имя служащего” и “Дата рождения служащего”. Так как атрибут “Номер служащего” имеет самые короткие и уникальные значения, то он лучше других подходит для первичного ключа.

При выборе первичного ключа для сущности, разработчики часто используют дополнительный (суррогатный) ключ, т.е. произвольный номер, который уникальным образом определяет запись в сущности. Атрибут “Номер служащего” является примером суррогатного ключа. Суррогатный ключ лучше всего подходит на роль первичного ключа потому, что является коротким и быстрее всего идентифицирует экземпляры в объекте. К тому же суррогатный ключи могут автоматически генерироваться системой так, чтобы нумерация была сплошной т.е. без пропусков. (примечание переводчика – суррогатный ключ и вводится-то с единственной целью создания искусственного первичного ключа, а выбор первичного ключа при наличии суррогатного ключа сильно напоминают старую добрую традицию демократических выборов из одного кандидата.)

Нужно заметить, что ключи, в зависимости от конкретной реализации физической модели и базы данных, можно в любое время изменить.

Назначение альтернативного ключа.

Потенциальные ключи, не использующиеся в качестве первичных ключей, могут быть назначены в качестве альтернативных ключей и записаны под этим именем в модели. Символ (AKn), где n – это номер, ставится после атрибутов, составляющих альтернативный ключ.

Альтернативные ключи часто используются для отображения различных индексов, используемых при доступе к данным. Таким образом, наша логическая модель для таблицы СЛУЖАЩИЙ теперь будет выглядеть так:

er8.GIF (2515 bytes)

Инверсные входы

В интересах бизнеса также требуется обращать внимание на атрибуты, не являющиеся уникальными, но использующимися для поиска информации в таблице. Эти атрибуты называются инверсными входами. Инверсный вход – это атрибут или группа атрибутов, которые используются для доступа к сущности (так, как если бы они были первичными ключами), однако не обязательно находят только один экземпляр.

К примеру, организации может потребоваться найти служащего по имени, также как и по номеру служащего, несмотря на то что, такой поиск может привести к получению одновременно нескольких записей. Когда вы назначите атрибут инверсным входом, после его названия будет стоять. En .У объекта, как показано ниже, может быть несколько инверсных входов.

er9.GIF (2438 bytes)

Связи и внешние ключи (Relationships and Foreign Key Attributes)

ERwin устанавливает взаимосвязи при помощи общих ключей также, как РСУБД захватывает связи, используя общие значения ключей. Несмотря на то, что ERwin может использоваться для моделирования информации, хранящейся в нереляционных системах управления базами данных, в своем подходе к ключам ERwin является реляционным.

Если сущности в диаграмме ERwin связаны, связь передает ключ (или набор ключевых атрибутов) дочерней сущности. Эти атрибуты называются внешними ключами. Внешние ключи определяются как атрибуты первичных ключей родительского объекта, переданные дочернему объекту через их связь.Передаваемые атрибуты называются мигрирующими.

Внешние ключи обозначаются в модели символами (FK), стоящими после названия.

er10.GIF (3086 bytes)

7. Идентификация взаимосвязи в IDEF1X(вверху) и IE (внизу).

er11.GIF (2002 bytes)

8. Объект с мигрировавшим внешним ключом (FK).
Зависимые и независимые сущности.

При разработке вашей модели, вы можете обнаружить сущности, уникальность которых зависит от значений атрибута внешнего ключа. Для этих сущностей (для уникального определения каждой сущности) внешний ключ должен быть частью первичного ключа дочернего объекта (находящегося над линией).

Дочерняя сущность, уникальность которой зависит от атрибута внешнего ключа, называется зависимой сущностью. В примере (рис.8) ИГРОК является зависимой сущностью потому, что его идентификация зависит от сущности КОМАНДА. В IDEF1X зависимые сущности представлены в виде закругленных прямоугольников.

Зависимые сущности далее классифицируются на сущности, которые не могут существовать без родительской сущности (зависимость существования, existence dependent) и сущности, которые не могут быть идентифицированы без использования ключа родителя (сущности, зависящие от идентификации). Сущность ИГРОК принадлежит ко второму типу зависимых сущностей, так как ИГРОКИ могут существовать и без КОМАНДЫ.

Напротив, существуют ситуации в которых сущность зависит от существования другой сущности. Рассмотрим две сущности: ЗАКАЗ, используемый для отслеживания заказов покупателей, и ЭЛЕМЕНТ СПИСКА, который отслеживает отдельные элементы в ЗАКАЗе. Зависимость между этими двумя объектами может быть выражена в качестве ЗАКАЗА <содержащего> один или несколько ЭЛЕМЕНТОВ СПИСКА. В этом случае, ЭЛЕМЕНТ СПИСКА зависит от существования ЗАКАЗА.

Объекты, не зависящие при идентификации от других объектов в модели, называются независимыми объектами. В вышеописанном примере объект КОМАНДА можно считать независимым объектом. В IE и IDEF1X независимые объекты представлены в виде прямоугольников.

er12.GIF (3129 bytes)

9. Не идентифицирующая взаимосвязь в IDEF1X (вверху) и IE (внизу).

Идентификация связей

В IDEF1X концепция зависимых и независимых сущностей усиливается типом взаимосвязей между двумя сущностями. Если вы хотите, чтобы внешний ключ передавался в дочернюю сущность (и, в результате, создавал зависимую сущность), то можете создать идентифицирующую взаимосвязь между родительской и дочерней сущность.

Идентифицирующие взаимосвязи обозначаются сплошной линией между сущностями.

В IDEF1X, как показано на рис.7, в конце линии со стороны дочернего объекта ставится точка. В IE в конце линии со стороны дочернего объекта ставится “куриная лапка”.

Примечание: В стандарте IE нет закругленных углов на объектах. Это IDEF1X символ, добавленный ERwin’ом в стандарт IE для совместимости.

Как вы могли заметить при обсуждении независимых и зависимых сущностей, правила, обозначающие то, что связь является идентифицирующей, определяются идентификацией дочерней сущности за счет использования идентификатора родительской сущности. В нашем примере ФИЛЬМОВ и КОПИЙ ФИЛЬМОВ для идентификации копии мы могли выбрать ее собственный уникальный номер. Однако, мы решили использовать идентификатор ФИЛЬМА и добавить вторую часть (номер копии) для того, чтобы отличить одну копию от другой.

Примечание: Как вы можете обнаружить, существует несколько преимуществ при передачи ключей дочерней сущности за счет идентификации связей, связанных с тем, что при этом упрощаются некоторые запросы к физической системе. Однако существуют и некоторые недостатки. С точки зрения реляционной теории предполагается, что передача ключей не должна происходить таким образом. Вместо этого, каждый сущность должен быть идентифицирована не только при помощи своего первичного ключа, но и при помощи логического дескриптора (handle) или дополнительного ключа, невидимого для пользователя системы. У этой теории существует убедительное доказательство и интересующиеся могут обратиться к работе E.F.Codd и C.J.Date на эту тему.

Неидентифицирующие связи

Неидентифицирующие связи, являющиеся уникальными для IDEF1X, также связывают родительский сущность с дочерней. Неидентифицирующие связи используются для отображения другого типа передачи атрибутов внешних ключей – передача в область данных дочерней сущности (под линией).

Неидентифицирующие связи отображаются пунктирной линией между объектами. Если вы свяжите объекты КОМАНДА и ИГРОК посредством неидентифицирующей связи, то модель будет выглядеть как показано на рис. 9.

Так как переданные ключи в неидентифицирующей связи не являются составной частью первичного ключа дочерней сущность, то этот вид связи не проявляется ни в одной идентифицирующей зависимости. В этом случае и КОМАНДА, и ИГРОК рассматриваются как независимые сущности.

Тем не менее взаимосвязь может отражать зависимость существования, если бизнес правило для взаимосвязи определяет то, что внешний ключ не может принимать значение NULL. Если внешний ключ должен существовать, то это означает, что запись в дочерней сущности может существовать только при наличии ассоциированной с ним родительской записи.

Примечание: Идентифицирующие и неидентифицирующие связи не являются особенностью IE метода. Однако, эта информации включена в вашу ERwin диаграмму в виде сплошной линии связи или пунктирной линии связи для обеспечения совместимости между IE и IDEF1X методами.

Роль (Rolename)

Когда внешние ключи мигрируют от родительской сущности через связь к дочерней сущности, они служат в модели двойную службу. Для понимания обеих ролей, иногда является полезным переименовать передаваемый ключ, для того, чтобы показать, какую он играет роль в дочерней сущности. Имя, назначаемое этому атрибуту, называется ролью.

er13.GIF (2210 bytes)

10. Пример имени Роли

Внешний ключ ИГРОКа “игрок-команда id.команда id” (рис.10) демонстрирует синтаксис определения и отображения имени роли. Первая половина (перед точкой) – это имя роли. Вторая часть – это собственное имя внешнего ключа, иногда называемое базовым именем.

Примечание: Имена Ролей также используются для совместимости модели с наследуемыми моделями данных, где внешний и первичный ключи имели разные названия.

Роли передаются посредством связи, также, как и другие атрибуты. Например, предположим, что мы расширили пример для того, чтобы показать какие ИГРОКИ забивали голы в различных матчах в сезоне. Имя роли “Игрок-команда-id” передается в сущность РЕЗУЛЬТАТИВНАЯ ИГРА (вместе с любым другим первичным ключом из родительской сущности), как показано ниже.

er14.GIF (3220 bytes)

Диаграмма, показывающая миграцию FK атрибута, имеющего ролевое имя

Определение Сущностей и Атрибутов

В моделировании данных и разработке систем в целом, очень важно выбирать понятные и четкие названия для объектов.

В результате можно получить понятную, четкую и недвусмысленную модель области деловой активности.

Стандарты и соглашения о названиях одинаковы для всех логических моделей, включая ERD и KB модели, описанные выше.

Названия сущностей и атрибутов

Нужно запомнить важное правило о том, что названия объектов должны быть только в единственном числе. Это упрощает чтение модели, содержащей выражения типа “РЕЙС <перевозит> от нуля и более ПАССАЖИРОВ” и “ПАССАЖИР <перевозится> одним РЕЙСОМ”. Когда мы называем сущность, мы также даем названия каждой записи.

Названия атрибутов тоже должны быть в единственном числе. Например “Имя персоны”, “количество премий для служащих” названы правильно. Именование атрибутов в единственном числе помогает избежать ошибок стандартизации, например, предоставление одним атрибутом более, чем одного фактора. Атрибуты “имена служащих” или “даты стартов и завершений” являются множественными и высвечивают ошибки дизайна атрибутов.

Еще одним хорошим правилом при названии атрибутов является использование имени сущности в качестве префикса. Правило гласит:

Префикс дает название.

Суффикс уточняет.

Используя это правило, вы можете решить большое количество проблем, связанных с дизайном. Например, в объекте ПОТРЕБИТЕЛЬ, вы можете давать следующие названия атрибутам “Имя потребителя”, “Номер потребителя”, “Адрес потребителя” и. т. д. Если у вас есть желание назвать атрибут “Потребитель – номер счета”, то используйте правило для того, чтобы убедиться, что суффикс “Номер счета” дает вам большую информацию о префиксе “Потребитель”. Если этого не происходит, то вы должны переместить атрибут в более подходящее место (например в СЧЕТ).

В отдельных случаях вы можете обнаружить, что достаточно сложно назвать сущность или атрибут, предварительно не определив его. Точное определение сущности или атрибута не менее важно, чем правильное название для него. Умение давать правильные информативные названия приходит с опытом и глубоким пониманием того, что представляет собой модель.

Так как модель данных является описанием деловой активности, то лучше всего выбирать информативные названия о данной деловой активности там, где это возможно. Если не существует подходящего названия из области бизнеса, то вы должны дать сущности название, полностью отражающее его предназначение в модели.

Синонимы, Омонимы и Псевдонимы

Не все говорят на одном языке. Мы также бываем не всегда точны когда даем чему-либо имена. Так как сущности и атрибуты идентифицируются в модели данных при помощи своих имен, то вам нужно убедиться в том, что значения синонимов точно определены, что они не приводят к появлению избыточных данных, а также, что они подробно описаны для того, чтобы в модели было понятно в каком объекте отражены какие факты.

Важно также выбирать имена, четко представляющие содержание сущностей и атрибутов. Например, мы отчетливо понимаем разницу между сущностями ПЕРСОНА, ПОТРЕБИТЕЛЬ и СЛУЖАЩИЙ. Несмотря на то, что все эти сущности представляют людей, они имеют различные характеристики и свойства. Выбирайте имена аккуратно, так, чтобы два разных объекта не назывались одинаково.

Например, если вы связаны с какой-либо областью бизнеса, в которой требуется, чтобы “потребители” назывались “покупателями”, то не стоит настаивать на таком названии. Может быть, вы столкнулись с псевдонимом, другим названием того же предмета, а может быть, и с другой, схожей с предыдущей, но отличной от нее, сущностью. В данном случае, “Покупатель” может оказаться одной из категорий “Потребителей”, обладающей свойствами, отличающими его от других категорий “Потребителей” или участвовать в связях, недоступных другим категориям “Потребителей”.

ERwin позволяет вам поддерживать уникальные названия в среде моделирования. Таким образом вы можете предотвратить случайное использование омонимов, неясных имен или повторения названий сущностей и атрибутов.

Примечание: Некоторые базы данных поддерживают множественные имена посредством использования определенных синонимов или псевдонимов, ERwin также поддерживает определения синонимов и псевдонимов, но только в физической модели.

Определения сущностей

Определение сущностей в вашей логической модели – это хороший способ определить назначение сущности и уточнить, какие данные должны войти в эту сущность.

Важно также, чтобы модель была как можно более ясной. Неопределенные сущности или атрибуты могут быть неверно истолкованы.

Составление хорошего определения не такая простая задача, как может показаться с первого взгляда.

Все знают кто такой ПОТРЕБИТЕЛЬ, не правда ли? Попробуйте составить определение сущности ПОТРЕБИТЕЛЬ так, чтобы к нему нельзя было придраться. Самые лучшие определения составляются после анализа точек зрения различных пользователей из области бизнеса и функциональных групп внутри предприятия. Определения, прошедшие под пристальным взором большого количества пользователей, имеют следующие преимущества:

Большинство организаций и частных лиц разрабатывает свои собственные соглашения и стандарты для определений. Некоторые из этих определений располагаются на нескольких страницах (например для ПОТРЕБИТЕЛЯ). Вы, может быть, захотите использовать на начальном этапе следующие далее понятия в качестве “стандартов” для структуры определения, несмотря на то, что IDEF1X и IE не предоставляют стандартов для определений:

Каждый из этих компонентов подробнее описывается ниже.

Описания

Описание должно быть четким и кратким выражением, которое сообщает о том является ли объект именно тем что вы хотели бы определить. Чаще всего такие описания могут быть довольно короткими. Остерегайтесь, однако того, чтобы описания не оказались слишком общими, и не использовали терминов, которые не были определены.

Приведем пару примеров, хорошего описания и спорного.

”ТОВАР – это нечто, имеющее стоимость, определяемую при обмене.”

Это хорошее определение, так как после его прочтения вы понимаете что ТОВАР это то, что можно было бы обменять на что-либо другое. Если, к примеру, кто-нибудь хотел бы дать нам три орешка и пластинку жвачки в обмен на мраморный шарик, то мы бы тогда знали, что шарик является ТОВАРОМ.

”Покупатель – это некто, покупающий что-то в нашей компании”.

Это не очень удачное описание. Вы можете перестать понимать кто такой “некто” если узнаете, что компания продает продукты другим компаниям. С другой стороны, с точки зрения бизнеса, может понабиться привлечение потенциальных покупателей, т. е. не только тех, которые уже покупали что-то в фирме. Стоит также подробнее раскрыть понятие “что-то”, чтобы определить - услуги это, товары, или некая их комбинация.

Примеры

Хорошей идеей является предоставление характерных примеров, связанных с определяемым объектом, так как примеры в большинстве случаев помогают лучше понять конкретное определение. Несмотря на то, что комментарии про орехи и мраморные шарики звучат не совсем “профессионально”, они помогают понять концепцию ТОВАРА.

Из примера становится понятно, что стоимость не всегда определяется “деньгами”.

Комментарии

Вы также можете внести общие комментарии о том, кто ответственен за данное определение, в каком оно находится состоянии, и когда оно последний раз изменялось как часть описания. В некоторых случаях вам также может понадобиться объяснить, чем отличаются имена этого объекта и связанного с ним объекта. Например, ПОКУПАТЕЛЬ может отличаться от ПРЕДПОЛАГАЕМОГО КЛИЕНТА.

Ссылки на определения и цикличность.

Если вы откроете словарь, то можете столкнуться со следующей ситуацией:

Определения по отдельности выглядят нормально, а когда рассматриваются вместе, становятся “цикличными”. Если с этим никак не бороться, то это может произойти с определениями сущности и атрибута. Например:

ПОКУПАТЕЛЬ: Это тот кто покупает один или несколько наших ПРОДУКТОВ.

ПРОДУКТ: Это то, что мы предлагаем на продажу ПОКУПАТЕЛЮ.

Это становится важно, когда вы определяете сущности и атрибуты в модели данных, где вы хотели бы избежать циклических ссылок.

Создание бизнес-словаря

Часто бывает удобным при определении сущностей и атрибутов использовать общие термины. Например: “ОБМЕН ВАЛЮТЫ - это соглашение между двумя СТОРОНАМИ, в котором они соглашаются обмениваться потоками двух различных валют в течение определенного количества времени. Курсы валют могут быть фиксированными на время действия соглашения, или могут быть плавающими.”

В этом примере определенные термины выделены. Использование такого стиля делает ненужным определение терминов в каждом месте использования.

Удобно использовать термины, не являющиеся именами сущностей или атрибутов, для общих определений, и ссылаться на эти определения как в случае ссылок на определения сущностей или атрибутов. Такого типа термины отмечаются жирным курсивом.

Может сложиться впечатление, что такая стратегия может привести к метанию между определениями. Альтернативой этому является только определение каждого термина при использовании. Если эти “внутренние определения” появляются в нескольких местах, то и изменять их придется в нескольких местах, а вероятность того, что удастся изменить все из них, очень мала.

Разработка словаря общих бизнес терминов может неоднократно пригодиться.

Он может стать “базовым” для использования в определениях при моделировании, а также может существенно помочь людям в общении.

Определения Атрибутов

Атрибуты, также как и сущности, должны быть четко определены. Используются те же правила – сравнивая объект с его определением, мы должны понять, подходит ли ему это определение. Однако, вы должны остерегаться таких вещей как “день-открытия-счета”, определенный как “Дата открытия СЧЕТА”. Далее вам может понадобиться пояснить, что подразумевается под словом “открытие”, чтобы сделать определение более четким и законченным.

Определения атрибутов, в общем случае, должны иметь такую же базовую структуру как и определения сущностей. Определения также должны, где только возможно, содержать правила, определяющие возможные значения атрибутов.

Правило подтверждения достоверности (validation rule) определяет набор значений, которые разрешены для использования атрибутом, ограничивает или запрещает домен допустимых значений. Эти значения имеют как абстрактный смысл, так и смысл с точки зрения бизнеса. Вы можете определить любые правила подтверждения достоверности или допустимые значения для атрибута в качестве части атрибута. ERwin может также назначить эти правила для атрибута, использующего домен. Поддерживаемые домены включают в себя текст, номер, дату и BLOB.

Такие определения атрибутов как коды и идентификаторы часто не годятся для примеров из области бизнеса. Таким образом, включение описания правил подтверждения достоверности для атрибута или допустимых значений, как правило является хорошей идеей. При определении правила проверки, хорошей практикой может стать расширение списка “значений”, которые атрибут может содержать. Предположим, что мы определяем атрибут “статус покупателя”.

Статус-покупателя: Код, описывающий взаимосвязь между ПОКУПАТЕЛЕМ и нашим бизнесом. Допустимые значения: A, P, F, N

Спецификация правила подтверждения достоверности не сильно помогает, так как не определяет того, что обозначают коды. Гораздо лучше описывать правила при помощи таблицы или списка значений, как показано ниже:

Что обозначает Допустимое значение

A: (Аctive) Действующий – ПОКУПАТЕЛЬ вовлечен в торговые отношения с нашей компанией.

P. (Prospect) Потенциальный – Некто, с кем бы нам хотелось установить контакт, которого на данный момент не существует.

F: (Former) Предыдущий – ПОКУПАТЕЛЬ ничего не покупал за последние 24 месяца.

N: Не поддерживается деловых контактов – Компания приняла решение не поддерживать деловых контактов с ПОКУПАТЕЛЕМ.

Названия ролей

Когда внешний ключ передается дочерней сущности при помощи связи, то вам может понадобиться написать новое или уточнить старое определение для атрибутов внешних ключей, которое будет объяснять его предназначение в дочерней сущности. В данном случае тот же атрибут передается одной и той же сущности неоднократно. Несмотря на то, что эти продублированные атрибуты могут быть одинаковыми, они могут иметь различные определения, так как они решают две разные задачи.

Давайте рассмотрим следующий ниже пример. Здесь мы видим ПУНКТОБМЕНАВАЛЮТЫ с двумя взаимосвязями с ВАЛЮТОЙ.

er15.GIF (4623 bytes)

Модель Пункта обмена валюты

Ключом для сущности ВАЛЮТА является “код валюты” (идентификатор допустимой ВАЛЮТЫ), за которой мы хотели бы проследить. Мы видим из связей, что одна ВАЛЮТА “покупается”, а другая “продается” ПУНКТОМОБМЕНАВАЛЮТЫ.

Мы также видим, что идентификатор ВАЛЮТЫ (“код валюты”) используется для идентификации обеих ВАЛЮТ. Идентификатор покупаемой валюты называется “код покупаемой валюты”, а идентификатор продаваемой, соответственно, “код продаваемой валюты”. Эти названия ролей показывают то, что эти атрибуты и атрибут “код валюты” не одно и тоже.

Достаточно глупо продавать валюту за ту же валюту в течении одного и того же времени и одинакового курса. Поэтому, для сделки (запись ПУНКТАОБМЕНАВАЛЮТЫ) “код покупаемой валюты” и “код продаваемой валюты” должны различаться. Мы можем уловить разницу между двумя кодами валют, если дадим различные имена ролей.

Атрибут/Ролевое имя Определения атрибута

код-валюты Уникальный идентификатор ВАЛЮТЫ.

код покупаемой валюты Идентификатор ВАЛЮТЫ (“код валюты”) покупаемой (приобретаемой) ВНЕШНЕЭКОНОМИЧЕСКОЙ ТОРГОВЛЕЙ

код продаваемой валюты Идентификатор ВАЛЮТЫ (“код валюты”) продаваемой ВНЕШНЕЭКОНОМИЧЕСКОЙ ТОРГОВЛЕЙ

Определения и проверка достоверности кодов покупаемой и продаваемой валюты основаны на “коде валют”. ”Код валюты” называется базовым атрибутом.

Стандарт IDEF1X устанавливает следующее условие: если два атрибута с одинаковыми именами передаются из одного и того же базового атрибута объекту, то атрибуты должны быть объединены.

Результатом объединения является один атрибут передаваемый посредством двух связей. Руководствуясь, IDEF1X стандартом, ERwin автоматически объединяет атрибуты внешние ключи. Если вы не хотите объединять переданные атрибуты, вы можете дать имена ролям атрибутов тогда же, когда вы даете имена взаимосвязи в Редакторе Взаимосвязей в ERwin.

Определения и бизнес-правила

Бизнес-правила были упомянуты раньше в качестве составной части модели данных. Эти правила принимают форму связей, ролевых имен, потенциальных ключей и других, еще не исследованных моделирующих структур, используя категории обобщений, ссылочную целостность и т.д. Бизнес-правила должны быть также охвачены определениями сущностей и атрибутов, а также правилами проверки данных (validation rules).

Например, сущность ВАЛЮТА на предыдущей диаграмме могла бы быть определена как набор допустимых валют, имеющих хождение во всем мире, или как составная часть этого набора, т.е список валют, выбранных нашей фирмой для каждодневных деловых операций. Различие небольшое, но очень важное. В последнем случае вводится бизнес-правило, оно же “политическое выражение”.

Это проявляет себя в правилах проверки для “кода валют”. Оно ограничивает число допустимых значений “кода валюты”. Поддержка бизнес-правила превращается в задачу поддержки таблицы допустимых значений для ВАЛЮТЫ. Для того, чтобы разрешить или запретить продажу ВАЛЮТ, вы просто должны создать или уничтожить записи в таблице допустимых значений.

Атрибуты “код покупаемой валюты” и “код продаваемой валюты” также ограничены. Далее они еще больше ограничиваются правилом проверки достоверности, которое гласит – “код покупаемой валюты” и “код продаваемой валюты” не должны быть одинаковыми, поэтому каждый зависит от значения другого атрибута. Используя ERwin, правила проверки достоверности можно адресовать определениям атрибутов, а также подробно описать при помощи правил проверки достоверности, значений, установленных по умолчанию и списков допустимых значений.

(продолжение в следующем номере)


Copyright © 1994-2016 ООО "К-Пресс"