Нотации er диаграмм. Er-диаграммы

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

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

• ПРОЕКТИРОВАНИЕ
• БАЗЫ ДАННЫХ
• 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.

What is ER Modeling?

Entity Relationship Modeling (ER Modeling) is a graphical approach to database design. It uses Entity/Relationship to represent real world objects.

An Entity is a thing or object in real world that is distinguishable from surrounding environment. For example each employee of an organization is a separate entity. Following are some of major characteristics of entities.

• An entity has a set of properties.
• Entity properties can have values.

In this tutorial, you will learn-

Let"s consider our first example again. An employee of an organization is an entity. If "Peter" is a programmer (an employee ) at Microsoft, he can have attributes ( properties) like name, age, weight, height, etc. It is obvious that those do hold values relevant to him.

Each attribute can have Values . In most cases single attribute have one value. But it is possible for attributes have multiple values also. For example Peter"s age has a single value. But his "phone numbers" property can have multiple values.

Entities can have relationships with each other. Let"s consider a simplest example. Assume that each Microsoft Programmer is given a Computer. It is clear that that Peter"s Computer is also an entity. Peter is using that computer and the same computer is used by Peter. In other words there is a mutual relationship among Peter and his computer.

In Entity Relationship Modeling, we model entities, their attributes and relationships among entities.

Enhanced Entity Relationship (EER) Model

Enhanced Entity Relationship (EER) Model is a high level data model which provides extensions to original Entity Relationship (ER) model. EER Models supports more details design. EER Modeling emerged as a solution for modeling highly complex databases.

EER uses UML notation. UML is the acronym for Unified Modeling Language; it is a general purpose modeling language used when designing object oriented systems. Entities are represented as class diagrams. Relationships are represented as associations between entities. The diagram shown below illustrates an ER diagram using the UML notation.

Why use ER Model?

Now you may think why use ER modeling when we can simply create the database and all of its objects without ER modeling? One of the challenges faced when designing database is the fact that designers, developers and end-users tend to view data and its usage differently. If this situation is left unchecked, we can end up producing a database system that does not meet the requirements of the users.

Communication tools understood by all stakeholders(technical as well non-technical users) are critical in producing database systems that meet the requirements of the users. ER models are examples of such tools.

ER diagrams also increase user productivity as they can be easily translated into relational tables.

Case Study: ER diagram for "MyFlix" Video Library

Let"s now work with the MyFlix Video Library database system to help understand the concept of ER diagrams. We will using this database for all hand-on in the remainder of this tutorials

MyFlix is a business entity that rents out movies to its members. MyFlix has been storing its records manually. The management now wants to move to a DBMS

Let"s look at the steps to develop EER diagram for this database-

1. Identify the entities and determine the relationships that exist among them.
2. Each entity, attribute and relationship, should have appropriate names that can be easily understood by the non-technical people as well.
3. Relationships should not be connected directly to eachother. Relationships should connect entities.
4. Each attribute in a given entity should have a unique name.

Entities in the "MyFlix" library

The entities to be included in our ER diagram are;

• Members - this entity will hold member information.
• Movies - this entity will hold information regarding movies
• Categories - this entity will hold information that places movies into different categories such as "Drama", "Action", and "Epic" etc.
• Movie Rentals - this entity will hold information that about movies rented out to members.
• Payments - this entity will hold information about the payments made by members.

Defining the relationships among entities

Members and movies

The following holds true regarding the interactions between the two entities.

• A member can rent a more than movie in a given period.
• A movie can be rented by more than one member in a given period.

From the above scenario, we can see that the nature of the relationship is many-to-many. Relational databases do not support many-to-many relationships. We need to introduce a junction entity . This is the role that the MovieRentals entity plays. It has a one-to-many relationship with the members table and another one-to-many relationship with movies table.

Movies and categories entities

The following holds true about movies and categories.

• A movie can only belong to one category but a category can have more than one movie.

We can deduce from this that the nature of the relation between categories and movies table is one-to-many.

Members and payments entities

The following holds true about members and payments

• A member can only have one account but can make a number of payments.

We can deduce from this that the nature of the relationship between members and payments entities is one-to-many.

Now lets create EER model using MySQL Workbench

In the MySQL workbench , Click - "+" Button

Double click on Add Diagram button to open the workspace for ER diagrams.

Following window appears

Let"s look at the two objects that we will work with.

The members" entity will have the following attributes

• Membership number
• Full names
• Gender
• Date of birth
• Physical address
• Postal address

Let"s now create the members table

1.Drag the table object from the tools panel

2.Drop it in the workspace area. An entity named table 1 appears

3.Double click on it. The properties window shown below appears

1. Change table 1 to Members
2. Edit the default idtable1 to membership_number
3. Click on the next line to add the next field
4. Do the same for all the attributes identified in members" entity.

Your properties window should now look like this.

Repeat the above steps for all the identified entities.

Your diagram workspace should now look like the one shown below.

Lets create relationship between Members and Movie Rentals

1. Select the place relationship using existing columns too
2. Click on membership_number in the Members table
3. Click on reference_number in the MovieRentals table

Repeat above steps for other relationships. Your ER diagram should now look like this -

Summary

• ER Diagrams play a very important role in the database designing process. They serve as a non-technical communication tool for technical and non-technical people.
• Entities represent real world things; they can be conceptual as a sales order or physical such as a customer.
• All entities must be given unique names.
• ER models also allow the database designers to identify and define the relations that exist among entities.

The entire ER Model is attached below. You can simple import it in MySQL Workbench

Но если требуется одновременно использовать термины ER-модели и реляционной модели данных, то, безусловно, требуется применять для терминов relation и relationship разные русские эквиваленты. За этими терминами стоят весьма различные понятия. В реляционной модели отношение ( relation ) – это единственная родовая структура данных . С помощью этого же механизма представляются "связанные" сущности (вспомните, например, про внешние ключи). Как мы увидим немного позже, в ER-модели для представления схемы базы данных используются два равноправных понятия – сущность и связь . Связи в ER-модели играют роль, отличную от той, какую играют отношения в реляционной модели данных.

Кроме того, в русскоязычную терминологию вошла и чистая транслитерация термина relation именно в смысле отношение . Мы говорим, например, про реляционную модель данных , реляционную алгебру и т. д., понимая модель данных , основанную на отношениях, алгебру отношений и т. п. По этому поводу, по крайней мере, в контексте баз данных, разумно окончательно зарезервировать термины relation и отношение для обозначения понятий реляционной модели данных, а для термина relationship использовать другой допустимый русскоязычный эквивалент – связь .

На использовании разных вариантов ER-модели основано большинство современных подходов к проектированию баз данных (главным образом, реляционных). Модель была предложена Питером Ченом (Peter Chen) в 1976 г. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Простота и наглядность представления концептуальных схем баз данных в ER-модели привели к ее широкому распространению в CASE-системах , поддерживающих автоматизированное проектирование реляционных баз данных . Среди множества разновидностей ER-моделей одна из наиболее популярных и развитых применялась в системе CASE компании Oracle . Мы обсудим некоторый упрощенный вариант этой модели. Если говорить более точно, сосредоточимся на ее структурной и целостной частях.

Основные понятия ER-модели

Основными понятиями ER-модели являются сущность , связь и атрибут . Сущность – это реальный или представляемый объект, информация о котором должна сохраняться и быть доступной. 4Понятно, что это "определение" на самом деле является тавтологией , поскольку, во-первых, мы пытаемся определить термин сущность через не определенный термин объект, а во-вторых, попытки определения термина объект настолько же безнадежны. Обычно авторы пытаются оправдываться тем, что в подобном контексте они имеют в виду "житейское", а не сколько-нибудь формализованное понятие объекта. Конечно, от этого не становится легче, поскольку понятие сущности должно пониматься в достаточно точном смысле. Но эта тавтология не изобретена автором этого курса; она традиционна для области семантического моделирования. В этой области стремятся максимально избегать формальностей. В диаграммах ER-модели сущность представляется в виде прямоугольника, содержащего имя сущности . При этом имя сущности – это имя типа , а не некоторого конкретного экземпляра этого типа . 5Хотя было бы правильнее всегда использовать термины тип сущности и экземпляр типа сущности , для избежания многословности (и следуя традиции) в тех случаях, где это не приводит к двусмысленности, мы будем использовать термин сущность в значении типа сущности . Для большей выразительности и лучшего понимания имя сущности может сопровождаться примерами конкретных экземпляров этого типа.

Рис. 9.1.

На рис. 9.1 изображена сущность АЭРОПОРТ с примерными экземплярами "Шереметьево" и "Хитроу". Эта примитивная диаграмма тем не менее несет важную информацию. Во-первых, она показывает, что в базе данных будут содержаться однотипные структуры данных (экземпляры сущности ), описывающие аэропорты. Во-вторых, поскольку в жизни существует несколько точек зрения на аэропорты (например, точка зрения пилота, точка зрения пассажира, точка зрения администратора) и этим точкам зрения соответствуют разные структуры данных, то приведенные примеры аэропортов позволяют несколько сузить допустимый набор точек зрения. В нашем случае приведены примеры международных аэропортов, так что, скорее всего, имеется точка зрения пассажира или пилота международных авиарейсов.

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

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

Связь представляется в виде ненаправленной линии, соединяющей две сущности или ведущей от сущности к ней же самой. При этом в месте "стыковки" связи с сущностью используются:

• трехточечный вход в прямоугольник сущности , если для этой сущности в связи могут (или должны) использоваться много (many ) экземпляров сущности ;
• одноточечный вход, если в связи может (или должен) участвовать только один экземпляр сущности .

Обязательный конец связи изображается сплошной линией, а необязательный – прерывистой линией.

Связь между сущностями БИЛЕТ и ПАССАЖИР , показанная на рис. 9.2 , связывает билеты и пассажиров. Конец связи с именем "для" позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец связи с именем "имеет" показывает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.

• каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА ;
• каждый ПАССАЖИР может иметь один или более БИЛЕТОВ или не иметь вовсе.

На следующем примере (рис. 9.3) изображена рекурсивная связь , связывающая сущность МУЖЧИНА с ней же самой. Конец связи с именем " сын " определяет тот факт, что несколько людей могут быть сыновьями одного отца. Конец связи с именем " отец " означает, что не у каждого мужчины должны быть сыновья.

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

• каждый МУЖЧИНА является сыном одного и только одного МУЖЧИНЫ ;
• каждый МУЖЧИНА может являться отцом одного или более МУЖЧИН .

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

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

5.1. Описание информационного представления предметной области. ER-диаграмма

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

Чаще всего концептуальная модель представляется в виде диаграммы сущностей – связей ( entity – relationship ) или ER-диаграммы . Процесс построения ER-диаграммы называется ER-моделированием .

Введем основные понятия, с помощью которых описывается предметная область.

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

Если в системе обрабатывается информация о факультетах, сущностью будет являться факультет, если о студентах, сущность – студент и т.п.

Имя сущности при ER-моделировании, как правило, записывается заглавными буквами. Каждая сущность обладает определенным набором свойств (рассматриваем только свойства, представляющие интерес для пользователей в рамках проводимого исследования), которые запоминаются в информационной системе. Так, например, в качестве свойств сущности ФАКУЛЬТЕТ можно указать номер факультета, название факультета, в качестве свойств сущности СТУДЕНТ можно указать фамилию, дату рождения, место рождения, в качестве свойств сущности ЭКЗАМЕН – предмет, дату проведения экзамена, экзаменаторов.

Для информационного описания сущности вводится понятие атрибута.

Атрибут – поименованное свойство (характеристика) сущности. Атрибут представляет собой информационное отображение свойства сущности и принимает конкретное значение из множества допустимых значений. Так, например, для сущности ФАКУЛЬТЕТ атрибут "название" у конкретного экземпляра сущности принимает конкретное значение "вычислительной математики и кибернетики". Таким образом, атрибут представляет информационное описание количественных или качественных свойств сущности, описывает состояние сущности, позволяет идентифицировать сущность . Информация о сущности представляется совокупностью атрибутов. Такую совокупность атрибутов часто называют записью об объекте .

Совокупность сущностей, характеризующихся в информационной системе одним и тем же перечнем свойств, называется классом сущностей (набором объектов). Так, например, совокупность всех сущностей СТУДЕНТ составляет класс сущностей СТУДЕНТ, совокупность всех сущностей ФАКУЛЬТЕТ составляет класс сущностей ФАКУЛЬТЕТ. Класс сущностей описывается перечнем свойств сущностей, составляющих этот класс .

Экземпляром сущности будем называть конкретную сущность (сущность с конкретными значениями соответствующих свойств) . Выше мы определили сущность как то, о чем будет накапливаться информация в информационной системе. Это только одна сторона. Информация должна не просто храниться сама по себе, а использоваться для удовлетворения информационных потребностей пользователя. Для реализации подавляющего числа запросов пользователю прежде всего необходимо найти интересующий его экземпляр сущности (с целью обработки, корректировки, удаления). Поэтому важнейшим свойством сущности является однозначная идентификация ее экземпляров по одному или группе атрибутов (уникальному идентификатору) . У сущности ФАКУЛЬТЕТ это, например, номер факультета, у сущности СТУДЕНТ это может быть атрибут "фамилия", если у всех студентов разные фамилии, группа атрибутов "фамилия", "имя", "отчество", или специально введенный уникальный идентификатор , например дополнительно введенный атрибут "код студента".

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

Пример класса сущностей СТУДЕНТ и конкретного экземпляра сущности показан на рис. 5.1

Рис. 5.1.

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

Класс связей может затрагивать несколько классов сущностей . Число классов сущностей , участвующих в связи, называется степенью связи n = 2, 3, ... Так, например, класс сущностей СТУДЕНТ связан с классом сущностей ФАКУЛЬТЕТ связью "учится на факультете". Степень этой связи равна двум. При n =2 связь называется бинарной. Заметим, что связь нужно рассматривать как двустороннюю: "студент учится на факультете" и "на факультете учатся студенты". Рассмотрим классификацию бинарных связей . В зависимости от того, сколько экземпляров сущности одного класса связаны со сколькими экземплярами сущности другого класса, различают следующие типы связей :

• Связь 1:1 . Одиночный экземпляр сущности одного класса связан с одиночным экземпляром сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и УЧЕБНЫЙ ПЛАН ПО СПЕЦИАЛЬНОСТИ ДЛЯ ФАКУЛЬТЕТА (каждому факультету соответствует свой учебный план по специальности или направлению).
• Связь 1:M . Единый экземпляр сущности одного класса связан со многими экземплярами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СТУДЕНТ (на одном факультете учатся много студентов).
• Связь M:N . Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ (на факультете может быть несколько специальностей и одна и та же специальность может быть на нескольких факультетах).

Числа, описывающие типы

Связь « Один – к одному » Один – к одному. Этот тип связи означает, что каждому объекту первого вида соответствует не более одного объекта второго вида, и наоборот. Например: сотрудник может руководить только одним отделом, и у каждого отдела есть только один руководитель.

Связь « Один – ко многим » Один – ко многим (или в обратную сторону Многие – к одному). Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, но каждому объекту второго вида соответствует не более одного объекта первого вида. Например: в каждом отделе может быть множество сотрудников, но каждый сотрудник работает только в одном отделе.

Связь « Многие – ко многим » Многие – ко многим. Этот тип связи означает, что каждому объекту первого вида может соответствовать более одного объекта второго вида, и наоборот. У этого типа связи иногда бывают собственные атрибуты. Например: каждый счет может включать множество товаров, и каждый товар может входить в разные счета.

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

Бинарные, тернарные связи Если связь соединяет две сущности, она называется бинарной. Связь может соединять более двух сущностей, например, связь, соединяющая три сущности, называется тернарной: Связь с арностью более 2 обычно имеет тип многие – ко многим по отношению ко всем связанным сущностям.

Пример ER- модели: Контора « Рога и копыта » Описание задачи Контора « Рога и копыта » занимается коммерческой деятельностью по реализации продукции, произведенной из рогов и копыт, и предоставлению магических услуг. Сотрудник организации имеет ФИО, табельный номер, должность. Сотрудники распределены по нескольким отделам. Каждый отдел имеет номер, название и руководителя. Сотрудник не может руководить более чем одним отделом. Организация работает с предприятиями - клиентами. Каждое предприятие имеет название и адрес. С предприятием может быть заключено несколько договоров. Договор характеризуется уникальным номером, датой и типом. Каждый договор курирует некоторый сотрудник. По мере реализации клиенту товаров и услуг по договору с некоторой периодичностью выставляются счета. Счет характеризуется уникальным номером, датой выставления, сроком оплаты и суммой, а также списком реализованных товаров и услуг с указанием их количества. По неоплаченным счетам начисляются пени. Счет может быть оплачен в несколько приемов, каждый платеж характеризуется номером, датой и суммой. Номер платежа уникален в пределах его счета. Цены на товары и услуги могут изменяться со временем.
Пример ER- модели: « Музыканты » Описание задачи Необходимо разработать базу данных для хранения информации о музыкантах, сочинениях и концертах. Музыкант характеризуется именем, датой рождения и страной рождения. Сочинение включает информацию о названии, композиторе и дате первого исполнения. Музыкант может играть на разных инструментах с разной степенью квалификации. Из музыкантов - исполнителей формируются ансамбли. Каждый ансамбль, кроме своих участников, содержит информацию о названии, стране и руководителе. Наконец, исполнения произведений характеризуются датой, страной, городом исполнения, а также ансамблем, дирижером и собственно исполняемым произведением.
17 Еще примеры В учебнике « Базы данных » на сайте