Привет студент. Построение ER диаграмм

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

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

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

Существует несколько различных нотаций (языков) изображения ER-диаграмм. Исторически первой является нотация Чена; в семействе стандартов IDEF модель «сущность-связь» реализуется нотацией IDEF1Х; используются нотации Мартина и Баркера, а также графические элементы UML.

Рис. 5.5. ER-диаграмма в нотации UML

Нотация UML. На рис. 5.5 приведен пример ER-диаграммы ПрО в нотации UML.

Унифицированный язык моделирования UML (Unified Modeling Language) представляет собой язык для определения, представления, проектирования и документирования программных систем, организационно-экономических систем, технических систем и других систем различной природы. Структуру UML составляет стандартный набор диаграмм и нотаций.

Главными в разработке UML были следующие цели:

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

Предусмотреть механизмы расширяемости базовых концепций языка;

Обеспечить независимость от конкретных языков программирования и процессов разработки.

Интегрировать лучший практический опыт.

В настоящее время UML находится в процессе стандартизации, проводимом организацией по стандартизации в области объектно-ориентированных методов и технологий (OMG - Object Management Group).

Рассмотрим правила изображения сущностей, свойств и связей в этой нотации.

Каждый тип сущности в ER-диаграммах нотации UML представляется в виде прямоугольника, содержащего имя сущности и перечень свойств сущности. В качестве имени сущности обычно используется существительное в единственном числе (например, ОТДЕЛ, ПРОЕКТ, СОТРУДНИК). Имя сущности указывается в верхней части прямоугольника с прописной буквы, имена свойств перечисляются в нижней части прямоугольника и начинаются со строчной буквы.

Слабые сущности характеризуются тем, что их нельзя однозначно идентифицировать только с помощью собственных атрибутов (в силу их зависимости от «родительских» сущностей и невозможности самостоятельного существования). На ER-диаграммах слабые сущности не имеют первичных ключей (например, сущность ПОДЧИНЕННЫЙ)

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

Таблица 5.2. Изображение типов свойств в UML

Тип свойства	Описание	Пример
Свойство первичного ключа	после имени свойства в фигурных скобках помещается идентификация первичного ключа {PK}
Многозначное	после имени свойства в квадратных скобках задаются возможные границы изменения количества значений
Производное	имя свойства начинается с наклонной черты «/»
Условное (необязательное)	после имени свойства в квадратных скобках задаются возможные границы изменения количества значений
Составное	под именем составного свойства перечисляются с отступом вправо имена простых свойств

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

1..* - один или более;

0..* - ноль или более;

1 – ровно один;

0..1 – может быть один.

Может быть задан также диапазон (например,1..10) или точное количество, отличное от 1

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

Рис. 5.6. Пример трехсторонней связи

Присутствие в задании мощности связи значения «0» объявляет связь как неполную (необязательную). Например, связь РАБОТАЕТ между сущностями ОТДЕЛ и СОТРУДНИК на рис. 5.5 должна читаться следующим образом: «Каждый сотрудник обязательно работает только в одном отделе; в отделе работает произвольное число сотрудников или не работает ни одного».

Связь может быть модифицирована указанием роли. Например, для рекурсивной связи СОСТАВ на рис. 5.5 указаны роли: «Деталь состоит из …» и «Деталь в составе …».

Связь «многие ко многим» может иметь собственные свойства, характеризующие взаимодействие сущностей (например, связи УЧАСТИЕ и РЕАЛИЗАЦИЯ ПРОЕКТА на рис. 5.5). В этом случае для изображения связи используется графический элемент, соответствующий слабой сущности. Прямоугольник сущности присоединяется к линии связи (или к ромбу в случае n -арной связи) пунктирной линией.

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

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

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

Рис. 5.7. Фрагмент ER-диаграммы в нотации Чена

Участники связи соединены со связью линиями. Двойная линия обозначает полное (обязательное) участие сущности в связи с данной стороны. Например, обязательная связь РУКОВОДСТВО со стороны сущности ПРОЕКТ (рис. 5.8) означает, что у каждого проекта должен быть руководитель. Однако не каждый сотрудник должен руководить проектом.

Тип связи указывается индексами «1» или «М» над соответствующей линией. Например, связь РУКОВОДСТВО (рис. 5.8) имеет тип «один ко многим»: один сотрудник может руководить многими проектами; связь УЧАСТИЕ (рис. 5.7) имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать многие сотрудники.

1.5 ER-моделирование

Моделирование данных – это первый шаг на пути проектирования БД, это переход от объектов реального мира к компьютерной модели БД.

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

1.5.1 Сущности

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

На уровне ER-моделирования под сущностью на самом деле подразумевается набор сущностей (entity set), а не единственная сущность. Иначе говоря, сущность в ER-моделировании соответствует таблице, а не строке в реляционной среде, отдельная строка в ER-модели называется экземпляром сущности (entity instance, entity occurrence). Сущность изображается прямоугольником, в котором записано имя сущности.

1.5.2 Атрибуты

Атрибуты описывают свойства сущности. Например, сущность STUDENT включает в себя атрибуты NSTBIL (№ студенческого билета), FIO (имя студента), KURS (курс) и т.д.

Рис. 1.24. Атрибуты сущности STUDENT в ER-модели.

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

Первичные ключи в ER-модели подчеркиваются. Если имеются несколько первичных ключей, то подчеркиваются все.

Атрибуты могут быть простые и составные. Составной атрибут – это атрибут, который может быть в дальнейшем разделен на несколько атрибутов. Например, атрибут ADRESS (адрес), может быть разделен на STREET (улица), CITY (город) и т.д.

Атрибуты могут быть однозначные и многозначные. Однозначный атрибут – это такой атрибут, который может принимать единственное значений. Например, ИНН может иметь единственное значение у каждого человека. Однозначные атрибуты не обязательно являются простыми. Например, серийный номер 78-03-06-137846 является однозначным атрибутом, но в то же время это составной атрибут, т.к. его можно разделить на регион, в котором изделие было выпущено (78), код города (03), выпускающую смену (06), номер изделия (137846).

Многозначный атрибут – это атрибут, который может принимать несколько значений. Например, человек может закончить несколько ВУЗов, иметь несколько телефонных номеров.

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

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

1.5.3. Связи

Связи (relationship) – это ассоциирование. Сущности, участвующие в связи, называются участниками (participants). В качестве названия связей может использоваться глагол или документ. Например, отделом руководит служащий, товары поступают на основании заключенного договора и т.д.

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

Мощность связи (cardinality) выражает определенное число экземпляров сущностей, связанных с одним экземпляром связанной сущности. На ER-диаграмме мощность связи не обозначается, но в прикладном программировании сведения о max и min количествах экземпляров сущности могут пригодиться. Например, группа не может начать занятия, если в ней меньше 10 студентов.

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

Если сущность может существовать вне других сущностей, то она независима от существования (existence –independent). Например, сущность «деталь» может существовать независимо от сущности «поставщик».

Если одна сущность независима от существования другой сущности, связь между ними называется слабой связью (weak relationship) или неидентифицируемой связью (non – identifying relationship). Слабые связи имеют место, если первичный ключ связанной сущности не содержит первичные компоненты порождающей сущности. Например, имеются две сущности COURSE (курс) и CLASS (группа), описанные как

COURSE (CRS-CODE , DEPT_CODE,…)

CLASS (CLASS-CODE , CRS_CODE,…)

Между этими сущностями существует слабая связь, т.к. атрибут CLASS_CODE является первичным ключом сущности CLASS, в то время как атрибут CRS_CODE сущности CLASS является внешним ключом. Первичный ключ сущности CLASS не наследует компонент первичного ключа из сущности COURSE. Слабая связь изображается на ER-диаграмме штриховой линией.

Сильная связь (strong relationship), также называемая идентифицируемой связью (identifying relationship) имеет место, если связанные сущности зависимы от существования. Сильная связь между двумя сущностями имеет место, когда первичный ключ связанной сущности содержит компонент первичного ключа порождающей сущности. Например, сущности

COURSE (CRS-CODE , DEPT_CODE,…)

CLASS (CRS_CODE , CLASS-SECTION ,…)

Имеют сильную связь, т.к. составной ключ сущности CLASS включает в себя первичный сущности COURSE. На ER-диаграмме сильные связи показываются сплошной линией.

Необходимо иметь в виду, что порядок, в котором таблицы создаются и загружаются, имеет существенное значение. Для данных, например невозможна ситуация, когда внешний ключ таблицы CLASS ссылается на еще не существующую таблицу COURSE. Проблема после последовательности создания таблиц в некоторых СУБД не возникает, пока не загружаются данные. Чтобы избежать нарушения целостности на уровне ссылки, в связи 1:М необходимо загружать сторону «1» независимо от того, является она сильной или слабой.

Участие сущности в связи может быть обязательным или необязательным. Участие сущности необязательно (optional participation), если один экземпляр сущности не требует наличия соответствующего экземпляра сущности в отдельной связи. Например, в связи на курсе (COURSE), создаются группы (CLASS) по крайней мере, на некоторых курсах могут и не создаваться группы. Т.е. экземпляр сущности (строка) в таблице COURSE не требует обязательного наличия соответствующего экземпляра сущности в таблице CLASS. Поэтому сущность CLASS рассматривается как необязательная по отношению к сущности COURSE. Необязательная связь на ER-диаграмме показывается небольшим кружком со стороны необязательной сущности. Существование необязательности указывает на то, что для необязательной сущности min значение мощности связи равно 0.

Участие сущности в связи обязательно (mandatory participation), если один экземпляр сущности обязательно требует соответствующего экземпляра сущности в отдельной связи. Если около сущности не изображен никакой дополнительный символ, то это означает, что данная сущность участвует в обязательной связи со связанной сущностью. Min мощность для обязательной сущности равна 1.

а) Сущность CLASS необязательна для сущности COURSE

б) Сущности COURE и CLASS в обязательной связи.

Рис.1.25. Изображение обязательной и необязательной связей в ER-модели.

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

Слабой сущностью (weak entity) называется сущность, которая удовлетворяет двум условиям:

условию зависимости от существования, т.е. она не может существовать без сущности, с которой она связана;

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

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

Рис. 1.26. Слабая сущность в ER-диаграммах.

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

Степень связи (relationship degree) указывает на число ассоциированных сущностей. Унарная связь (unary relationship) существует тогда, когда ассоциация поддерживается внутри единственной сущности. Бинарная связь (binary relationship) существует тогда, когда ассоциируются две сущности. Тернарная связь (ternary relationship) имеет место тогда, когда связываются три сущности. Хотя существуют и более высокие степени связи, они довольно редки и не имеют особых названий.

Если сущность имеет связи с собой, то такая связь называется рекурсивной.

Рис. 1.27. ER-представление рекурсивной связи

Иерархия обобщенных представлений (generalization hierarchy), отображает связи «предок-потомок». В контексте реляционных БД иерархия обобщенных представлений отображает связи между супертипами сущности верхнего уровня и подтипами сущности нижнего уровня. Т.е. супертип содержит совместно используемые атрибуты, в то время как подтип содержит уникальные атрибуты.

Рис. 1.28. Иерархия обобщенных представлений.

Связи наследуются, т.е. подтип сущности наследует атрибуты и связи от супертипа сущности. Например, все пилоты, механики и бухгалтера имеют табельные номера, ФИО, домашний адрес и т.д., но они могут иметь атрибуты, уникальные для их специализации. Другими словами, супертип набора сущностей обычно связан с несколькими уникальными и непересекающимися подтипами набора сущностей. Такие непересекающиеся связи обозначаются буквой ‘G’.

Супертип и подтип(ы) поддерживают связь 1:1. Например, структуру таблицы EMPLOYEE можно заменить двумя таблицами, одна из которых представляет супертип EMPLOYEE, а другая – подтип PILOT.

Некоторые супертипы содержат пересекающиеся (overlapping) подтипы. Например, какой-то сотрудник может быть преподавателем, но в то же время и администратором.

Пересекающиеся связи отображаются символами ‘Gs’.

Рис. 1.29. Иерархия обобщенных представлений с пересекающимися подтипами.

Основными понятиями метода сущность-связь являются следующие:

Сущность,

Атрибут сущности,

Ключ сущности,

Связь между сущностями,

Степень связи,

Класс принадлежности экземпляров сущности,

Диаграммы ER-экземпляров,

Диаграммы ER-типа.

Сущность представляет собой объект, информация о котором хранится в БД. Экземпляры сущности отличаются друг от друга и однозначно идентифицируются. Названиями сущностей являются, как правило, существительные, например: ПРЕПОДАВАТЕЛЬ, ДИСЦИПЛИНА, КАФЕДРА, ГРУППА.

Атрибут представляет собой свойство сущности. Это понятие аналогично понятию атрибута в отношении. Так, атрибутами сущности ПРЕПОДАВАТЕЛЬ может быть его Фамилия, Должность, Стаж (преподавательский) и т. д.

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

Связь двух или более сущностей - предполагает зависимость между атрибутами этих сущностей. Название связи обычно представляется глаголом. Примерами связей между сущностями являются следующие: ПРЕПОДАВАТЕЛЬ ВЕДЕТ ДИСЦИПЛИНУ (Иванов ВЕДЕТ «Базы данных»), ПРЕПОДАВАТЕЛЬ ПРЕПОДАЕТ-В ГРУППЕ (Иванов ПРЕПОДАЕТ-В 256 группе), ПРЕПОДАВАТЕЛЬ РАБОТАЕТ-НА КАФЕДРЕ (Иванов РАБОТАЕТ-НА 25 кафедре).

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

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

диаграммы ER-экземпляров,

диаграммы ER-muna, или ER-диаграммы.

На рис. 1 приведена диаграмма ER-экземпляров для сущностей ПРЕПОДАВАТЕЛЬ и ДИСЦИПЛИНА со связью ВЕДЕТ.

Рисунок 1 - Диаграмма ER-экземпляров

Диаграмма ER-экземпляров показывает, какую конкретно дисциплину (СУБД, ПЛ/1 и т.д.) ведет каждый из преподавателей. На рисунок 2 представлена диаграмма ER-типа, соответствующая рассмотренной диаграмме ER-экземпляров.

Рисунок 2 - Диаграмма ER-типа

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

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

Степень связи является характеристикой связи между сущностями, которая может быть типа: 1:1, 1:М, М:1, М:М.

Класс принадлежности (КП) сущности может быть: обязательным и необязательным.

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

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

Пример 1. Связи типа 1:1 и необязательный класс принадлежности.

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

Каждый преподаватель ведет не более одной дисциплины, а каждая дисциплина ведется не более чем одним преподавателем (степень связи 1:1);

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

Пример 2. Связи типа 1:1 и обязательный класс принадлежности.

На рис. 3 приведены диаграммы, у которых степень связи между сущностями 1:1, а класс принадлежности обеих сущностей обязательный.

В этом случае каждый преподаватель ведет одну дисциплину и каждая дисциплина ведется одним преподавателем.

Рисунке 3 - Диаграммы для связи 1:1 и обязательным КП обеих сущностей

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

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

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

Символы на линии связи указывают на степень связи.

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

На практике степень связи и класс принадлежности сущностей при проектировании БД определяется спецификой предметной области. Рассмотрим примеры вариантов со степенью связи 1:М или М:1.

Пример 3. Связи типа 1:М.

Каждый преподаватель может вести несколько дисциплин, но каждая дисциплина ведется одним преподавателем.

Пример 4. Связи типа М:1.

Каждый преподаватель может вести одну дисциплину, но каждую дисциплину могут вести несколько преподавателей.

Примеры с типом связи 1:М или М:1 могут иметь ряд вариантов, отличающихся классом принадлежности одной или обеих сущностей. Обозначим обязательный класс принадлежности символом «О», а необязательный - символом «Н», тогда варианты для связи типа 1:М условно можно представить как: О-О, ОН, Н-О, Н-Н. Для связи типа М:1 также имеются 4 аналогичных варианта.

Пример 5. Связи типа 1:М вариант Н-О.

Каждый преподаватель может вести несколько дисциплин или ни одной, но каждая дисциплина ведется одним преподавателем (рис. 4).

По аналогии легко составить диаграммы и для остальных вариантов.

Пример 6. Связи типа М:М.

Каждый преподаватель может вести несколько дисциплин, а каждая дисциплина может вестись несколькими преподавателями.

Как и в случае других типов связей, для связи типа М:М возможны 4 варианта, отличающиеся классом принадлежности сущностей.

Пример 7. Связи типа М:М и вариант класса принадлежности О-Н.

Допустим, что каждый преподаватель ведет не менее одной дисциплины, а дисциплина может вестись более чем одним преподавателем, есть и такие дисциплины, которые никто не ведет. Соответствующие этому случаю диаграммы приведены на рис. 5.

Рисунок 4 - Диаграммы для связи типа 1:М варианта Н-О

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

Рисунок 5 - Диаграммы для связи типа М: М и варианта О-Н

педагогические науки

• Хусаинова Гузалия Ядкаровна , кандидат наук, доцент, доцент
• Башкирский государственный университет

• ПРОЕКТИРОВАНИЕ
• БАЗЫ ДАННЫХ
• ER-ДИАГРАММА

В данной работе рассмотрено создание ER – диаграммы на примере детского магазина.

• Разработка приложения «Справочник по языку программирования Pascal» для ОС Android
• Работа с базой данных в среде Delphi на примере детского магазина
• Сравнение языков программирования на примере сортировки массива
• Формирование мотивации у школьников к занятиям физической культурой и спортом

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

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

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

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

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

• поиск нужного товара;
• формирование списка товаров;
• добавление информации о покупателях;

Информационные процессы этапов представлены в виде таблицы (Таблица 1.).

Таблица 1. Информационные процессы этапов

После изучения предметной области и анализа структуры системы были определены объекты. Список сущностей и связей представлены в таблицах 2 и 3.

Таблица 2. Перечень сущностей предметной области

Таблица 3. Перечень связей между сущностями

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

Рисунок 1. ER-диаграмма.

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

Связи между объектами модели данных реализуются теми же реквизитами - ключи связи в соответствующих таблицах. Ключом соединения всегда является уникальный ключ главной таблицы. Ключ в подчиненной таблице - это либо часть уникального ключа в нем, либо поле, которое не является частью первичного ключа. Ключ связи в подчиненной таблице называется внешним ключом. В Access можно создать схему данных, визуально представляющую логическую структуру базы данных. Определение отношений «один ко многим» в этой схеме должно соответствовать построенной модели данных. Появление схемы данных практически совпадает с графическим представлением информационно-логической модели. В таблицах 4 и 5 показаны структуры объектов "Товары" и «Сотрудники». Аналогично можно получить и другие таблицы базы данных.

Таблица 4. Структура таблицы «Товары»

Таблица 5. Структура таблицы «Сотрудники»

Используя правила перевода ER - диаграмму на логическую схему можно завершающую схему - логическую схему данных (рис. 2)

Таким образом, в данной работе подробно рассмотрено получение ER - диаграммы и логической схемы на примеры детского магазина.

Список литературы

1. Айнуров К.И. Использование информационных технологий в обучении. – Магнитогорск.: МГПУ, 2014. – 85 с.
2. Викторов С.У. Развитие информационных технологий.– Пермь: ЛНА, 2011. – 74 с.
3. Хусаинов И.Г., Рахимова Р.А. Роль интерактивных технологий на уроках информатики в развитии этического воспитания учащихся // Современные проблемы науки и образования. – 2015. – № 3. – С. 488.
4. Хусаинова Г.Я. Исследование температурных полей при стационарном течении аномальных жидкостей // Автоматизация. Современные технологии. 2016. № 7. С. 13-16.

В начале 1980-х гг. были предложены новые подходы к мифологическому проектированию БД, в большей степени ориентированные на БД реляционного типа. Среди работавших в этом направлении исследователей можно назвать Р. Баркера (Richard Barker) и авторов нотации Information Engineering (сокр. IE) Дж. Мартина (James Martin) и К. Финкелыитейна (Clive Finkelstein).

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

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

Рис. 6.2.

а – нотация Баркера; 6 – нотация Мартина (IE)

Нужно отмстить, что из-за особенностей изображения связей нотации Баркера и Мартина в литературе иногда называют "crow"s foot notation" (дословно – "нотация вороньей лапки").

На рис. 6.3 приведен фрагмент диаграммы в нотации Мартина, изображающей две сущности ("Клиент" и "Заказ") и связь между ними. Первичные ключи на рисунке выделяются символом "#". Предполагается, что:

• клиент может разместить один, несколько или ни одного заказа;
• заказ может быть размещен одним и только одним клиентом.

Рис. 6.3.

В настоящее время также широкое распространение получила нотация, определенная стандартом IDEF1X (полное название на англ. – Integration Definition for Information Modeling), речь о которой пойдет в следующем параграфе.

Задача проектирования БД для современной информационной системы корпоративного уровня может быть достаточно трудоемкой и требовать совместной работы большой группы специалистов – аналитиков, разработчиков БД, разработчиков прикладного ПО, специалистов в предметной области, для которой разрабатывается БД. Для автоматизации этого процесса широко используются CASE-средства – программные средства, поддерживающие одну или несколько технологий проектирования БД (также есть средства проектирования ПО и т.д.). В качестве примера можно назвать программные продукты ERwin Data Modeler (разработчик – компания СА Technologies), ER/Studio (разработчик – Embarcadero Technologies), PowerDesigner (разработчик – компания Sybase, в настоящее время приобретенная SAP). Отчасти подобная функциональность реализована и в популярном офисном программном продукте Microsoft Visio.

ERwin и подобные ему CASE-средства позволяют решать как задачи прямого проектирования (англ. forward-engineering), т.е. получения структуры БД на основе построенной ER-диаграммы, так и обратного проектирования (англ. reverse-engineering), когда ER-диаграмма создается на основе анализа структуры существующей БД.

Далее рассмотрена методология проектирования и нотация (правила изображения) диаграмм IDEF1X, а приводимые примеры будут иллюстрироваться с использованием программного продукта ERwin Data Modeler v. 9 в версии Community Edition. Данная версия продукта свободно распространяется, ее можно получить через веб-сайт erwin.com. Наиболее существенным ограничением версии ERwin Community Edition является небольшое количество объектов в модели – не более 25, но для учебных целей это не является критичным. Для разработки БД со сложной структурой рекомендуется использовать другие версии продукта.

Наряду с нотацией IDEF1X, ERwin поддерживает нотацию 1Е, особенности современной версии которой описаны далее.