Oc-windows.ru

IT Новости из мира ПК
3 просмотров
Рейтинг статьи
1 звезда2 звезды3 звезды4 звезды5 звезд
Загрузка...

Er диаграмма access

Методика построения еr — диаграммы для базы данных

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

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

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

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

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

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

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

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

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

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

    1. поиск нужного товара

    — поиск товара на складе посредством побуквенного ввода названия товара, фирмы изготовителя или цене в поле поиска;

    2. формирование списка товаров

    — вывод выбранных товаров в отдельную таблицу;

    3. оформление документов клиента

    — сохранение информации в базу данных;

    4. оформление продажи

    — выбор количества продаваемого товара;

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

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

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

    Поставщики ПОСТАВЛЮТ Товары

    Товары СОСТОЯТ Типы

    Товары НАХОДЯТСЯ Магазин

    Магазин РАБОТАЮТ Сотрудники

    Сотрудники ОФОРМЛЯЮТ Заказы

    Заказы ДЕЛАЮТ Клиенты

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

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

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

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

    Создание ER-Диаграмм

    Краткая теория вопроса

    Информационная система (ИС) — программно-аппаратный комплекс, предназначенный для хранения и обработки информации о какой-либо предметной области.

    Процесс создания ИС делится на ряд этапов. Обычно выделяют следующие этапы создания ИС:

    • — формирование требований к системе (анализ),
    • — проектирование,
    • — реализация,
    • — тестирование,
    • — ввод в действие,
    • — эксплуатация и сопровождение.

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

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

    Согласно современной методологии, процесс создания ИС представляет собой процесс построения и последовательного преобразования ряда согласованных моделей на всех этапах жизненного цикла (ЖЦ) ИС. На каждом этапе ЖЦ создаются модели: организации, требований к ИС, проекта ИС, требований к приложениям и т. д.

    Проектирование ИС охватывает три основные области:

    • — проектирование объектов данных ( создание моделей данных ) , которые будут реализованы в базе данных;
    • —проектирование программ, экранных форм, отчетов, которые будут обеспечивать выполнение запросов к данным;
    • —учет конкретной среды или технологии, а именно: топологии сети, конфигурации аппаратных средств, используемой архитектуры (файл-сервер или клиент-сервер), параллельной обработки, распределенной обработки данных и т. п.

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

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

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

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

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

    Базовые понятия ERD

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

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

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

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

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

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

    Один-к-одному, многое-ко-многим, один-ко-многим.

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

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

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

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

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

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

    3) Свойства этих сущностей (будут представлены в виде имен атрибутов в этих блоках).

    Задача: разработать информационную систему «Контингент студентов института» .

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

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

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

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

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

    1. — Хранить информацию о студентах и их успеваемости.
    2. — На факультетах по определённой специальности печатать экзаменационные ведомости и другие документы.

    Выделим все существительные в этих предложениях — это предполагаемые сущности и проанализируем их:

    • — Студент — явная сущность.
    • — Успеваемость — явная сущность.
    • — ?Факультет — нужно выяснить один или несколько факультетов в институте? Если несколько, то это — предполагаемая новая сущность.
    • — ? Специальность — нужно выяснить одна или несколько специальностей на факультете? Если несколько, то это — ещё одна сущность.
    • — Предмет — предполагаемая сущность.

    На первоначальном этапе моделирования данных информационной системы явно выделены две основные сущности: Студент и Успеваемость.

    Критерием успеваемости является наличие отметки о сдачи экзаменов.

    Сразу возникает очевидная связь между сущностями — «студент сдаёт несколько экзаменов » и «экзамены сдаются каждым студентом». Явная связь Один-ко-многим . Первый вариант диаграммы выглядит так:

    Мы знаем, что студенты учатся на факультетах, на определённой специальности и сдают экзамены по дисциплинам (предметам). Анализ предметной области показал, что студенты учатся на нескольких факультетах института по нескольким специальностях и сдают экзамены по определённому перечню предметов.

    Исходя из этого, мы добавляем в ER-модель ещё несколько сущностей. В результате она будет выглядеть так:

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

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

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

    Для преобразования концептуальной модели в физическую необходимо знать, что:

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

    — Каждый атрибут становится колонкой (полем) соответствующей таблицы.

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

    — Семантическое моделирование данных основывается на технологии определения значения данных через их взаимосвязи с другими данными.

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

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

    После создания концептуальной модели данных переходим к созданию физической модели средствами конкретной СУБД, а именно СУБД ACCESS. Для этого переходим к выполнению Практического задания №2

    Приглашайте друзей на мой сайт

    Поддержите проект! Выберите один из вариантов платежа:

    С карты, с баланса сотового, из Кошелька

    Построение реляционной структуры из ER-модели

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

    Правила эти применяются к ER-модели, то есть модели «сущность-связь».

    ER-модель

    ER -модель представляет собой схему, составными элементами которой являются:

    • Сущность — это реальный, либо воображаемый объект, информацию о котором необходимо хранить в базе данных. На диаграмме ER-модели сущность изображается в виде прямоугольника, содержащего имя сущности.
    • Связь — отображаемая графически на диаграмме ассоциация между двумя (чаще всего) сущностями, или между одной и той же сущностью (рекурсивная связь). Связь изображается ромбом, на котором выделяются два конца, по одному на каждую сущность. Для каждой стороны этой связи устанавливаются:
      1. Степень связи — сколько экземпляров данной сущности связывается
      2. Обязательность связи — обязательно ли данная сущность должна участвовать в связи.

    Приведу пример:
    Пусть необходимо хранить информацию о клиентах и их заказах. Построим диаграмму


    Рис.1

    Заметим, что со стороны сущности «ЗАКАЗ» связь обозначена дополнительным прямоугольником — это обозначение того, что каждому экземпляру сущности «ЗАКАЗ» соответствует экземпляр сущности «КЛИЕНТ» (для клиента же наличие заказа не обязательно). Степень «M» означает, что для каждого экземпляра сущности «КЛИЕНТ» могут существовать несколько экземпляров сущности «ЗАКАЗ» (но не наоборот, поскольку для каждого заказа всегда только один заказчик — ставим степень «1»)

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

    Этапы проектирования

    Концептуальное проектирование

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

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

    У меня получилась следующая диаграмма.


    Рис. 2

    Логическое проектирование

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

    Переход к реляционной структуре (построение набора отношений) производится по следующим правилам:

    1. Если степень бинарной связи равна 1:1 и класс принадлежности обеих сущностей обязательный, то требуется только одно отношение. Первичным ключом этого отношения может быть ключ любой из этих двух сущностей. В этом случае гарантируется однократное появление каждого значения ключа в любом экземпляре отношения.
    2. Если степень бинарной связи равна 1:1 и класс одной из сущностей необязательный, то необходимо построение двух отношений, под каждую сущность необходимо выделение одного отношения. Ключ сущности, для которого класс принадлежности является необязательным, добавляется в качестве атрибута в отношение, выделенное для сущности с обязательным классом принадлежности.
    3. Если степень бинарной связи равна 1:1 и класс принадлежности ни одной из сущностей не является необязательным, то используется три отношения — по одному для каждой сущности — ключи которых служат в качестве первичных в соответствующих отношениях и одного для связи. Отношение, выделенное для связи, будет иметь по одному ключу сущности от каждой сущности.
    4. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности обязательный, то достаточно использовать два отношения: по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Ключ же односвязной сущности должен быть добавлен как атрибут в отношение, отводимое М-связной сущности.
    5. Если степень бинарной связи равна 1: М и класс принадлежности М-связной сущности необязателен, то необходимо использовать три отношения: по одному на сущность и одно для связи. Связь должна иметь среди своих атрибутов ключ сущности от каждой сущности.
    6. Если степень бинарной связи равна М: М, то для хранения данных необходимо три отношения: по одному на сущность и одно для связи. Ключи сущности входят в связь. Если одна из сущностей вырождена, то — два отношения (т.е. достаточно будет двух таблиц).
    7. В случае трехсторонней связи необходимо использовать четыре отношения: по одному на сущность и одно для связи. Отношение, порождаемое связью, имеет в себе среди атрибутов ключи сущности от каждой сущности.

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

    СущностиНомер правилаОтношения
    Клиент
    Заказ
    4Клиент(#Клиента
    Заказ(#Заказа, #Клиента
    Сотрудник
    Заказ
    4Сотрудник(#Сотрудника
    Заказ(#Заказа, #Сотрудника
    Заказ
    Элемент заказа
    4Заказ(#Заказа
    Элемент заказа(#Элемента заказа, #Заказа
    Бригада
    Элемент заказа
    4Бригада(#Бригады
    Элемент заказа(#Элемента, #Бригады
    Изделие
    Элемент заказа
    4Изделие(#Изделия
    Элемент заказа(#Элемента, #Изделия
    Клиент
    Заказ
    6Клиент(#Клиента
    Заказ(#Заказа
    Платеж(#Платежа, #Клиента, #Заказа
    Бригада
    Сотрудник
    5Бригада(#Бригады
    Сотрудник(#Сотрудника
    Сотрудник бригады(#Сотрудника бригады, #Сотрудника, #Бригады
    Элемент заказа
    Операция
    5Элемент заказа(#Элемента
    Операция(#Операции
    Запись операции(#Записи, #Элемента, #Операции
    Элемент заказа
    Материал
    5Элемент заказа(#Элемента
    Материал(#Материала
    Расход(#Записи, #Элемента, #Материала

    Табл. 1

    Распределив атрибуты по полученным отношениям, получим (в списке полей на первом месте — первичный ключ, остальные, помеченные «#», являются внешними ключами):

    БРИГАДА(#Бригады, #Бригадира, Расположение)
    ДОЛЖНОСТЬ(#Должности, Должность, Оклад)
    ЗАКАЗ(#Заказа, #Клиента, #Сотрудника, ДатаРазмещения, ТребуемаяДата, ДатаИсполнения, Описание)
    КЛИЕНТ(#Клиента, Название, Имя, Фамилия, ОрганизацияИлиОтдел, Адрес, НомерТелефона, АдресЭлектроннойПочты)
    ЗАПИСЬОПЕРАЦИИ(#Записи, #Элемента,#Операции, #Сотрудника, Количество)
    ОПЛАТА(#Оплаты, #Клиента, #Заказа, СуммаОплаты, ДатаОплаты, Заметки)
    РАСХОД(#Записи, #РасхМат, #Елемента, Количество)
    СОСТАВ(#Элемента, #Заказа, #Товара, #Бригады, Количество)
    СОТРБРИГАДЫ(#СотрБригады, #Бригады,#Сотрудника)
    СОТРУДНИК(#Сотрудника, НомерПаспорта, Фамилия, Имя, Отчество, #Должности, Адрес, ДомашнийТелефон, РабочийТелефон, ДатаРождения, ДатаНайма, ДатаОкончДоговора, Фотография, Заметки)
    ОПЕРАЦИЯ(#Операции, Описание, Стоимость, Время, Оборудование, Выполнение)
    МАТЕРИАЛ(#РасхМат, НаимРасхМат, Цена, Плотность, Тип, Состав)
    ТОВАР(#Товара, Марка, Название, ОписаниеТовара, Тип, СерийныйНомер, НаСкладе, Цена)

    Табл. 2

    Вот так нас учили делать в университете. Может будет кому-нибудь интересно. Насчет «нужно ли это», слушаю ваши мнения!

    Основы баз данных. ER-модель (сущность-связь)

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

    Сегодня речь пойдет о модели «сущность-связь», или entity-relationship model.

    Теория

    Модель “сущность-связь” (Entity-Relationship model или ER – модель) представляет собой высокоуровневую концептуальную модель данных, кото­рая была разработана с целью упрощения задачи проектирова­ния структур баз данных.

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

    Цель диаграмм “сущность-связь” — это создать точное и полное отображение ре­альной предметной области (ПрО), используемое в дальнейшем в ка­честве источника информации для построения базы данных автоматизированных систем обработки информации (БД АСОИ).

    Эта диаграмма или концептуальная модель ПрО должна отвечать сле­дующим тре­бованиям:

    • Обеспечивать адекватное отображение ПрО;
    • Представлять на языке, понятном, как будущим пользователям АСОИ, так и разработ­чикам БД;
    • Содержать информацию о ПрО, достаточную для дальнейшего проек­тирова­ния БД (разработка логической и физической моделей);
    • Гарантировать однозначную интерпретацию или толкование модели ПрО.

    Основные концепции этой модели — понятия сущность, атрибут и связь.

    СУЩНОСТЬ– это множество объектов реального мира с одинаковыми свой­ствами. Сущ­ность характеризуется независимым существованием и может быть объектом с фи­зическим (или реальным) существова­нием или объектом с концептуальным (или абстрактным) существо­ванием.

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

    Практика

    ПРИМЕР. Предметная область “Заказ билетов в кинотеатре”. В кинотеатре показывают фильмы, билеты на которые можно купить в день показа или забронировать их заранее. В базе данных находится информация обо всех Кинопоказах в данном кинотеатре, в том числе о старых. У каждого кинопоказа своя стоимость, т.е. билеты на один и тот же фильм, но в разное время, могут отличаться по цене. Кинопоказ состоит из Фильма, информация о котором так же хранится в БД.

    Для ПрО “Заказ билетов в кинотеатре” сущностями будут выступать следующие понятия:

    Кинопоказ

    Фильмы

    Зритель

    Билет

    Бронь

    Стоимость

    Графически сущности на диаграммах “сущность-связь” представляются в виде пря­моугольников:

    АТРИБУТ это средство, с помощью которого определяются свойства сущности или связи. Атрибут — это поименованная характеристика сущности. Наименова­ние атрибута должно быть уникальным для кон­кретной сущности, но может быть одинаковым для разных сущностей.

    Конкретный набор атрибутов для сущности определяется задачами, в ко­торых они используются. Например, сущности ПрО “Заказ билетов в кинотеатре” можно описать с помощью следующей совокупности атрибутов:

    Кинопоказ (Номер кинопоказа, Номер Фильма, Дата показа, Номер Стоимости);

    Фильм (Номер фильма, Название, Продолжительность, Краткое описание);

    Зритель (Номер зрителя, ФИО, дата рождения);

    Билет (Номер зрителя, Номер кинопоказа, Стоимость билета);

    Бронь (Номер зрителя, Номер кинопоказа, дата брони);

    Стоимость (Номер стоимости, Номер кинопоказа, стоимость).

    Графически изображение атрибутов сущности представляются в виде вы­носок, в ко­торых перечисляется список имен атрибутов. Например:

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

    СВЯЗЬ – это отношение между экземплярами двух (и более) разных сущностей. Механизм связей используется для того, чтобы опре­делить взаимоотноше­ния между сущностями в ПрО. Кроме этого, существуют отношения между атрибутами отдельной сущности (будут рассмотрены при построении логи­ческих моделей).

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

    Наименование связи должно нести в себе определенный смысл, чтобы было легче разобраться в том, как соотносятся сущности. Например, взаимо­отношение между сущ­ностями Зритель и Билет можно определить как “Покупает”.

    Для графического представления связи на диаграммах “сущность-связь” использу­ется ромб. Внутри ромба определяется имя связи, а с помощью ли­ний соединяются сущности, участвующие в данной связи.

    Показатель кардинальности связи (характеристика однозначности) обозначает степень взаимосвязи сущностей и описывает количество возможных связей для каждой из сущ­ностей-участниц:

    Читать еще:  Книги по access
Ссылка на основную публикацию
Adblock
detector