Нотация idef1х для построения логической модели данных — студенческий портал

Модели данныхимеют два уровня представления модели – логическийи физический. Логический уровень– это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Фамилия сотрудника», «Отдел».

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

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

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

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

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

• Создание логической модели данных
• Различают три уровня логической модели, отличающиеся по глубине представления информации о данных:
• − диаграмма сущность-связь (Entity Relationship Diagram (ERD));
• − модель данных, основанная на ключах (Key Based model (KB));
• − полная атрибутивная модель (Fully Attributed model (FA)).

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

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

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

Сущности и атрибуты

Основные компоненты ER-диаграммы – это сущности, атрибуты и связи. Каждая сущность является множеством подобных индивидуальных объектов, называемых экземплярами.

Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта.

С точки зрения БД (физическая модель) сущности соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы.

Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущность Клиент(но не Клиенты!) с атрибутами Номер Клиента, Фамилия Клиентаи Адрес Клиента.

На уровне физической модели ей может соответствовать таблица Clientс колонками Client_number, Client_name и Client_address.

Связи

Связьявляется логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой (рис. 5).

Рис. 5. Связь

Имя связи выражает некоторое ограничение или бизнес-правило и облегчает чтение диаграммы, например: каждый КЛИЕНТ «вносит/снимает» СРЕДСТВА.

Связь показывает, какие именно действия делает клиент. По умолчанию имя связи на диаграмме не показывается. Для отображения имени следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Relationship Displayи затем включить опцию verb Phrase.

На логическом уровне можно установить идентифицирующую связь один — ко — многим, связь многие — ко — многим и не идентифицирующую связь один — ко — многим (соответственно это кнопки слева направо в палитре инструментов).

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

Рис. 6. Идентифицирующая связь

Экземпляр зависимой сущности определяется только через отношение к родительской сущности.

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

Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности новые атрибуты помечаются как внешний ключ – (FK).

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

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

7) служит для связывания независимых сущностей.

Рис. 7. Неидентифицирующая связь

1. Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной линией.
2. Мощность связи (Cardinality)– служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности:
3. 1) общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом;
4. 2) символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение);
5. 3) символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения);
6. 4) цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности.

Имя связи (Verb Phrase)– фраза, характеризующая отношение между родительской и дочерней сущностями.

Для связи один — ко — многим идентифицирующей или не идентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child).

Для связи многие — ко — многим следует указывать имена как Parent-to-Child,так и Child-to-Parent.

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

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

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

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

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

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

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

Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более – только имя роли.

Связь многие — ко — многимвозможна только на уровне логической модели данных. Такая связь обозначается сплошной линией с двумя точками на концах (рис. 8).

Рис. 8. Связь многие — ко — многим

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



Источник: https://infopedia.su/14x882e.html

IDEF1X-модель базы данных web-ориентированной информационной системы оценки семантического качества меню пользователя

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

Ключевые слова: меню пользователя, семантическое качество, коэффициент успешности, коэффициент прямого выбора, IDEF1X-модель, база данных.

Терминология меню пользователя предметно-ориентированной информационной системы [1–4, с. 4–5] определяет эффективность семантической интерпретации отношений между пунктами меню и функциями информационной системы.

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

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

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

В работах [5–6, с. 5] предлагаются различные подходы к решению проблемы создания качественного меню, такие как: оценка качества пунктов меню, минимизация времени поиска определенного пункта меню, семантический подход к решению проблемы понимания пользователем меню. В работе [7, с.

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

В настоящее время можно выделить следующие web-сервисы для компьютерной поддержки процесса разработки и качественной оценки меню: Naview (www.naviewapp.com), C-Inspector (www.c-inspector.com), TreeJack (http://www.optimalworkshop.com/). К сожалению, все они являются платными и англоязычными, но имеют бесплатные режимы доступа, на основе использования которых можно оценить функциональные возможности и принципы работы данных web-сервисов.

• В таблице 1 приведены результаты сравнительного анализа web-сервисов для разработки и оценки качества меню.
• Таблица 1
• Сравнительный анализ web-сервисов Naview, C-Inspector, Treejack

КритерииПродукты	Naview	C-Inspector	Treejack
Возможность просмотра результатов по каждому пункту меню	Да	Да	Да
Просмотр результатов по каждому пользователю	Нет	Да	Да
Графическое представление процесса выбора пользователем пункта меню	Нет	Да	Да
Формирование пользователей по группам	Нет	Да	Да
Выдача рекомендаций по внесению изменений в меню	Да	Нет	Нет
Представление результатов в читаемом формате (pdf)	Нет	Нет	Да
Возможность загрузки меню из файла	Нет	Да	Да.

1. Предлагаемое математическое описание критериев семантического качества меню [8] может быть представлено следующим множеством параметров:
2. а) Коэффициент положительных исходов выполнения тестового задания для i-го пункта меню:
3. где  — количество пользователей, участвующих в выполнении тестового задания для i-го пункта меню;  — количество пользователей, успешно выполнивших тестовое задание для i-го пункта меню;
4. б) Коэффициент успешности меню:           
5. где  — количество пунктов меню.
6. в) Коэффициент прямого выбора для i-го пункта меню — отношение минимального числа элементов меню, выбор которых необходим для успешного выполнения тестового задания для i-го пункта меню, к общему количеству элементов меню, выбранных пользователем в процессе ответа на тестовое задание:
7. где  — минимальное количество элементов меню, выбор которых необходим для успешного выполнения тестового задания для i-го пункта меню;  — количество элементов меню, выбранных j-ым пользователем при выполнении тестового задания для i-го пункта меню.
8. г) Среднее время успешного выполнения тестового задания (включая время, затраченное на его чтение) для i-го пункта меню:

где – время, затраченное j-ым пользователем на чтение тестового задания для i-го пункта меню; – время выбораj-ым пользователем ответа на тестовое задание для i-го пункта меню.

Рис. 1. IDEF1X-модель базы данных web-ориентированной информационной системы

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

• IDEF1X-модель базы данных представлена следующим набором элементов (таблица 2):
• Таблица 2
• Функциональное назначение элементов IDEF1X-модели базы данных

Наименование элемента	Хранимая информация
Меню	Проект меню пользователя информационной системы
Пункты-Меню	Структура меню
Разработчики-Меню	Пользователи, которые имеют возможность: проектировать меню, создавать тестовые задания, регистрировать респондентов, создавать группы респондентов
Респонденты	Пользователи, принимающих участие в процессе оценки семантического качества меню
Группы	Группы пользователей-респондентов
Респонденты-Группы	Распределение пользователей-респондентов по группам
Тестовое-Задание	Тестовые задания для оценки семантического качества пунктов меню
Тесты	Наборы тестовых заданий для оценки семантического качества меню
Структура-Тестов	Распределение тестовых заданий по тестам
Группы-Тесты	Права на участие групп-респондентов в тестировании меню
Ответы-Респондентов	Результаты выполнения тестовых заданий пользователями-респондентами
Процесс-Ответа	Пункты меню, выбранные пользователем-респондентом в процессе выполнения тестового задания

Предлагаемая IDEF1X-модель базы данных ориентирована на обеспечение информационной поддержки процесса оценки семантического качества меню пользователя и может быть использована при создании web-ориентированной информационной системы оценки качества меню более высокого уровня [9, с. 5].

Литература:

1.         Рыбанов А. А. Web-ориентированный программный модуль ведения базы данных рабочих программ учебных дисциплин [программа]: свидетельство о государственной регистрации программы для ЭВМ № 2013612009. — Зарегистрирована в Реестре программ для ЭВМ 11.02.13.

Источник: https://moluch.ru/archive/52/6882/

Нотация IDEF1X как средство построения модели данных

Для проектирования информационной модели бизнес-процессов используется методология IDEF1X Метод моделирования, который поддерживает графическое описание:

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

Документирование модели. Многие СУБД имеют ограничение на именование объектов (например, ограничение на длину имени таблицы или запрет использования специальных символов — пробела и т. п.). Зачастую разработчики ИС имеют дело с нелокализованными версиями СУБД.

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

Кроме того, проектировщики баз данных нередко злоупотребляют «техническими» наименованиями, в результате таблица и колонки получают наименования типа RTD_324 или CUST_A12 и т. д.

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

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

Сущность

Сущность(Entity) — это некоторый объект, идентифицируемый в рабочей среде пользователя, нечто такое, за чем пользователь хотел бы наблюдать.

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

Экземпляр сущности (Entity instance) представляет конкретную сущность, такую как КЛИЕНТ 12345; он описывается значениями атрибутов данной сущности. Сущности одного и того же типа группируются в классы сущностей (Entity classes). Так, класс сущностей СОТРУДНИК является совокупностью всех сущностей СОТРУДНИК.

Класс сущностей — это совокупность сущностей, которая описывается структурой или форматом сущностей, составляющих данный класс.

Структура (формат) сущности — множество всех атрибутов сущности. Обычно класс сущностей содержит множество экземпляров сущности. Например, класс КЛИЕНТ содержит множество экземпляров — по одному на каждого клиента, для которого имеется запись в базе данных. Пример класса сущностей и двух экземпляров сущности показан на следующем рисунке

Атрибут

Атрибут — составная часть сущности (свойство сущности), которая описывает отдельную, атомарную смысловую область сущности с определением для нее:

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

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

Атрибут представляет тип характеристик или свойств, ассоциированных со множеством реальных или абстрактных объектов (людей, мест, событий, состояний, идей, пар предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества.

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

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

Связь

Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

Рекомендуемые страницы:

Воспользуйтесь поиском по сайту:

Источник: https://megalektsii.ru/s23665t1.html

Нотация idef1x

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

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

Будучи статическим методом разработки, IDEF1X изначально не предназначен для динамического анализа по принципу «AS-IS», тем не менее он иногда применяется в этом качестве как альтернатива методу IDEF1.

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

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

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

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

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

Связи между сущностями. Связи в 1DEF1X представляют собой ссылки, соединения и ассоциации между сущностями. Связи — это суть глаголов, которые показывают, как соотносятся сущности между собой. Ниже приведен ряд примеров связи между сущностями:

• • Отдел нескольких Сотрудников;
• • Самолет нескольких Пассажиров;
• • Сотрудник разные Отчеты.

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

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

На рис. 5.1 приводится диаграмма связи между Сотрудником и Отделом.

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

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

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

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

Идентификация сущностей. Сущность описывается в диаграмме IDEF1X графическим объектом в виде прямоугольника. На рис. 5.2 приведен пример IDEFlX-диаграммы.

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

Рис. 5.2. Пример диаграммы

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

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

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

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

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

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

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

Правила устанавливают, что атрибуты и группы атрибутов должны:

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

• Для наглядного представления о том, как целесообразно выбирать первичные ключи, приведем следующий пример — выберем первичный ключ для знакомой нам сущности «Сотрудник».
• Атрибут «Ш сотрудника» является потенциальным ключом, так как он уникален для всех экземпляров сущности «Сотрудник».
• Атрибут «Имя сотрудника» не очень хорош для потенциального ключа, так как среди служащих на предприятии может быть, например, два Ивановых или Петровых.
• Атрибут «Номер страхового полиса сотрудника» является уникальным, но проблема в том, что сотрудник может не иметь такового.
• Комбинация атрибутов «Имя сотрудника» и «Дата рождения сотрудника» может оказаться удачной для наших целей и стать искомым потенциальным ключом.

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

Источник: https://studref.com/382612/informatika/notatsiya_idef1x

Концептуальное проектирование с использованием методологии IDEF1X — Учебная и научная деятельность Анисимова Владимира Викторовича

• Проектирование информационных систем
• Лекции
• Тема 7. Разработка информационной модели
• МЕТОДОЛОГИЯ IDEF1X

7.2. Концептуальное проектирование с использованием методологии IDEF1X.

7.3. Пример построения концептуальной схемы.

7.2. Концептуальное проектирование с использованием методологии IDEF1X

Цель концептуального проектирования – создание концептуальной схемы данных на основе представлений о предметной области каждого отдельного типа пользователей.

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

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

Ниже рассматривается последовательность шагов при концептуальном проектировании [1, 21].

1. Выделение сущностей.

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

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

Например, для задачи определения допускаемых скоростей основными объектами (наборами объектов) являются: нормативно-справочная информация, информация об участках дороги, задания на расчет, ведомости допускаемых скоростей и т.д.

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

1. Возможные трудности в определении объектов связаны с использованием постановщиками задачи:
2. — примеров и аналогий при описании объектов (например, вместо обобщающего понятия «работник» они могут упоминать его функции или занимаемую должность: «руководитель», «ответственный», «контролер», «заместитель»);
3. — синонимов (например, «допускаемая скорость» и «установленная скорость», «разработка» и «проект», «барьерное место» и «ограничение скорости»);
4. — омонимов (например, «программа» может обозначать компьютерную программу, план предстоящей работы или программу телепередач).

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

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

• Каждая сущность должна обладать некоторыми свойствами:
• — должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;
• — обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;

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

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

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

Источник: https://www.sites.google.com/site/anisimovkhv/learning/pris/lecture/tema7/tema7_2

IDEF1X

Not to be confused with Idefix.
Example of an IDEF1X diagram.

Integration DEFinition for information modeling (IDEF1X) is a data modeling language for the development of semantic data models. IDEF1X is used to produce a graphical information model which represents the structure and semantics of information within an environment or system.[1]

IDEF1X permits the construction of semantic data models which may serve to support the management of data as a resource, the integration of information systems, and the building of computer databases. This standard is part of the IDEF family of modeling languages in the field of software engineering.

Overview

A data modeling technique is used to model data in a standard, consistent and predictable manner in order to manage it as a resource.

It can be used in projects requiring a standard means of defining and analyzing the data resources within an organization.

Such projects include the incorporation of a data modeling technique into a methodology, managing data as a resource, integrating information systems, or designing computer databases. The primary objectives of the IDEF1X standard are to provide:[1]

• Means for completely understanding and analyzing an organization's data resources
• Common means of representing and communicating the complexity of data
• A technique for presenting an overall view of the data required to run an enterprise
• Means for defining an application-independent view of data which can be validated by users and transformed into a physical database design
• A technique for deriving an integrated data definition from existing data resources.

A principal objective of IDEF1X is to support integration. The approach to integration focuses on the capture, management, and use of a single semantic definition of the data resource referred to as a “conceptual schema.

” The “conceptual schema” provides a single integrated definition of the data within an enterprise which is not biased toward any single application of data and is independent of how the data is physically stored or accessed.

The primary objective of this conceptual schema is to provide a consistent definition of the meanings of and interrelationships between data that can be used to integrate, share, and manage the integrity of data. A conceptual schema must have three important characteristics:[1]

• Consistent with the infrastructure of the business and true across all application areas
• Extendible, such that new data can be defined without altering previously defined data
• Transformable to both the required user views and to a variety of data storage and access structures.

History

The need for semantic data models was first recognized by the U.S. Air Force in the mid-1970s as a result of the Integrated Computer Aided Manufacturing (ICAM) Program.

The objective of this program was to increase manufacturing productivity through the systematic application of computer technology. The ICAM Program identified a need for better analysis and communication techniques for people involved in improving manufacturing productivity.

As a result, the ICAM Program developed a series of techniques known as the IDEF (ICAM Definition) Methods which included the following:[1]

• IDEF0 used to produce a “function model” which is a structured representation of the activities or processes within the environment or system
• IDEF1 used to produce an “information model” which represents the structure and semantics of information within the environment or system
• IDEF2 used to produce a “dynamics model”.

Источник: https://en.wikipedia.org/wiki/IDEF1X

Назначение IDEF1X

IDEF1X — методология моделирования данных, основанная на семантике, т.е. на трактовке данных в контексте их взаимосвязи с другими данными.

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

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

С помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области(сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами(связей).Нотация была введена Ченом (Chen) и получила дальнейшее развитие в работах Баркера (Barker). Методология IDEF1X определяет стандарты терминологии, используемой при информационном моделировании, и графического изображения типовых элементов на диаграммах.

IDEF1X является методом разработки реляционных БД основанном на применении условного синтаксиса, специально разработанного для построения концептуальных схем. КОНЦЕПТУАЛЬНАЯ СХЕМА — универсальное представление структуры данных в рамках предприятия, независимое от конечной реализации БД и аппаратной платформы.

IDEF1X является статическим методом проектирования логической структуры БД после того, как все информационные ресурсы исследованы (например, с помощью метода IDEF1), определены с помощью функциональной модели информационные потоки предприятия и принято решение о внедрении реляционной БД, как части корпоративной ИС.

Однако, в связи с тем, что методология IDEF1X разработана специально для построения реляционных ИС, то создаваемая аналитиком IDEF1X-модель является некорректной для при-менения методов объектно-ориентированной реализации. IDEF1X не следует применять для построения не реляционных систем:

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

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

Источник: http://itstan.ru/funk-strukt-analiz/naznachenie-idef1x.html

Методология. Стандарт IDEF1

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

Метод IDEF1 создан Т.Рэмей, однако базируется он на подходе П.Чена и позволяет создать структурную модель данных, которая равноценна реляционной модели в третьей нормальной форме.

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

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

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

Также при помощи IDEF1 создается изучение уже существующей информации.

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

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

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

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

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

Преимущества IDEF1

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

1. Структурой данных, которая применяется для управления, использования, накопления и приобретения информации
2. Информацией, которая относится к реальным объектам
3. Абстрактными и физическими зависимостями, которые есть среди реальных объектов
4. Реальными объектами

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

Основные концепции моделирования IDEF1

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

1. Первая область — реальный мир (то есть некая совокупность интеллектуальных и физических объектов: идей, вещей, людей и т.д., а также все характеристики данных объектов и зависимость между ними)
2. Вторая — информационная область (включает уже существующие отображения объектов информации предыдущей области и их свойства)

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

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

Семантика и терминология метода IDEF1

Данная методология делит структурные элементы области информации, их взаимосвязи и свойства на определенные классы. Базовым ее понятием является понятие сущности. Класс сущностей — это совокупность информации, которая накоплена и хранится внутри предприятия и соответствует определенной группе объектов или же одному объекту реальной действительность.

Концептуальные свойства сущностей:

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

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

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

Согласно методологии IDEF1, каждый выше отмеченный класс, предполагает условное собственное графическое отображение.

На рис. № 1 можно увидеть пример IDEF1 – диаграммы. Здесь представлены две сущности, которые имеют имена «Сотрудник» и «Отдел», а также взаимосвязь между ними с именем «работает в».

Имя данной взаимосвязи всегда используется в форме глагола.

Если же между несколькими объектами реальной действительности не образуется определенной зависимости, то, как предполагает методология IDEF1, взаимосвязь между их сущностями тоже отсутствует.

Таким образом, стандарт IDEF1 — это метод анализа и изучения. Он качественно отличается от похожего стандарта IDEF1X, который предназначен для создания реляционной структуры базы данных, оперирующей с определенными объектами мира физического.

Похожее

Источник: http://iteranet.ru/it-novosti/2013/10/16/metodologiya-standart-idef1/