Заглавная страница Избранные статьи Случайная статья Познавательные статьи Новые добавления Обратная связь FAQ Написать работу КАТЕГОРИИ: АрхеологияБиология Генетика География Информатика История Логика Маркетинг Математика Менеджмент Механика Педагогика Религия Социология Технологии Физика Философия Финансы Химия Экология ТОП 10 на сайте Приготовление дезинфицирующих растворов различной концентрацииТехника нижней прямой подачи мяча. Франко-прусская война (причины и последствия) Организация работы процедурного кабинета Смысловое и механическое запоминание, их место и роль в усвоении знаний Коммуникативные барьеры и пути их преодоления Обработка изделий медицинского назначения многократного применения Образцы текста публицистического стиля Четыре типа изменения баланса Задачи с ответами для Всероссийской олимпиады по праву Мы поможем в написании ваших работ! ЗНАЕТЕ ЛИ ВЫ?
Влияние общества на человека
Приготовление дезинфицирующих растворов различной концентрации Практические работы по географии для 6 класса Организация работы процедурного кабинета Изменения в неживой природе осенью Уборка процедурного кабинета Сольфеджио. Все правила по сольфеджио Балочные системы. Определение реакций опор и моментов защемления |
Краткое описание методологии IDEF1XСодержание книги
Поиск на нашем сайте
Модели данных имеют два уровня представления модели – логический и физический. Логический уровень – это абстрактный взгляд на данные, на нем данные представляются так, как выглядят в реальном мире, и могут называться так, как они называются в реальном мире, например «Фамилия сотрудника», «Отдел». Объекты‑модели, представляемые на логическом уровне, называются сущностями и атрибутами. Логическая модель может быть построена на основе другой логической модели, например на основе модели процессов. Логическая модель данных является универсальной и никак не связана с конкретной реализацией СУБД. Физическая модель данных, напротив, зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует, физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Разделение модели данных на логические и физические позволяет решить несколько важных задач. Документирование модели. На физическом уровне объекты БД могут называться так, как того требуют ограничения СУБД. На логическом уровне можно этим объектам дать синонимы – имена более понятные неспециалистам, в том числе на кириллице и с использованием специальных символов. Масштабирование. Создание модели данных, как правило, начинается с создания логической модели. После описания логической модели проектировщик может выбрать необходимую СУБД и автоматически создать соответствующую физическую модель. Создание логической модели данных Различают три уровня логической модели, отличающиеся по глубине представления информации о данных: − диаграмма сущность-связь (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. Неидентифицирующая связь
Идентифицирующая связь показывается на диаграмме сплошной линией с жирной точкой на дочернем конце связи, неидентифицирующая – пунктирной линией. Мощность связи (Cardinality) – служит для обозначения отношения числа экземпляров родительской сущности к числу экземпляров дочерней. Различают четыре типа мощности: 1) общий случай, когда одному экземпляру родительской сущности соответствуют 0, 1 или много экземпляров дочерней сущности, не помечается каким-либо символом; 2) символом P помечается случай, когда одному экземпляру родительской сущности соответствуют 1 или много экземпляров дочерней сущности (исключено нулевое значение); 3) символом Z помечается случай, когда одному экземпляру родительской сущности соответствуют 0 или 1 экземпляр дочерней сущности (исключены множественные значения); 4) цифрой помечается случай точного соответствия, когда одному экземпляру родительской сущности соответствует заранее заданное число экземпляров дочерней сущности. Имя связи (Verb Phrase) – фраза, характеризующая отношение между родительской и дочерней сущностями. Для связи один - ко - многим идентифицирующей или не идентифицирующей достаточно указать имя, характеризующее отношение от родительской к дочерней сущности (Parent-to-Child). Для связи многие - ко - многим следует указывать имена как Parent-to-Child,так и Child-to-Parent. Имя роли (функциональное имя) – это синоним атрибута внешнего ключа, который показывает, какую роль играет атрибут в дочерней сущности. По умолчанию в списке атрибутов показывается только имя роли. Для отображения полного имени атрибута (как функционального имени, так и имени роли) следует в контекстном меню, которое появляется, если щелкнуть левой кнопкой мыши по любому месту диаграммы, не занятому объектами модели, выбрать пункт Entities Display и затем включить опцию Attribute. Полное имя показывается как функциональное имя и базовое имя, разделенные точкой. Обязательным является применение имен ролей в том случае, когда два или более атрибутов одной сущности определены по одной и той же области, т. е. они имеют одинаковую область значений, но разный смысл. Другим примером обязательности присвоения имен ролей являются рекурсивные связи (иногда их называют «рыболовный крючок» – fish hook), когда одна и та же сущность является и родительской, и дочерней одновременно. При задании рекурсивной связи атрибут должен мигрировать в качестве внешнего ключа в состав неключевых атрибутов той же сущности. Атрибут не может появиться дважды в одной сущности под одним именем, поэтому обязательно должен получить имя роли. Рекурсивная связь может быть только неидентифицирующей. Вид рекурсивной связи, называющийся иерархической рекурсией, задает связь, когда экземпляр родительской сущности может иметь множество экземпляров дочерней сущности, но экземпляр дочерней сущности может иметь только один экземпляр родительской сущности. Другим видом рекурсии является сетевая рекурсия, когда экземпляр родительской сущности может иметь множество экземпляров дочерней сущности и, наоборот, экземпляр дочерней сущности может иметь множество экземпляров родительской сущности. Сетевая рекурсия задает паутину отношений между экземплярами родительской и дочерней сущностей. Это случай, когда сущность находится сама с собой в связи многие - ко - многим. Для разрешения связи многие - ко - многим необходимо создать новую сущность. Если атрибут мигрирует в качестве внешнего ключа более чем на один уровень, то на первом уровне отображается полное имя внешнего ключа (имя роли + базовое имя атрибута), на втором и более – только имя роли. Связь многие - ко - многим возможна только на уровне логической модели данных. Такая связь обозначается сплошной линией с двумя точками на концах (рис. 8).
Рис. 8. Связь многие - ко - многим
Для внесения связи следует установить курсор на кнопке с изображением сплошной линии с двумя точками на концах в палитре инструментов, щелкнуть сначала по одной, а затем по другой сущности. Связь многие - ко - многим должна именоваться двумя фразами – в обе стороны. Это облегчает чтение диаграммы.
|
||||
Последнее изменение этой страницы: 2016-12-17; просмотров: 1186; Нарушение авторского права страницы; Мы поможем в написании вашей работы! infopedia.su Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав. Обратная связь - 13.59.68.161 (0.009 с.) |