Как сделать инфологическую модель базы данных в ворде

Обновлено: 03.07.2024

Анализ определенных выше объектов и атрибутов позволяет выделить сущности проектируемой базы данных и, приняв решение о создании реляционной базы данных, построить ее инфологическую модель на языке "Таблицы-связи" (рис. 5.2).

К стержневым сущностям можно отнести:

Код создателя

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

Так как фамилия и имена (инициалы) создателя могут быть достаточно громоздкими (М.Е. Салтыков-Щедрин, Франсуа Рене де Шатобриан, Остен Жюль Жан-Батист Ипполит и т.п.) и будут многократно встречаться в разных изданиях, то их целесообразно нумеровать и ссылаться на эти номера. Для этого вводится целочисленный атрибут "Код_создателя", который будет автоматически наращиваться на единицу при вводе в базу данных нового автора, переводчика или другого создателя.

Аналогично создаются: Код_издательства, Код_заглавия, Вид_ издания, Код_характера, Код_языка, Номер_билета, Номер_пере- плета, Код_места и Код_издания, замещающие от одного до девяти атрибутов.

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

Кроме названия языка хранится его общепринятое сокращение (англ., исп., нем., фр.), если оно существует.

Один из кодов этой сущности (например, "-1") отведен для описания обобщенного места, находящегося за стенами хранилища книг (издание выдано читателю, временно передано другой библиотеке или организации).

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

Издание (Код_издания, Код_заглавия, Вид_издания, Номер_тома, Авторский_знак, Библиотечн_шифр, Повторность, Код_издательства, Год_издания, Аннотация) [Заглавия, Вид_издания, Издательства];
Переплеты (Номер_переплета, Код_издания, Цена, Дата_приобретения)[Издания];

Стержневые сущности и обозначения связаны между собой ассоциациями:

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

Рис. 5.2. Инфологическая модель базы данных "Библиотека", построенная с помощью языка "Таблицы-связи"

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

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

1 Анализ предметной области

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

Каждая сущность, кроме hall_row содержит поле id, которое идентифицирует объект. У сущности hall_row поле id не нужно, так как в одном и том же зале кинотеатра (id_hall) не могут повторяться номера рядов (number).

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

2 Построение концептуальной модели

Выше были отображены основные сущности, но не отображены роли пользователей, хотя их тоже должна хранить система. Они показаны ниже на ER-диаграмме в нотации Чена [1].

На диаграмме выделены роли кассира и менеджера, а также основные отношения между сущностями. На диаграмме нет роли администратора, но его роль заключается в:

создании всех таблиц базы;
добавлении залов и рядов в них;
добавлении кассиров и менеджеров.

На диаграмме не отражена роль посетителя, так как:

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

На диаграмме проставлены кратности связей, например, видно, что один менеджер может добавить много (N) прокатов. В этой базе не оказалось связей типа N:M, сложных или рекурсивных связей — такие связи являются препятствиями в проектировании и решаются изменением ее структуры.

Для формирования схемы данных необходимо сначала дополнить ER-диаграмму реквизитами сущностей (уточнить ее) — результат приведен на рисунке.

В ходе анализа этой диаграммы были найдены несколько недочетов, допущенных при выделении сущностей системы:

система не должна позволять продавать несколько билетов на одно и то же место при одном показе фильма. Это значит, что вторичным ключем для Билета должен быть кортеж (id_screening, row, seat). Однако, тогда нет необходимости в id билета — на билеты не ссылается ни одна таблица, это поле может быть удалено. Изначально id был добавлен потому, что обычно на билетах в кинотеатрах печатается номер;
билет хранит поле id_hall, это было сделано для того, чтобы посетитель кинотеатра мог найти свой кинозал. Однако, билет, выдаваемый пользователю — это не тоже самое, что информация о билетах, хранимая в базе данных. Билет базы данных хранит также поле id_screening, а Показ уже ссылается на id_hall. Таким образом, в базе нет смысла хранить id_hall в таблице билетов.

Исправленная ER-диаграмма приведена ниже:

Таблица менеджеров и кассиров не объединены в таблицу Users так как вопросы разграничения прав доступа в различных СУБД решаются по-разному. Так, в MS SQL пользователи добавляются с помощью специальных запросов типа:

CREATE LOGIN Manager_Name WITH PASSWORD='Some Passwrd';

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

3 Физическое проектирование

ER-диаграмма отражает основные таблицы, связи и атрибуты, на ее основе можно построить модель БД. На ER-диаграммы нет стандарта, но есть ряд нотаций (Чена, IDEFIX, Мартина и т.п.) [2], но на модель предметной области не удалось найти ни стандарта, ни нотаций. Однако, в ходе построения такой диаграммы обязательно выделяются ключевые поля (внешние и внутренние), иногда — индексы и типы данных. Схема базы данных, приведенная на рисунке, выполнена с использованием открытого инструмента plantuml [3], при этом:

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

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

Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями . К ним можно отнести семантическую модель данных , предложенную Хаммером ( Hammer ) и Мак-Леоном ( McLeon ) в 1981 году, функциональную модель данных Шипмана ( Shipman ), также созданную в 1981 году, модель " сущность—связь ", предложенную Ченом ( Chen ) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны, но испытание временем выдержала только последняя. И в настоящий момент именно модель Чена " сущность—связь ", или " Entity Relationship ", стала фактическим стандартом при инфологическом моделировании баз данных. Общепринятым стало сокращенное название ER-модель, большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели. Кроме того, разработаны методы автоматического преобразования проекта БД из ER-модели в реляционную, при этом преобразование выполняется в даталогическую модель, соответствующую конкретной СУБД . Все CASE-системы имеют развитые средства документирования процесса разработки БД , автоматические генераторы отчетов позволяют подготовить отчет о текущем состоянии проекта БД с подробным описанием объектов БД и их отношений как в графическом виде, так и в виде готовых стандартных печатных отчетов, что существенно облегчает ведение проекта.

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

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

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

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

В основе ER-модели лежат следующие базовые понятия:

Сущность,с помощью которой моделируется класс однотипных объектов. Сущность имеет имя, уникальное в пределах моделируемой системы. Так как сущность соответствует некоторому классу однотипных объектов, то предполагается, что в системе существует множество экземпляров данной сущности. Объект, которому соответствует понятие сущности, имеет свой набор атрибутов — характеристик, определяющих свойства данного представителя класса. При этом набор атрибутов должен быть таким, чтобы можно было различать конкретные экземпляры сущности. Например, у сущности Сотрудник может быть следующий набор атрибутов: Табельный номер, Фамилия, Имя, Отчество, Дата рождения, Количество детей, Наличие родственников за границей. Набор атрибутов, однозначно идентифицирующий конкретный экземпляр сущности , называют ключевым.Для сущности Сотрудник ключевым будет атрибут Табельный номер, поскольку для всех сотрудников данного предприятия табельные номера будут различны. Экземпляром сущности Сотрудник будет описание конкретного сотрудника предприятия. Одно из общепринятых графических обозначений сущности — прямоугольник, в верхней части которого записано имя сущности, а ниже перечисляются атрибуты, причем ключевые атрибуты помечаются, например, подчеркиванием или специальным шрифтом (рис. 7.1):

Между сущностями могут быть установлены связи — бинарные ассоциации , показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь).Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности. Например, если у нас есть связь между сущностью "Студент" и сущностью "Преподаватель" и эта связь — руководство дипломными проектами, то каждый студент имеет только одного руководителя, но один и тот же преподаватель может руководить множеством студентов-дипломников. Поэтому это будет связь "один-ко-многим" (1:М), один со стороны "Преподаватель" и многие со стороны "Студент" (см. рис. 7.2).

В разных нотациях мощность связи изображается по-разному. В нашем примере мы используем нотацию CASE системы POWER DESIGNER, здесь множественность изображается путем разделения линии связи на 3. Связь имеет общее имя "Дипломное проектирование" и имеет имена ролей со стороны обеих сущностей. Со стороны студента эта роль называется "Пишет диплом под руководством", со стороны преподавателя эта связь называется "Руководит". Графическая интерпретация связи позволяет сразу прочитать смысл взаимосвязи между сущностями, она наглядна и легко интерпретируема. Связи делятся на три типа по множественности: один-к-одному (1:1), один-ко-многим (1:M), многие-ко-многим (M:M). Связь один-к-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности. Связь 1: M означает, что один экземпляр сущности , расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи. Связь "один-к-одному" (1:1) означает, что один экземпляр одной сущности связан только с одним экземпляром другой сущности, а связь "многие-ко-многим" (M:M) означает, что один экземпляр первой сущности может быть связан с несколькими экземплярами второй сущности, и наоборот, один экземпляр второй сущности может быть связан с несколькими экземплярами первой сущности. Например, если мы рассмотрим связь типа "Изучает" между сущностями "Студент" и "Дисциплина", то это связь типа "многие-ко-многим" (M:M), потому что каждый студент может изучать несколько дисциплин, но и каждая дисциплина изучается множеством студентов. Такая связь изображена на рис. 7.3.

Кроме того, в ER-модели допускается принцип категоризации сущностей. Это значит, что, как и в объектно-ориентированных языках программирования, вводится понятие подтипа сущности , то есть сущность может быть представлена в виде двух или более своих подтипов — сущностей,каждая из которых может иметь общие атрибуты и отношения и/или атрибуты и отношения, которые определяются однажды на верхнем уровне и наследуются на нижнем уровне. Все подтипы одной сущности рассматриваются как взаимоисключающие, и при разделении сущности на подтипы она должна быть представлена в виде полного набора взаимоисключающих подтипов. Если на уровне анализа не удается выявить полный перечень подтипов, то вводится специальный подтип , называемый условно ПРОЧИЕ, который в дальнейшем может быть уточнен. В реальных системах бывает достаточно ввести подтипизацию на двух-трех уровнях.

1. Чудинов И.Л., Осинова В.В. Базы данных: учебное пособие / Томский политехнический университет. – Томск: Издательство Томского политехнического университета, 2012. – 140 с.

2. Советов Б.Я. Базы данных: теория и практика: учебник для бакалавров / Б.Я. Советов, В.В. Цехановский, В.Д. Чертовский. – 2–е изд. – М.: Издательство Юрайт, 2014. – 463 с.

3. Мулеса О.Ю. Інформаційні системи та реляційні бази даних. Навчальний посібник. – Електронне видання, 2018. – 118 с.

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

В результате развития концепций БД выделены три уровня представления информации: инфологический, даталогический и физический. На каждом уровне проводится структуризация информации таким образом, чтобы на третьем уровне информация могла быть представлена в виде структур данных, реализуемых в памяти ЭВМ. На инфологическом уровне определяется какая информация о предметной области будет хранится и обрабатываться в компьютере, а в результате исследования предметной области строится ее инфологическая модель, которая описывается в терминах классов объектов и их взаимодействий. В инфологической модели информация представляется вне зависимости от того, что представляют собой данные и какие технические средства будут использовании в дальнейшем для ее хранения и обработки. Даталогическая и физическая модели непосредственно реализуются в системах управления БД (СУБД), а физическая модель в свою очередь определяет структуру хранения данных на физических носителях. Цель инфологического проектирования заключается в представлении семантики (смысла) предметной области. Для описания предметной области наиболее часто используется модель “сущность–связь”, которую сокращенно называют ER–моделью от английского названия “Entity – Relationship” (“Сущность – связь”). ER–диаграмма модели имеет лексикографическую структуру и включает в себя текст и элементы графики. На практике инфологическая (семантическая) модель используется на первой стадии проектирования БД. При этом в терминах ER–модели описывается концептуальная (понятийная) схема БД, которая затем преобразуется к реляционной или другой схеме. ER–модели получили распространение в CASE–системах, поддерживающих проектирование реляционных БД [1–3]. Следует отметить, что при подготовке учителей и студентов инженерных специальностей высших учебных заведений следует выделять ключевые понятия теории БД и применять их при проектировании БД [4].

В данной работе мы предлагаем рассмотрение построения инфологической (семантической) модели данных и построения ER–диаграммы при проектировании базы данных “Кафедра”.

Процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели. При этом можно выделить следующие этапы проектирования [4]:

Системный анализ и словесное описание информационных объектов предметной области;
Проектирование инфологической модели предметной области – частично формализованное описание объектов предметной области в терминах некоторой семантической модели, например, в терминах ER–модели;
Даталогическое или логическое проектирование БД;
Физическое проектирование БД.

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

ER–модель опирается на понятия сущность, атрибут, связь и предметная область должна быть представлена как совокупность сущностей с атрибутами, между которыми установлены связи. С объектами ER–модели связаны понятия: тип – набор однородных предметов, явлений, которые выступают как единое целое; экземпляр – конкретный элемент набора, который (набор) означает некоторый тип; множество – конкретный набор экземпляров типа. Сущность – это объект, который может быть идентифицирован некоторым способом, который отличает его от других объектов. Тип сущности означает набор однородных сущностей некоторого типа. Набор сущностей – множество сущностей одного типа. Сущность фактически является множеством атрибутов, которые описывают свойства всех членов данного набора сущности. Тип сущности означает множество однородных объектов, а “экземпляр сущности” – конкретный объект из множества объектов. Например, сущностью является Студент, который представляет собой всех студентов вуза, а один из них, Петров Петр Петрович является не сущностью, а конкретной реализацией этой сущности (экземпляром). Атрибутами сущности Студент являются: ФИО, номер группы, номер зачетной книжки, дата зачисления и др. [2–3].

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

Каждая сущность должна иметь уникальный идентификатор (ключ), то есть должна быть уникально определена: каждый экземпляр сущности должен иметь ямное и недвусмысленное определение, позволяющее отличать его от других экземпляров той же сущности. Ключом может быть атрибут, комбинация атрибутов, комбинация связей или атрибутов и связей. Например, ключом для сущности Студент является атрибут № зачетной книжки [2–3].

На сегодняшний день существуют несколько нотаций для представления ER–диаграмм [1]:

Рис. 1. Пример ER–диаграммы в нотации Чена.

Рис. 2. Пример ER–диаграммы в нотации Мартина.

Рис. 3. Пример ER–диаграммы в нотации Баркера.

4. Нотация IDEFIX: сущность изображается прямоугольником, атрибут – овалом, соединенным со своей сущностью, а связь – ромбом, соединенным со связываемыми сущностями. Имена сущности, атрибута и связи располагаются внутри их изображений (Рис. 4.).

Рис. 4. Пример ER–диаграммы в нотации IDEFIX.

5. Нотация Бахмана: сущность изображается таблицей из одного столбца, столбцы которой являются атрибутами сущности (идентифицирующий атрибут выделен жирным шрифтом), а связь – стрелкой, соединяющей таблицы, направление которой указано на стороне М (Рис. 5).

Рис. 5. Пример ER–диаграммы в нотации Бахмана.

Выводы. В данной работе рассмотрено проектирование и построение инфологической модели данных. Приведены примеры построения ER–диаграмм в нотациях Чена, Мартина, Баркера, IDEFIX и Бахмана.

Читайте также: