Логическая и физическая модель базы данных в чем разница
Разница между логической и физической моделью данных
Содержание:
Логическая и физическая модель данных
Что такое логическая модель данных?
Логическая модель данных подробно описывает данные и взаимосвязи на очень высоком уровне. Сюда не входит, как данные физически представлены в базе данных, а описывается на очень абстрактном уровне. Он в основном включает сущности и отношения между ними, а также атрибуты каждой сущности.
Логическая модель данных включает первичные ключи каждой сущности, а также внешние ключи. При создании логической модели данных первые сущности и их отношения идентифицируются с помощью ключей. Затем идентифицируются атрибуты каждой сущности. После этого отношения многие ко многим разрешаются и выполняется нормализация. Логическая модель данных не зависит от системы управления базами данных, так как не описывает физическую структуру реальной базы данных. При разработке логической модели данных для сущностей и атрибутов могут использоваться неформальные длинные имена.
Что такое физическая модель данных?
Физическая модель данных описывает, как данные на самом деле находятся в базе данных. Он включает описание всех таблиц и столбцов внутри них. Спецификация таблицы включает такие детали, как имя таблицы, количество столбцов, а спецификация столбца включает имя столбца и тип данных. Физическая модель данных также содержит первичные ключи каждой таблицы, а также показывает взаимосвязь между таблицами с использованием внешних ключей. Более того, физическая модель данных содержит ограничения, применяемые к данным и компонентам, таким как триггеры и хранимые процедуры.
Физическая модель данных зависит от используемой системы управления базой данных. Таким образом, физическая модель данных для MySQL будет отличаться от модели данных, нарисованной для Oracle. При создании физической модели данных из логической модели данных первые сущности преобразуются в таблицы. Затем отношения преобразуются в ограничения внешнего ключа. После этого атрибуты конвертируются в столбцы каждой таблицы.
В чем разница между логической и физической моделью данных?
• Физическая модель данных зависит от используемой системы управления базой данных. Однако логическая модель данных не зависит от используемой системы управления базами данных.
• Логическая модель данных включает сущности, атрибуты, отношения и ключи. Физическая модель данных включает таблицы, столбцы, типы данных, ограничения первичного и внешнего ключей, триггеры и хранимые процедуры.
• В логической модели данных для сущностей и атрибутов используются длинные неформальные имена. Однако в физических данных для имен таблиц и столбцов используются сокращенные формальные имена.
• Логическая модель данных сначала выводится из описания. После этого выводится только физическая модель данных.
• Логическая модель данных нормализована до четвертой нормальной формы. При необходимости физическая модель базы данных будет деформализована для соответствия требованиям.
Резюме:
Логическая и физическая модель данных
О разных данных на бытовом уровне
Мне как фриланс-архитектору часто приходится сталкиваться с людьми из бизнеса, которые не понимают что такое ИТ, как там все происходит и зачем все эти страшные слова.
А когда люди не понимают о чем говорят они закрываются и боятся принять какое-либо решение. А так как мне нужно рассказать о своих способностях и том, чем я могу быть полезен, т.е. по сути продать свои услуги, мне часто приходится искать общие понятия, так сказать common ground. Когда люди начинают строить аналогии с тем, что им понятно, происходит уже более предметное обсуждение.
Часто встречаясь с одними и теми же проблемами, в конце концов, я решил поделиться своим опытом, возможно, это кому-то будет полезно в чистом виде, а кто-то поймёт принцип и придумает примеры и объяснения получше.
В этой статье я хочу рассказать об уровнях данных – Физическом, Логическом, Концептуальном.
Физический уровень
Итак, представьте себе, что у вас есть коробка для хранения и целый набор различных крепёжных элементов – болты, гайки, саморезы, гвозди, эксцентрики и прочее (рис.1)
Рис.1 База данных и её элементы в реальной жизни
Свалив все в коробку вы уже получили базу, содержащую данные. Теперь каждый раз, когда вам нужно что-то достать, вы будете открывать коробку и доставать из неё нужный элемент крепежа. При этом вам каждый раз придётся копаться во всей коробке.
Это называется неструктурированная и ненормированная база данных. Её преимущества в простоте и дешевизне.
Однако, то, что очевидно для вас, совсем не очевидно для другого человека. Для человека незнакомого с вашей коробкой и её содержим, поиск будет настоящим мучением.
Точно та же проблема будет стоять и перед любым ИТ-специалистом.
Со временем вы захотите навести больше порядка в своей коробке – т.е. её структурировать. Выделить каждому типу элементов свой контейнер, чтобы как можно быстрее находить нужное.
Для этого вы купите дополнительные контейнеры поменьше и раскидаете в них соответствующие элементы. Болты в один контейнер, гвозди в другой, гайки в третий и так далее.
При этом вы наверняка начнёте размещать наиболее часто используемые коробочки наверх, наиболее редко используемые вниз. Элементы, которые часто используете вместе, размещать рядом и так далее.
На языке ИТ это называется нормализация. А крепёжные элементы — это объекты.
Рис.2 – Структурированная база данных
После выполнения нормализации, в каждой коробочке будет находится свой тип объекта – гайки, болты или гвозди.
Нормализацию вы можете продолжать и дальше. Например, вы можете купить коробочки поменьше и разложить саморезы по металлу, дереву и бетону в разные.
Можете дополнительно разделить их по длине, цвету или скажем ходу резьбы.
Как и в случае с коробками, фанатичная нормализация базы данных создаёт те же проблемы – большой уровень вложенности и замедление поиска нужного элемента, которого просто может не оказаться в коробке.
Потому ИТ-специалисты всегда стараются соблюдать баланс между чёткой структурой и удобством её использования.
Поэтому иногда специально прибегают к денормализации.
Например, болт и гайка почти всегда используются вместе. Если следовать прямой логике структуризации – болты нужно положить в одну коробочку, а гайки в другую.
Но с точки зрения удобства, это хуже, т.к. приходится заглядывать в две коробочки и тратить на это время. Потому, вы можете пойти на осознанную денормализацию и положить болты и гайки в одну коробочку.
Если коробочек много или скажем они не прозрачны или ещё по каким-либо причинам удобства, вы можете наклеить на каждую коробочку метку – индекс.
С помощью таких индексов скорость поиска существенно повышается, т.к. вы точно знаете где что хранится и возможно что хранится в соседних коробочках.
Таким образом, организуя хранилище крепёжных элементов, вы можно сказать, что вы управляете базой данных.
Вы можете выполнять две основные операции над коробкой – извлекать элементы и класть элементы.
Конечно, вы можете осуществлять поиск, выбирать конкретные элементы или считать их количество. Т.е. то же самое, что и с базой данных.
При этом самой коробочке все равно какие типы элементов в ней хранятся, как они будут использоваться и как удобно вам с ним обращаться. Её задача хранить элементы.
Что делать с элементами или какой в них бизнес-смысл — это задача логического уровня.
Логический уровень
Однажды в моей жизни произошла забавная ситуация, когда я работал в крупной компании с процедурами, регламентами, базами заявок и прочее.
Мне нужно было чтобы от одного стола открутили перегородку, а к другому столу ее прикрутили. Конечной целью являлась прикрученная перегородка ко второму столу, а то, что её нужно было открутить от второго стола, воспринималось все равно что взять её у стены.
Потому и заявку я оставил на прикручивание перегородки к столу. Монтажник пришёл с шуруповёртом и был очень недоволен, что заявка на прикручивание перегородки, а нужно ещё открутить. Мы тогда посмеялись и спросили, помочь ли ему переключить шуруповёрт в режим реверса. Ведь с житейской точки зрения, это глупость чистой воды, возьми открути перегородку, потрать лишние 30 секунд.
Если посмотреть на ситуацию более системно, то все дело в том, что шуруповёрт давно был продуман и подготовлен к такой ситуации. Производитель давно подумал о функции реверса и потому отказ монтажника от того, чтобы открутить перегородку кажется абсурдным.
Но ведь ситуация могла быть и совсем другой, например, если бы он пришёл с шуруповертом, у которого нет функции реверса, и он физически мог бы только закрутить болт, но не мог бы его открутить.
На рисунке 3 представлена упрощённая логическая модель из примера с заявкой.
Рис.3 Логическая модель данных
В ИТ-мире это особенно важно, ведь если перед программистом не стояло задачи реализовать реверс, то монтажник сделать ничего не сможет.
Обратите внимание, что мы говорим о тех самых объектах с физического уровня – болтах. Но операции, которые мы теперь выполняем над ними уже не достать или положить, а прикрутить или открутить. При том, что сами операции открутить или прикрутить, определяются направлением вращения отвёртки, а отнюдь не самим болтом.
Конечно, у болта есть свойство это направление резьбы, которая определяет в какую сторону нужно поворачивать отвёртку.
В ИТ-мире вы часто можете услышать слово атрибут объекта, вместо свойства.
При этом заметьте, что, если мы изменим направление резьбы, сами операции закрутить и открутить останутся, но нужно будет изменить направление вращения отвёртки.
Таким образом, когда мы говорим о логическом уровне работы с данными, мы говорим о каких-то осмысленных операциях над данными, позволяющими решать какие-то задачи.
Помимо списка операций, мы всегда думаем о ценности наличия тех или иных объектов, т. е. об их предназначении. Зачем нам эти объекты и что мы будем с ними делать?
Часто в ИТ-мире это называется бизнес-логикой или бизнес-смыслом.
Саморезу все равно, что на нем висит картина или роликовые коньки, у него есть свойство «несущая способность» и операция держать нагрузку. Но мы вкладываем в это разную ценность в одном случае мы добавляем эстетическую составляющую в комнате, в другом имеем удобную функцию хранения.
Концептуальный уровень
Уровень концепции — это уровень верхнеуровневых рассуждений без деталей.
Мы часто используем этот уровень, даже не подозревая об этом.
Концептуальный уровень позволяет нам определить основные объекты, их связи друг с другом, не впадая в детализацию (вес картины, длинна самореза и так далее).
Концептуальный уровень позволяет быстро сформировать набросок логической модели, договориться о понятиях и выровнять понимание.
В жизни мы часто очень неосторожно используем понятия, буквально жонглируем ими. Но когда дело доходит до автоматизации, часто возникают проблемы в реализации.
Один из моих любимых примеров на этот счёт является сервис Яндекс такси. Для пользование сервисом нужно создать аккаунт и согласиться с условиями соглашения (договора), т.е. стать Клиентом. При этом нужно привязать карту для оплаты, владельцем карты не обязательно должны быть вы, потому появляется понятие Плательщик. Однако, относительно недавно появилась функция – Такси другому человеку, которая явно указывает на тот факт, что пользоваться услугой может другой человек – Потребитель. (рис.4)
Рис.4 Концептуальная модель данных
Здесь я специально не использую слово пассажир, т.к. хочу сфокусировать ваше внимание на ключевых объектах и их отношениях.
Краткий итог по данным и их уровням
Физический уровень – как организовываем и храним данные.
Логический уровень – описываем и манипулируем данными.
Концептуальный – рассуждаем о данных и их связях.
Надеюсь, статья была вам полезной и занимательной.
P.S.: эта статья не для ИТ специалистов, статья рассчитана на средне статического человека, не связанного с ИТ, с максимальным упрощением. А как в любом упрощении, в статье сделаны осознанные допущения и упущены некоторые детали.
Например, объяснить что такое ключи и гипер ссылки, я не стал да и пример для этого нужен другой.
Логическая и физическая модель базы данных 2021
Логическая и физическая модель базы данных
Логическая модель базы данных
Моделирование логической базы данных требуется для компиляции бизнес-требований и представления требований в качестве модели. В основном это связано с сбором бизнес-потребностей, а не с дизайном базы данных. Информация, которая должна быть собрана, касается организационных единиц, бизнес-единиц и бизнес-процессов.
После компиляции информации создаются отчеты и диаграммы, в том числе:
Логические модели баз данных в основном определяют, собраны ли все требования бизнеса. Разработчики, менеджеры и, наконец, конечные пользователи проверяют, нужно ли собирать больше информации до начала физического моделирования.
Физическая модель базы данных Физическое моделирование базы данных касается проектирования фактической базы данных на основе требований, собранных в процессе моделирования логической базы данных. Вся собранная информация преобразуется в реляционные модели и бизнес-модели. Во время физического моделирования объекты определяются на уровне, называемом уровнем схемы. Схема рассматривается как группа объектов, связанных друг с другом в базе данных. Таблицы и столбцы производятся в соответствии с информацией, предоставленной во время логического моделирования. Первичные ключи, уникальные ключи и внешние ключи определяются для обеспечения ограничений. Определены индексы и моментальные снимки. Данные можно суммировать, и пользователям предоставляется альтернативная перспектива после создания таблиц.
Физическое моделирование базы данных зависит от программного обеспечения, которое уже используется в организации. Это программное обеспечение. Физическое моделирование включает:
Диаграмма модели сервера. Она включает таблицы и столбцы и различные отношения, которые существуют в базе данных. Документация по проектированию базы данных. Обратная связь пользователей.
1. Логическое моделирование базы данных в основном для сбора информации о потребностях бизнеса и не предполагает разработки базы данных; тогда как физическое моделирование баз данных в основном требуется для фактического проектирования базы данных. 2. Логическое моделирование базы данных не включает индексы и ограничения; логическая модель базы данных для приложения может использоваться в различных программах и реализациях баз данных; тогда как физическое моделирование базы данных является специфическим программным и аппаратным обеспечением, имеет индексы и ограничения. 3. Моделирование логической базы данных включает; ERD, диаграммы бизнес-процессов и документацию обратной связи с пользователями; тогда как физическое моделирование базы данных включает в себя; диаграмму модели сервера, документацию по дизайну базы данных и документацию обратной связи с пользователями.
1. РАЗРАБОТКА ИНФОРМАЦИОННОЙ МОДЕЛИ
Разработанная функциональная модель системы отвечает на вопросы «Что должна делать система?» и «За счет каких действий может быть достигнут требуемый результат?». Эта модель также позволяет концептуально определить наборы данных, используемых в системе.
В то же время она не отвечает на вопрос «Каким образом организованы данные в системе?». Для ответа на него необходимо построить информационную модель (запроектировать БД).
Традиционно процедуру проектирования базы данных разбивают на три этапа, каждый из которых завершается созданием соответствующей информационной модели.
Этап 1-й. Концептуальное проектирование – создание представления (схемы, модели) БД, включающего определение важнейших сущностей (таблиц) и связей между ними, но не зависящего от модели БД (иерархической, сетевой, реляционной и т. д.) и физической реализации (целевой СУБД).
Этап 2-й. Логическое проектирование – развитие концептуального представления БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).
Этап 3-й. Физическое проектирование – развитие логической модели БД с учетом выбранной целевой СУБД.
Концептуальное и логическое проектирование вместе называют также инфологическим или семантическим проектированием.
В настоящее время для проектирования БД активно используются CASE-средства, в основном ориентированные на использование ERD (Entity – Relationship Diagrams, диаграммы «сущность–связь»). С их помощью определяются важные для предметной области объекты (сущности), отношения друг с другом (связи) и их свойства (атрибуты). Следует отметить, что средства проектирования ERD в основном ориентированы на реляционные базы данных (РБД), и если существует необходимость проектирования другой системы, скажем объектно-ориентированной, то лучше избрать другие методы проектирования.
Сущность (таблица, в РБД – отношение) – реальный либо воображаемый объект, имеющий существенное значение для рассматриваемой предметной области, информация о котором подлежит хранению. Если выражаться точнее, то это не объект, а набор объектов (класс) с одинаковыми свойствами. Примеры сущностей: работник, деталь, ведомость, результаты сдачи экзамена и т. д.
Экземпляр сущности (запись, строка, в РБД – кортеж) – уникально идентифицируемый объект.
Связь – некоторая ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Примерами связей могут являться родственные отношения «отец–сын», производственные – «начальник-подчиненный» или произвольные – «иметь в собственности», «обладать свойством».
Атрибут (столбец, поле) – свойство сущности или связи.
Большинство современных CASE-средств моделирования данных, как правило, поддерживает несколько графических нотаций построения информационных моделей. В частности система ERwin фирмы Computer Associates поддерживает две нотации: IDEF1X и IE (англ. Information Engineering – информационное проектирование). Данные нотации являются взаимно-однозначными, т. е. переход от одной нотации к другой и обратно выполняется без потери качества модели. Отличие между ними заключается лишь в форме отображения элементов модели.
Перечисленный выше порядок действий называется прямое проектирование БД (Forward Engineering DB). CASE-средства позволяют выполнять также обратное проектирование БД (Reverse Engineering DB), т.е. на основании системного каталога БД или DDL-скрипта построить физическую и, далее, логическую модель данных.
Кроме режимов прямого и обратного проектирования, CASE-средства обычно поддерживают синхронизацию между моделью и системным каталогом БД, т. е. при изменении модели они могут автоматически внести все необходимые изменения в существующую БД и наоборот.
Развитые CASE-средства обладают также встроенной подсистемой поиска и исправления ошибок в модели. Особенно полезна эта функция при проектировании больших БД, содержащих десятки или сотни таблиц, а также при обратном проектировании.
Следует отметить, что современные СУБД обладают своими встроенными средствами визуального моделирования данных. Некоторые из них даже поддерживают классические нотации ERD. Недостатками такого моделирования является построение только физической модели данных и невозможность быстрого перехода на другую СУБД, если такое решение принято. Достоинством этого подхода является более полное использование потенциала СУБД, ведь разработчики СУБД лучше других знают ее особенности и возможности.
Далее рассматривается процедура прямого проектирования с использованием методологии IDEF1X. Методология IDEF1 была разработана Т. Рэмеем. В настоящее время на основе IDEF1 создана ее новая версия – методология IDEF1X, которая в 1981 г. принята ICAM в качестве федерального стандарта США.
1 Data Definition Language – язык определения данных, подмножество языка SQL.
1.2. Концептуальное проектирование с использованием методологии IDEF1X
Цель концептуального проектирования – создание концептуальной модели данных на основе представлений о предметной области каждого отдельного типа пользователей. Концептуальная модель представляет собой описание основных сущностей (таблиц) и связей между ними без учета принятой модели БД и синтаксиса целевой СУБД. Часто на такой модели отображаются только имена сущностей (таблиц) без указания их атрибутов. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания.
Ниже рассматривается последовательность шагов при концептуальном проектировании.
1. Выделение сущностей.
Первый шаг в построении концептуальной модели данных состоит в определении основных объектов (сущностей), которые могут интересовать пользователя и, следовательно, должны храниться в БД. При наличии функциональной модели IDEF0 прообразами таких объектов являются входы, управления и выходы. Еще лучше для этих целей использовать DFD. Прообразами объектов в этом случае будут накопители данных. Как было отмечено выше, накопитель данных является совокупностью таблиц (набором объектов) или непосредственно таблицей (объектом). Для более детального определения набора основных объектов необходимо также проанализировать потоки данных и весь методический материал, требуемый для решения задачи. Например, для задачи определения допускаемых скоростей основными объектами (наборами объектов) являются: нормативно-справочная информация, информация об участках дороги, задания на расчет, ведомости допускаемых скоростей и т. д. В ходе анализа и проектирования информационной модели наборы объектов должны быть детализированы. Например, составной объект «информация об участках дороги» с учетом специфики решаемой задачи требует разбиения на отдельные составляющие: участки, пути, раздельные пункты, километраж, план, верхнее строение пути и т. д.
Возможные трудности в определении объектов связаны с использованием постановщиками задачи:
· примеров и аналогий при описании объектов (например, вместо обобщающего понятия «работник» они могут упоминать его функции или занимаемую должность: «руководитель», «ответственный», «контролер», «заместитель»);
· синонимов (например, «допускаемая скорость» и «установленная скорость», «разработка» и «проект», «барьерное место» и «ограничение скорости»);
· омонимов (например, «программа» может обозначать компьютерную программу, план предстоящей работы или программу телепередач).
Далеко не всегда очевидно то, чем является определенный объект – сущностью, связью или атрибутом. Например, как следует классифицировать «семейный брак»? На практике это понятие можно вполне обоснованно отнести к любой из упомянутых категорий. Анализ является субъективным процессом, поэтому различные разработчики могут создавать разные, но вполне допустимые интерпретации одного и того же факта. Выбор варианта в значительной степени зависит от здравого смысла и опыта проектировщика.
Каждая сущность должна обладать некоторыми свойствами:
· должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;
· обладать одним или несколькими атрибутами, которые либо принадлежат сущности, либо наследуются через связь;
· обладать одним или несколькими атрибутами (первичным ключом), которые однозначно идентифицируют каждый экземпляр сущности, т. е. делают уникальной каждую строку таблицы;
· может обладать любым количеством связей с другими сущностями.
В графической нотации IDEF1X для отображения сущности используются обозначения, изображенные на рис. 7.1.
Рис. 7.1. Сущности
Сущность в методологии IDEF1X является независимой (сильной, родительской, доминантной, владельцем), если сущность не зависит от существования другой сущности (другими словами, каждый экземпляр сущности может быть однозначно идентифицирован без определения его связей с другими сущностями, или уникальность экземпляра определяется только собственными атрибутами). Сущность называется зависимой (слабой, дочерней, подчиненной), если ее существование зависит от существования других сущностей. Терминология «родительская» – «дочерняя» и «владелец» – «подчиненный» также может использоваться в отношении двух зависимых сущностей, если экземпляры одной из них (дочерней, подчиненной) могут быть однозначно определены с использованием экземпляров другой (родительской, владельца), несмотря на то, что вторая сущность в свою очередь зависит от третьей сущности.
2. Определение атрибутов.
Как правило, атрибуты указываются только для сущностей. Если у связи имеются атрибуты, то это указывает на тот факт, что связь является сущностью. Самый простой способ определения атрибутов – после идентификации сущности или связи, задать себе вопрос «Какую информацию требуется хранить о …?». Существенно помочь в определении атрибутов могут различные бумажные и электронные формы и документы, используемые в организации при решении задачи. Это могут быть формы, содержащие как исходную информацию (например, «Ведомость возвышений наружного рельса в кривых»), так и результаты обработки данных (например, «Форма № 1»).
Выявленные атрибуты могут быть следующих видов:
· простой (атомарный, неделимый) – состоит из одного компонента с независимым существованием (например, «должность работника», «зарплата», «норма непогашенного ускорения», «радиус кривой» и т. д.);
· составной (псевдоатомарный) – состоит из нескольких компонентов (например, «ФИО», «адрес», и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком. Если от системы не требуется выборки всех клиентов с фамилией Иванов или проживающих на улице Комсомольской, то составные атрибуты можно не разбивать на атомарные;
· однозначный – содержит только одно значение для одного экземпляра сущности (например, у кривой в плане может быть только одно значение радиуса, угла поворота, возвышения наружного рельса и т. д.);
· многозначный – содержит несколько значений (например, у одного отделения компании может быть несколько контактных телефонов);
· производный (вычисляемый) – значение атрибута может быть определено по значениям других атрибутов (например, «возраст» может быть определен по «дате рождения» и текущей дате, установленной на компьютере);
· ключевой – служит для уникальной идентификации экземпляра сущности (входит в состав первичного ключа);
· неключевой (описательный) – не входит в первичный ключ;
· обязательный – при вводе нового экземпляра в сущность или редактировании обязательно указывается допустимое значение атрибута, т. е. оно после редактирования не может быть неопределенным (NOT NULL).
После определения атрибутов задаются их домены (области допустимых значений), например:
· наименование участка – набор из букв русского алфавита длиной не более 60 символов;
· поворот кривой – допустимые значения «Л» (влево) и «П» (вправо);
· радиус кривой – положительное число не более 4 цифр.
Задание доменов определяет набор допустимых значений для атрибута (нескольких атрибутов), а также тип, размер и формат атрибута (атрибутов).
На основании выделенного множества атрибутов для сущности определяется набор ключей. Ключ – один или несколько атрибутов сущности, служащих для однозначной идентификации ее экземпляров или для их быстрого поиска. Выделяют следующие типы ключей:
· суперключ (superkey) – атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности. Суперключ может содержать «лишние» атрибуты, которые необязательны для уникальной идентификации экземпляра. При правильном проектировании структуры БД суперключом в каждой сущности (таблице) будет являться полный набор ее атрибутов;
· потенциальный ключ (potential key) – суперключ, который не содержит подмножества, также являющегося суперключом данной сущности, т. е. суперключ, содержащий минимально необходимый набор атрибутов, единственным образом идентифицирующих экземпляр сущности. Сущность может иметь несколько потенциальных ключей. Если ключ состоит из нескольких атрибутов, то он называется составным ключом. Среди всего множества потенциальных ключей для однозначной идентификации экземпляров выбирают один, так называемый первичный ключ, используемый в дальнейшем для установления связей с другими сущностями;
· первичный ключ (primary key) – потенциальный ключ, который выбран для уникальной идентификации экземпляров внутри сущности;
· альтернативные ключи (alternative key) – потенциальные ключи, которые не выбраны в качестве первичного ключа.
Если некий атрибут (набор атрибутов) присутствует в нескольких сущностях, то его наличие обычно отражает наличие связи между экземплярами этих сущностей. В каждой связи одна сущность выступает как родительская, а другая – в роли дочерней. Это означает, что один экземпляр родительской сущности может быть связан с несколькими экземплярами дочерней. Для поддержки этих связей обе сущности должны содержать наборы атрибутов, по которым они связаны. В родительской сущности это первичный ключ. В дочерней сущности для моделирования связи должен присутствовать набор атрибутов, соответствующий первичному ключу родительской. Однако здесь этот набор атрибутов уже является вторичным ключом. Данный набор атрибутов в дочерней сущности принято называть внешним ключом (foreign key).
Рассмотрим пример. Пусть имеется таблица, содержащая сведения о студенте, со следующими столбцами:
· номер пенсионного страхового свидетельства (НПСС);
· дата выдачи паспорта;
Для каждого экземпляра (записи) в качестве суперключа может быть выбран весь набор атрибутов. Потенциальными ключами (уникальными идентификаторами) могут быть:
· номер пенсионного страхового свидетельства;
В качестве уникального идентификатора можно было бы выбрать совокупность атрибутов «Фамилия»+«Имя»+«Отчество», если вероятность учебы в вузе двух полных тезок была бы равна нулю.
Если в сущности нет ни одной комбинации атрибутов, подходящей на роль потенциального ключа, то в сущность добавляют отдельный атрибут – суррогатный ключ (искусственный ключ, surrogate key). Как правило, тип такого атрибута выбирают символьный или числовой. В некоторых СУБД имеются встроенные средства генерации и поддержания значений суррогатных ключей (например, MS Access).Также стоит отметить, что некоторые разработчики вместо поиска потенциальных ключей и выбора из них первичного в каждую сущность добавляют искусственный атрибут, который в дальнейшем и используют в качестве первичного ключа.
Если потенциальных ключей несколько, то для выбора первичного ключа рекомендуется придерживаться следующих правил:
· количество атрибутов, входящих в ключ, должно быть минимальным (желательно, чтобы ключ был атомарным, т. е. состоял из одного атрибута);
· размер ключа в байтах должен быть как можно короче;
· тип домена ключа – числовой. При выборе символьных атрибутов в ключ часто возникают проблемы с вводом ошибочных значений (путают регистр букв; добавляют лишние пробелы; используют буквы, пишущиеся на разных языках одинаково). В числовых атрибутах вероятность ошибки при вводе значения меньше;
· вероятность изменения значений ключа была наименьшей (например, «Номер пенсионного страхового свидетельства» более постоянный параметр, чем «ИНН» или «Номер паспорта»);
· с ключом проще всего работать пользователям (например, «Номер пенсионного страхового свидетельства» – это набор из 11 цифр, а «Номер паспорта» зависит от его вида: гражданина СССР, гражданина РФ или зарубежный).
В нотации IDEF1X атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой. Предварительная идентификация атрибутов на примере двух сущностей показана на рис. 7.2.
Рис. 7.2. Сущности
У независимой сущности «Участки» в качестве первичного ключа назначен суррогатный ключ, у зависимой сущности «План» – первичный ключ составной, состоящий из пяти атрибутов.
3. Определение связей.
Наиболее характерными типами связей между сущностями являются:
· связи типа «часть–целое», определяемые обычно глаголами «состоит из», «включает» и т.п.;
· классифицирующие связи (например, «тип – подтип», «множество – элемент», «общее – частное» и т. п.);
· производственные связи (например, «начальник–подчиненный»);
· функциональные связи, определяемые обычно глаголами «производит», «влияет», «зависит от», «вычисляется по» и т. п.
Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.
Связь характеризуется следующим набором параметров:
· именем – указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;
· кратностью (кардинальность, мощность): один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (N:M, N = M или N <> M). Кратность показывает, какое количество экземпляров одной сущности определяется экземпляром другой. Например, на одном участке (описывается строкой таблицы «Участки») может быть один, два и более путей (каждый путь описывается отдельной строкой в таблице «Пути»). В данном случае связь 1:N. Другой пример: один путь проходит через несколько раздельных пунктов и через один раздельный пункт может проходить несколько путей – cвязь N:M;
· типом: идентифицирующая (атрибуты одной сущности, называемые внешним ключом, входят в состав дочерней и служат для идентификации ее экземпляров, т.е. входят в ее первичный ключ) и неидентифицирующая (внешний ключ имеется в дочерней сущности, но не входит в состав первичного ключа);
· обязательностью: обязательная (при вводе нового экземпляра в дочернюю сущность заполнение атрибутов внешнего ключа обязательно и для введенных значений должен существовать экземпляр в родительской сущности) и необязательная (заполнение атрибутов внешнего ключа в экземпляре дочерней сущности необязательно или введенным значениям не соответствует экземпляр в родительской сущности);
· степенью участия – количеством сущностей, участвующих в связи. В основном между сущностями существуют бинарные связи, т. е. ассоциации, связывающие две сущности (степень участия равна 2). Например, «Участок» состоит из «Путей». В то же время по степени участия возможны следующие типы связей:
o унарная (рекурсивная) – сущность может быть связана сама с собой. Например, в таблице «Работники» могут быть записи и по подчиненным, и по их начальникам. Тогда возможна связь «начальник» – «подчиненный», определенная на одной таблице;
o тернарная – связывает три сущности. Например, «Студент» на «Сессии» получил «Оценку по дисциплине»;
o кватернарная и т.д.
В методологии IDEF1X степень участия может быть только унарной или бинарной. Связи большей степени приводятся к бинарному виду.
Внешний вид связи на диаграммах IDEF1X указывает на ее мощность, тип и обязательность (табл. 7.1).