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

Методология IDEF1X

Case-средство ERWin поддерживает методологию IDEF1X и стандарт IE (Information engineering). Методология IDEF1X подразделяется на уровни, соответствующие проектируемой модели данных системы. Каждый такой уровень соответствует определенной фазе проекта. Такой подход полезен при создании систем по принципу «сверху вниз».

Верхний уровень состоит из Entity Relation Diagram (Диаграмма сущность-связь) и Key-Based model (Модель данных, основанная на ключах). Диаграмма сущность-связь определяет сущности и их отношения. Модель данных, основанная на ключах, дает более подробное представление данных. Она включает описание всех сущностей и первичных ключей, которые соответствуют предметной области.

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

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

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

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

Три уровня моделей, объединяющие в себе логические модели, состоят из Entity Relationship Diagram (Диаграмма сущность-связь), the Key-Based (Модель данных, основанная на ключах) Model и the Fully Attributed model (Полная атрибутивная модель).

Рис. 5.1. Уровни методологии IDEF1X

1.1. Диаграмма сущность-связь

Диаграмма сущность-связь является самым высоким уровнем в модели данных и определяет набор сущностей и атрибутов проектируемой системы. Целью этой диаграммы является формирование общего взгляда на систему для ее дальнейшей детализации.

1.2. Модель данных, основанная на ключах

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

1.3. Полная атрибутивная модель

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

1.4 Компоненты логической модели данных

Сущности

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

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

Рис. 5.2. Пример использования ERwin для отображения сущностей в простейшей форме.

Атрибуты

Атрибуты представляют данные об объектах, которые необходимо иметь корпорации. Атрибуты представляются именами существительными, которые описывают характеристики сущностей.

Рисунок 2.3 иллюстрирует несколько примеров атрибутов.

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

Отношения

Рис. 5.4. Примеры отношений используют нотацию IE системы ERwin, в которой «коровьи копыта» или «трезубцы» отображают многие стороны отношений.

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

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

логической модели в СУБД.

Трансформационная модель

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

Перед началом проектирования БД необходимо убедиться в обеспечении следующих требований:

Модель СУБД

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

Преимущества от использования CASE-средства ERWin

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

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

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

Кроме того, ERWin предоставляет возможность формирования большого числа отчетов, отражающих текущее состояние процесса проектирования БД.

Инструментарий ERWin

При запуске ERWin появляется основная панель инструментов и палитра инструментов (табл. 5.1).

Таблица 5.1. Основная панель инструментов ERWin

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

Рис. 5.5. Палитра инструментов на логическом уровне

1. Слева направо, верхний ряд:

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

2. Слева направо, нижний ряд:

На физическом уровне палитра инструментов имеет следующий вид (рис. 2.6).

Рис. 5.6. Палитра инструментов на физическом уровне

Контрольные вопросы

Источник

Метод моделирования «сущность-связь»

Нормализация модели «сущность-связь»

Имеются 3 подуровня логического уровня модели данных, отличающихся по глубине представления информации о данных:

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

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

Процесс нормализации сводится к последовательному приведению структуры данных к нормальным формам – формализованным требованиям к организации данных. Известно 6 нормальных форм:

Нормальные формы основаны на понятии функциональной зависимости (в дальнейшем будет использоваться термин «зависимость»). Приведем формальное определение для функциональной зависимости.

Функциональная зависимость (FD). Атрибут B сущности E функционально зависит от атрибута A сущности E тогда и только тогда, когда каждое значение A в E связало с ним точно одно значение B в E, т. е. A однозначно определяет B.

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

На рис. 6.15 в сущности «Сотрудник» значения атрибутов Фамилия, Имя и Отчество однозначно определяются значением атрибута Табельный номер, т. е. атрибуты Фамилия, Имя и Отчество зависят от атрибута Табельный номер.

Рассмотрим нормальные формы.

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

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

Для приведения сущности к первой нормальной форме следует:

Предположим, что сущность «Проект» содержит информацию о проекте, которым руководит сотрудник, причем информация содержится как непосредственно о проекте, так и о руководителе проекта ( рис. 6.17). Атрибуты Фамилия, Имя, Отчество и Должность зависят только от атрибута табельный номер руководителя, но вовсе не от атрибута Наименование проекта. Другими словами, имеется зависимость только от части ключа.

Для приведения сущности ко второй нормальной форме следует:

Вторая нормальная форма позволяет избежать следующих аномалий при выполнении операций:

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

Для приведения сущности к третьей нормальной форме следует:

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

Третья нормальная форма также позволяет избежать ряда аномалий.

Четвертая нормальная форма (4NF) требует отсутствия многозначных зависимостей между атрибутами.

В примере на рис. 6.20 (слева) преподаватель читает лекции по нескольким предметам и курирует несколько групп студентов. Одна группа студентов может изучать несколько предметов, одному предмету могут обучаться несколько групп студентов. Имеется многозначная зависимость между атрибутами Предмет и Группа. При этом возможна аномалия: если у преподавателя появляется новая группа, приходится добавлять несколько записей, по числу читаемых предметов.

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

Резюме

Метод моделирования » сущность-связь » был предложен С. Ченом в 1976 году. Ряд исследователей разработали несколько графических нотаций для представления элементов модели. Проектировщик ХД может выбрать графическую нотацию по своему вкусу.

Независимо от выбранной нотации, действия проектировщика ХД при ER-моделировании сводятся к следующему алгоритму.

Для каждой сущности предметной области базы данных необходимо:

Для каждой связи между сущностями необходимо:

Источник

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

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

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

— диаграмм сущность-связь (Entity Relationship Diagram, ERD);

— модель данных, основанная на ключах (Key Based model, KB);

— полная атрибутная модель (Fully Attributed model, FA).

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

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

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

Основные компоненты диаграммы ERwin – это сущности, атрибуты и связи.

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

Сущность на диаграмме изображается прямоугольником. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие сведения (см. рис. 34).

Рис. 34. Сущность с заполненными атрибутами.

Экземпляры независимой сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями; зависимая сущность, наоборот, не может быть уникально идентифицирована без определения ее связей с другими сущностями. Зависимая сущность отображается в ERwin прямоугольником с закругленными углами (см. рис. 35).

Рис. 35. Зависимая сущность с заполненными атрибутами.

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

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

Для добавления сущности следует нажать кнопку , а затем – щелкнуть «мышью» по свободному месту диаграммы. После этого по созданному элементу следует щелкнуть два раза левой кнопкой «мыши». В открывшемся диалоговом окне Attributes (см. рис. 36) следует:

— при нажатии кнопки ввести название сущности;

— при нажатии кнопки New ввести название и тип добавляемого атрибута (список форматов возможных типов представлен в табл. 5), а при необходимости установить ему ключевой признак вводом флажка Primary Key.

Рис. 36. Окно для заполнения атрибутов сущности.

Расшифровка назначения типов атрибутов

Для каждого атрибута имеется возможность ввода дополнительных характеристик, расположенных на вкладках окна Attributes:

— General (основные характеристики атрибута);

— Datatype (выбранный формат атрибута);

— Note (комментарий для данного атрибута);

— UDP (свойства атрибутов сущности, добавляемых пользователем);

— Key Group (отношение выбранного атрибута к ключевым признакам);

— History (история возникновения атрибута).

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

Пример логической модели данных представлен на рис. 37.

Для компактного расположения модели на листе бумаги при печати следует вызвать в меню File режим Print, а в открывшемся окне Print (см. рис. 38) нажать кнопку Fit model.

Рис. 37. Пример логической модели данных

Рис. 38. Окно для настройки параметров печати.

Источник

Правила ссылочной целостности

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

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

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

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

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

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

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

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

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

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

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

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

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

Ключевая область объекта СТРАХОВАНИЕ содержит поле уникальный идентификатор Код договора, в области данных находятся поля «Страховая сумма», «Дата страхования» и т.д.

Рис. П6. Ключевые поля

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

Например, для того, чтобы корректно использовать сущность СТРАХОВАНИЕ в IDEF1X модели данных (а позже в базе данных), необходимо иметь возможность уникально идентифицировать записи.

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

Уникальным образом идентифицировать экземпляр сущности.

Не использовать NULL значений.

Не изменяться со временем. Экземпляр идентифицируется при помощи ключа. При изменении ключа, соответственно меняется экземпляр.

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

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

Для наглядного представления о том, как целесообразно выбирать первичные ключи, приведем следующий пример – выберем первичный ключ для знакомой нам сущности «СОТРУДНИК»:

Атрибут «ID сотрудника» является потенциальным ключом, так как он уникален для всех экземпляров сущности СОТРУДНИК.

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

Атрибут «Номер страхового полиса сотрудника» является уникальным, но проблема в том, что СОТРУДНИК может не иметь такового.

Комбинация атрибутов «имя сотрудника» и «дата рождения сотрудника» может оказаться удачной для наших целей и стать искомым потенциальным ключом.

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

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

Суррогатный ключ— это произвольный номер, который уникальным образом определяет запись в сущности. Атрибут «Номер сотрудника» является примером суррогатного ключа.

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

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

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

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

Источник