Главная
Веб-редактирование и типографика
3. Базы данных и знаний
Основные положения инфологического подхода к проектированию баз данных. Модель сущность-связь

Кто не делится найденным, подобен свету в дупле секвойи (древняя индейская пословица)

Версия для печати

Библиографическая запись: Основные положения инфологического подхода к проектированию баз данных. Модель сущность-связь. — Текст : электронный // Myfilology.ru – информационный филологический ресурс : [сайт]. – URL: https://myfilology.ru//165/bazy-dannyx/osnovnye-polozheniya-infologicheskogo-podxoda-k-proektirovaniyu-baz-dannyx/ (дата обращения: 25.04.2024)

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

Содержание

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

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

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

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

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

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

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

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

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

Помимо наиболее известного описания объектов и связей между ними (модель «сущность — связь») к инфологическому уровню описания предметной области можно отнести следующие компоненты:

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

Модель сущность-связь

Описание предметной области в инфологической модели обычно производится в терминах «объект» - «отношение» (ряд авторов используют термины «сущность» - «связь», англ. entity - relation, сокращенно ER).

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

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

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

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

Атрибуты могут быть:

1) простыми и составными;
2) ключевыми и неключевыми;
3) обязательными и необязательными;
4) однозначными и многозначными.

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

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

Атрибуты должны быть заданы на доменах (домен в данном случае - это множество допустимых значений атрибута). На ЕR-диаграммах, которые будут рассматриваться ниже, обычно домены не указываются. Эта информация помещается в отдельный документ, называемый словарем данных. В то же время, некоторые варианты нотации Чена допускают указания доменов на диаграммах под изображением атрибута. Связь (отношение) при инфологическом проектировании описывает имеющуюся в предметной области логическую связь между двумя или более сущностями. Объекты, которые соединяются, называются участниками связи. Число участников определяет степень связи. Так же как и в случае с сущностями выделяют тип и экземпляр связи. Связь принято именовать с помощью глагола, например, связь между сущностями «Клиент» и «Заказ» можно назвать «Размещает».

Пусть R - тип связи, Е - тип сущности. Если каждый экземпляр сущности типа Е находится, по крайней мере, в одном экземпляре связи типа R, то участие Е в R называется полным или обязательным, в противном случае - частичным или необязательным. Например, пусть рассматриваемая предметная область - это образование, в ней выделены сущности «Преподаватель» и «Курс», а между ними определена связь «Читает». Если каждый курс читается хотя бы одним преподавателем, но есть преподаватели, которые не читают ни одного курса, то участие сущности «Курс» в связи «Читает» является полным, а сущности «Преподаватель» - частичным.

Выделяются следующие типы связей:

1) один-к-одному;
2) один-ко-многим;
3) многие-ко-многим.

Приведем формальные определения для данных типов связей.

Пусть имеются две сущности (А и В), участвующие в связи R. Если каждый экземпляр А_j сущности А связан не более чем с одним экземпляром сущности В, а каждый экземпляр В_j сущности В связан не более чем с одним экземпляром сущности А, то связь B имеет тип один-к-одному. На практике данный тип связи встречается достаточно редко.

Связь A имеет тип один-ко-многим, если экземпляр А_j сущности А может быть связан с нулем, одним или несколькими экземплярами сущности В, а экземпляр B_jсущности В может быть связан не более чем с одним экземпляром сущности А. Обратным по отношению к типу один-ко-многим, является тип связи многие-к-одному.

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

Составная (ассоциированная) сущность представляет данные, которые ассоциируются со связью между двумя или более сущностями. Введение данного типа сущностей связано с тем, что связь, по своей сути, не должна обладать собственными свойствами. Но часто случается, что это не так. Например, связь между пассажиром и авиарейсом, которым он летит, описывается набором собственных параметров: номер места, класс, цена, дата приобретения билета и т. д. Чтобы представить все эти данные, можно ввести составную сущность «Билет».

Голицына О. Л., Максимов Н. В., Попов И. И. Базы данных: Учебное пособие. — М.: ФОРУМ: ИНФРА-М, 2006. — 352 с.
Карпова Т. С. Базы данных.
Нестеров С. А. Базы данных: учеб. пособие / С. А. Нестеров. - СПб.: Изд-во Политехи, ун-та, 2013. - 150 с.

02.05.2022, 1436 просмотров.