СЕМАНТИЧЕСКАЯ МОДЕЛЬ СУЩНОСТЬ-СВЯЗЬ ОТОБРАЖЕНИЕ

ВВЕДЕНИЕ

 Модель сущность-связь (ER-модель) —  модель данных, позволяющая описывать концептуальные схемы предметной области.

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

ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER-диаграмма)(англ. entity-relationship diagram, ERD).

В данной курсовой работе были рассмотрено следующее: понятие ER-модели баз дынных, графическое представление, связь ER-модели и реляционной базы данных, реализация ER-модели на примере БД.[3]

Проблема

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

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

Актуальность

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

Цель работы: детальное рассмотрение понятия «ER-модели».

Задачи:

1.    Рассмотрение концепции ER-модели

2.    Графическое представление

3.    Связь ER-модели и реляционной базы данных.

4.    Реализация ER-модели на примере БД ««Учет материальных ценностей»

1      ER-модель базы данных

1.1 История появления ER-модели базы данных

Питер Чен Пин-Шен (англ. Peter Pin-Shan Chen) — американский ученый в области информатики, предложивший в 1976 году ER-модель данных (модель сущность-связь).

Питер Чен Пин-Шен родился в Тайчжуне (Тайвань), получил степень бакалавра в области электротехники в 1968 году в Национальном университете Тайваня и степень Ph.D в области компьютерных наук/прикладной математики в Гарвардском университете в 1973 году. С 1974 по 1978 годы работал в Массачусетском технологическом институте, в 1978—1984 — профессор Калифорниийского университета в Лос-Анджелесе. С 1983 года — профессор компьютерных наук в Университете штата Луизиана.[2]

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

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

Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.). ER-модель представляет собой формальную конструкцию, которая сама по себе не предписывает никаких графических средств её визуализации. В качестве стандартной графической нотации, с помощью которой можно визуализировать ER-модель, была предложена диаграмма сущность-связь (ER- диаграмма) (entity-relationship diagram, ERD).

Работы Чена являются основой в разработке программного обеспечения, в частности, в области CASE — средств. Модель ER повлияла на разработку большинства основных CASE-инструментов, включая ERWIN компании Computer Associates, Designer/2000 корпорации Oracle, PowerDesigner компании Sybase и даже Microsoft Visio, а также стандарт IDEF1X. В конце 1980-х и начале 1990-х на основе ER-модели данных были разработаны такие программные продукты, как репозиторий DB2 и AD/Cycle компании IBM. На ER-модели данных основаны и системы репозиториев других вендоров, например CDD+.

Концепция гипертекста, которая делает World Wide Web чрезвычайно популярным, очень похожа по своей сути на ER-модель. ER-модель также лежит в основе некоторых работ по объектно-ориентированному анализу, методологий проектирования и семантического веба. Язык моделирования UML также имеет корни в ER-модели.[1]

1.2              Основные понятия ER-диаграмм

Элементы модели "сущность-связь"

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

Семантическое моделирование представляет собой моделирование структуры данных, опираясь на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм сущность-связь (ER - Entity-Relationship).

Основные понятия ER-диаграмм

Сущность - это класс однотипных объектов, информация о которых должна быть учтена в модели.[4]

Каждая сущность должна иметь наименование, выраженное существительным в единственном числе.

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

Каждая сущность в модели изображается в виде прямоугольника с наименованием:

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

Например, представителем сущности "Материальные ценности" может быть "Материальная ценность Компьютер".

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

Атрибут сущности - это именованная характеристика, являющаяся некоторым свойством сущности.

Наименование атрибута должно быть выражено существительным в

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

Примерами атрибутов сущности "Материальные ценности" могут быть такие атрибуты как "Индифицирующий номер", "Инвентарный номер", "Цена", "Количество", "Дата поступления", "Дата списания" и т.п.

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

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

Сущность может иметь несколько различных ключей.

Ключевые атрибуты изображаются на диаграмме подчеркиванием:

Связь - это некоторая ассоциация между двумя сущностями. Одна сущность может быть связана с другой сущностью или сама с собою.

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

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

Графически связь изображается линией, соединяющей две сущности.

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

Каждая связь может иметь один из следующих типов связи:

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

- Связь типа один-ко-многим означает, что один экземпляр первой сущности (левой) связан с несколькими экземплярами второй сущности (правой). Это наиболее часто используемый тип связи. Левая сущность (со стороны "один") называется родительской, правая (со стороны "много") - дочерней.

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

Каждая связь может иметь одну из двух модальностей связи:

- Модальность "может" означает, что экземпляр одной сущности может быть связан с одним или несколькими экземплярами другой сущности, а может быть и не связан ни с одним экземпляром.[5]

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

1.3               Концепции ER-модели

Концепции ER-модели

В ER-модели выделены следующие три концепции:

1) Объекты (типы сущностей):

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

существованием (например, «материальная ценность «материально-ответственное лицо»), так и объектом с абстрактным (концептуальным) существованием (например, «единица измерения»). Разные разработчики могут выделять разные типы объектов. Каждый тип объекта идентифицируется именем и списком свойств. Объект (экземпляр типа объекта или сущность) – экземпляр типа сущности, «предмет, который может быть четко идентифицирован» на основе свойств (т.к. обладает уникальным набором свойств среди объектов одного типа). Типы объектов классифицируются как сильные и слабые:

- слабый тип объекта (дочерний, зависимый или подчиненный) – тип объекта, существование которого зависит от какого-то другого типа объекта;

- сильный тип объекта (родительский, владелец или доминантный) – тип объекта, существование которого не зависит от какого-то другого типа объекта. Представление объектов на диаграмме: сильный тип объекта – прямоугольник, с именем внутри него; слабый тип объекта – прямоугольник с двойным контуром (деление объектов на сильные и слабые – по желанию проектировщика). [6]

2) Свойства (атрибуты):

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

- Простое свойство состоит из одного компонента с независимым существованием (такое свойство – атомарное (не может быть разделено на более мелкие компоненты);

- Составное свойство – состоит из нескольких компонентов, каждый из которых характеризуется независимым существованием  (могут быть разделены на более мелкие части (например, «ФИО»), но решение о представлении такого атрибута (как простой или составной) зависит от проектировщика);

- Однозначные и многозначные: однозначное свойство – свойство, которое может содержать только одно значение для одного объекта; многозначное свойство – может содержать несколько значений для одного объекта;

- Производные и базовые: производное свойство - представляет значение, производное от значения связанного с ним свойства или некоторого множества свойств, принадлежащих некоторому типу объектов (не обязательно одному), например, «сумма деталей», «возраст сотрудника»; базовое – не зависит от других свойств.

- Ключевое и неключевое: ключ – свойство (набор свойств), которое однозначно определяет объект из всех объектов данного типа (например, «номер паспорта»); ключи делят на: потенциальные – содержит значения, которые позволяют уникально идентифицировать каждый отдельный экземпляр типа объекта (тип объекта может иметь несколько потенциальных ключей); первичные – один из потенциальных ключей для типа объекта, который выбран для идентификации объектов (должен гарантировать уникальность значений не только в текущий период, но и в обозримом будущем, лучше чтобы он содержал меньшее число свойств (например, «номер материальной ценности», «инвентарный номер»)); альтернативные – все потенциальные ключи, кроме первичного; составной ключ – потенциальный ключ, который состоит из 2-х и более свойств (позволяет определить уникальность объекта, не вводя лишних уникальных свойств). Представление свойств на диаграмме: в виде эллипсов с именем внутри него, присоединенных линией к типу объекта; для производных свойств – эллипс окружен пунктирным контуром, для многозначных – двойным; имя свойства, которое является первичным ключом – подчеркивается.[6]

3) Отношения (типы связей):

Типы отношений (типы связи) – осмысленная ассоциация (связь) между типами объектов, каждое отношение имеет имя, описывающее его

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

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

Представление отношений на диаграмме: в виде ромба (при связи слабого типа объекта с сильным, ромб отношения имеет двойной контур) с указанным в нем именем связи и соединенного линиями с участниками отношения.[6]

1.4             Переход к реляционной модели данных

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

категориям ER-модели, то ее можно легко «читать», следовательно, она доступна для анализа программистам-разработчикам, которые будут разрабатывать отдельные приложения. Она имеет однозначную интерпретацию, в отличие от некоторых предложений естественного языка, и поэтому здесь не может быть никакого недопонимания со стороны разработчиков.[10]

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

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

Рассмотрим правила преобразования ER-модели в реляционную.[6]

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

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

3.                Первичный ключ сущности становится PRIMARY KEY соответствующего отношения. Атрибуты, входящие в первичный ключ отношения, автоматически получают свойство обязательности (NOT NULL).

4.                В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности. В отношении, соответствующем подчиненной сущности, этот набор атрибутов становится внешним ключом (FOREING KEY).[8]

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

6.                Для отражения категоризации сущностей при переходе к реляционной модели возможны несколько вариантов представления. Возможно создать только одно отношение для всех подтипов одного супертипа. В него включают все атрибуты всех подтипов. Однако тогда для ряда экземпляров ряд атрибутов не будет иметь смысла. И даже если они будут иметь неопределенные значения, то потребуются дополнительные правила различения одних подтипов от других. Достоинством такого представления является то, что создается всего одно отношение.[8]

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

8.                Дополнительно при описании отношения между типом и подтипами необходимо указать тип дискриминатора. Дискриминатор может быть взаимоисключающим (М/Е, mutually exclusive ) или нет. Если установлен данный тип дискриминатора, то это значит, что один экземпляр сущности супертипа связан только с одним экземпляром сущности подтипа и для каждого экземпляра сущности супертипа существует потомок. Кроме того, необходимо указать для второго способа, наследуется ли только идентификатор супертипа в подтипы или наследуются все атрибуты супертипа.

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

Теория нормализации, которую мы рассматривали ранее применительно к реляционной модели, применима и к модели «сущность—связь». Поэтому нормализацию можно проводить и на уровне инфологической (семантической) модели и смысл ее аналогичен нормализации реляционной модели.[8]

2 ПРАКТИЧЕСКАЯ ЧАСТЬ

2. Разработка БД

2.1.1. Исследование предметной области

2.1.1.1 Цель создания БД

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

2.1.1.2         Описание объектов предметной области

Объект «Материальная ценность»

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

Идентифицирующий номер;

Название;

Инвентарный номер;

Единица измерения;

Материально-ответственное лицо;

Цена;

Количество;

Дату поступления;

Место хранения;

Дату списания;

Акт списания;

Объект «Единица измерения»

Каждая материальная ценность имеет единицу измерения, которая следующие сведения:

Идентифицирующий номер;

Название.

Объект «Материально-ответственное лицо»

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

Идентифицирующий номер;

Название (ФИО, отдел).

Объект «Место»

Поступившая материальная ценность имеет место хранение, которое имеет следующие сведения:

Идентифицирующий номер;

Название (номер кабинета, лаборатории).

Объект «Списание»

Каждая материальная ценность через определенное время списывается. Списание объекта содержит следующие данные:

Идентифицирующий номер материальной ценности;

Название (причина).

Объект «Кому списано»

Каждая материальная ценность через определенное время списывается по определенным причинам. Списание объекта содержит следующие данные:

Идентифицирующий номер материальной ценности;

Название (ФИО/отдел).

2.1.1.3. Предусмотреть следующие ограничения на информацию в системе

Одна и та же материальная ценность не должна записываться два раза.

Если материальная ценность списывается, то нужно указать списание.

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

2.1.1.4. С данной информационной системой должны работать следующие группы пользователей

Администратор.

При работе с базой администратор должен  иметь возможность решать следующие задачи:

Поступление материальных ценностей и регистрирование их в базе.

Регистрировать новое поступление, с занесением данных в базу.

Производить обновление базы данных в определенный срок.

Описание входных документов, которые служат источником данных для БД:

Ведомость о поступлении материальных ценностей

2.1.2. Анализ данных (сущностей и их атрибутов)

Объект «Материальная ценность»

Идентифицирующий номер;                          INTEGER, NOT NULL, PK;

Название;                                                         VARCHAR(30), NOT NULL;

Инвентарный номер;                                       INTEGER, NOT NULL;

Единицу измерения;                                        INTEGER, NOT NULL;

Материально-ответственное лицо;                INTEGER, NOT NULL;

Цену;                                                                  INTEGER, NOT NULL;

Количество;                                                       INTEGER, NOT NULL;

Дату поступления;                                            DATE, NOT NULL;

Место хранения;                                               INTEGER, NOT NULL;

Дату списания;                                                  DATE, NOT NULL;

Акт списания;                                                    INTEGER, NOT NULL;

Объект «Единица измерения»

Идентифицирующий номер;                         INTEGER, NOT NULL, PK;

Название.                                                         VARCHAR(10), NOT NULL;

Объект «Материально-ответственное лицо»

Идентифицирующий номер мастера;        INTEGER, NOT NULL, PK;

Название(ФИО)                                              VARCHAR(30), NOT NULL; 

Объект «Место»

Идентифицирующий номер услуги;          INTEGER, NOT NULL, FK;

Название(Кабинет)                                         VARCHAR(30), NOT NULL;

Объект «Списание»

Идентифицирующий номер;                          INTEGER, NOT NULL, PK;

Название(причина).                                        VARCHAR(30), NOT NULL;

Объект «Кому списано»

Идентифицирующий номер услуги;            INTEGER, NOT NULL, FK;

Название(ФИО/отдел)                                    VARCHAR(15), NOT NULL;

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

2.2 Создание логической схемы БД в DBDesigner4

2.3. Создание БД в SQL Manager Lite for MySQL путем синхронизации таблиц из DBDesigner4

ЗАКЛЮЧЕНИЕ

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1.                Голицына О. Л., И. И. Попов, Н. В. Максимов, Т. Л. Партыка, Информационные технологии, М, Издательство Инфра-М, 2009 г., 608 стр.

2.                Научная статья на тему: «СЕМАНТИЧЕСКАЯ МОДЕЛЬ «СУЩНОСТЬ-СВЯЗЬ ОТОБРАЖЕНИЕ» Бабанов Алексей Михайлович;

3.                Информатика и программирование А.М.Бабанов, А.С.Скачкова «Графическая нотация нотация для модели «Сущность-связь»»;

4.                Мальцев М.Г., Хоменко А.Д., Цыганов В.М. Базы данных: учебник для высших учебных заведений, Корона-Принт 2009;