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

• Название: Реферат По теме Концепция erмодели, основные понятия erтехнологии. Тип сущности, типы связи, атрибуты, ключи, структуры ограничения степень связи, класс принадлежности
• Дата: 04.03.2022
• Размер: 1.21 Mb.
• Имя файла: Material.docx
• Тип: Реферат; #382762

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ИРКУТСКОЙ ОБЛАСТИ «ЧЕРЕМХОВСКИЙ ГОРНОТЕХНИЧЕСКИЙ КОЛЛЕДЖ ИМ. М.И. ЩАДОВА»

Реферат

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

Выполнила:

Неберкутя П.П

Группа ИС-20

Проверила:

Антипова А.А

2022г

Оглавление

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ПРОФЕССИОНАЛЬНОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ИРКУТСКОЙ ОБЛАСТИ «ЧЕРЕМХОВСКИЙ ГОРНОТЕХНИЧЕСКИЙ КОЛЛЕДЖ ИМ. М.И. ЩАДОВА» 1

Введение 4

Преобразование ER-модели в реляционную модель данных 7

Правила преобразования ER-модели в реляционную 11

Расширенная ER-модель (EER-модель) 11

Концептуальные ER-модели 12

Примеры ER-моделей 13

Пример разработки простой ER-модели 14

Введение

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

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

За последние несколько лет наблюдается тенденция к усложнению структур данных. Простые виды информации, представимой в форме чисел и текстовых строк, не утратив своей значимости, дополняются сегодня многочисленными мультимедийными документами, графическими образами, хронологическими рядами, процедурными, или активными, данными и мириадами прочих сложных информационных форм. В связи с этим появилась целая плеяда СУБД, поддерживающих новые коллекции данных и способных реализовать преимущества современных аппаратных средств. Одним из таких СУБД является MS Access 2003 (2007), входящая в пакет программ Microsoft Office, и являющаяся одной из популярных реляционных СУБД для локальных компьютеров.

Популярность СУБД Microsoft Access обусловлена следующими причинами:

• 
  доступность в изучении и понятность позволяют являться одной из лучших систем быстрого создания приложений управления базами данных;
  
• 
  полностью русифицирована;
  
• 
  возможность использования OLE технологии;
  
• 
  поддержка WWW-идеологии;
  
• 
  визуальная технология позволяет постоянно видеть результаты своих действий и корректировать их, кроме того, работа с конструктором форм может существенно облегчить дальнейшее изучение таких систем программирования, как Visual Basic или Delphi;
  
• 
  широко и наглядно представлена справочная система;
  
• 
  наличие большого набора "мастеров" по разработке объектов.
  

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

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

Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

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

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

Связь представляется в виде линии, связывающей две сущности или ведущей от сущности к ней же самой. При этом в месте «стыковки» связи с сущностью используются трехточечный вход в прямоугольник сущности, если для этой сущности в связи могут использоваться много (many) экземпляров сущности, и одноточечный вход, если в связи может участвовать только один экземпляр сущности. Обязательный конец связи изображается сплошной линией, а необязательный - прерывистой линией.

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


Рис. 1 – Типы связей


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

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

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

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


Рис. 2 – Модальность связи

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

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

Преобразование ER-модели в реляционную модель данных

Рассмотрим преобразование ER-модели в реляционную модель данных на абстрактном примере. Предположим, что дана ER-модель. Необходимо получить набор таблиц (отношений) вида Таблица (Ключ, Атрибут1, Атрибут2, …, АтрибутN). Ключ может быть составным. Удобно имена атрибутов в масштабе ER-модели сделать уникальными, тогда при построении реляционной модели их (почти никогда) не придется переименовывать.

1. 
   Преобразование множеств сущностей (для краткости - сущностей)
   

1. 
   Преобразование обычной сущности
   

Рис. 3 – Преобразование обычной сущности
Обычная сущность преобразуется в отдельную таблицу, полями таблицы будут все атрибуты сущности: Сущность (Ключ, Атрибут1, Атрибут2)

2. 
   Преобразование слабой сущности
   

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

Ключевые поля всех родительских таблиц войдут в ключ дочерней таблицы. Для дочерней таблицы они будут называться внешним ключом: Сущность1 (Ключ1, Ключ2, Атрибут1, Атрибут2).


Рис. 4 – Преобразование слабой сущности

3. 
   Преобразование подтипов сущностей
   

1 способ. Создается одна таблица, в которую помещают все атрибуты. Для того, чтобы указать, к какому подтипу относится объект, приходится вводить дополнительное поле-признак: Сущность1(Ключ, Атрибут1, Атрибут2, Атрибут3, Атрибут4, Атрибут4, Признак).

Недостатком этого способа является то, что в таблице остается много незаполненных полей: для объекта подтипа 1 атрибуты 4 и 5, а для объекта подтипа 2 - атрибуты 2 и 3 останутся пустыми.

2 способ. Создается отдельная таблица для каждого подтипа. В нее включаются все атрибуты этого подтипа и все атрибуты надтипа:

Подтип1(Ключ, Атрибут1, Атрибут2, Атрибут3)

Подтип2(Ключ, Атрибут1, Атрибут4, Атрибут5)

Недостатком этого подхода является то, что подтипы теперь никак не связаны друг с другом.

3 способ. Создается одна таблица для надтипа, и по одной таблице для каждого подтипа, в которую включаются ключевые поля надтипа:

Сущность1(Ключ, Атрибут1)

Подтип1(Ключ, Атрибут2, Атрибут3)

Подтип2(Ключ, Атрибут4, Атрибут5)

Недостатком этого подхода является то, что информация о каждом объекте теперь раскидана по двум таблицам.


Рис. 5 – Преобразование подтипов сущностей

2. 
   Преобразование связей
   
   1. 
      Связь М:М
      

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



Рис. 6 – Связь М:М

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

Сущность1Сущность2(Ключ1, Ключ2, Атрибут1).

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

2. 
   Связь 1:М
   

Рис. 7 – Связь 1:М

1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ второй сущности.

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

Сущность1Сущность2(Ключ1, Ключ2).

2 способ. Новая таблица не создается, а в таблицу дочерней сущности добавляют ключевые поля родительской сущности (в ключ дочерней сущности они входить не будут). Ключевые поля родительской сущности представляют собой внешний ключ (foreign key) для дочерней сущности.

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

Таблица дочерней сущности: Сущность2(Ключ2, Атрибут1, Ключ1).

3. 
   Связь 1:1
   

Рис. 8 – Связь 1:1

1 способ. Точно так же, как и в случае М:М, создается новая таблица, содержащая ключевые поля каждой сущности, участвующей в связи. В названии обычно отражают, какие именно сущности связываются, или называют новую таблицу именем связи. Ключом будет ключ любой сущности.

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

Сущность1Сущность2(Ключ1, Ключ2) или Сущность1Сущность2(Ключ1, Ключ2).

2 способ. Точно так же, как и во 2 случае 1:М, новая таблица не создается, а в таблицу одной из сущностей (будем считать ее дочерней) добавляют ключевые поля другой сущности (будем считать ее родительской).

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

Таблица дочерней сущности: Сущность1(Ключ1, Атрибут1, Ключ2),

или Сущность2(Ключ2, Атрибут2, Ключ1).

3 способ. Две таблицы для сущностей, связанных 1:1, объединяются в одну. Ключом новой таблицы может быть комбинация ключей обеих таблиц. Если хотя бы в одном направлении связь "ровно к одному", то ключ этой сущности можно считать ключом объединенной таблицы.

Таблицы: Сущность1(Ключ1, Атрибут1) и Сущность2(Ключ2, Атрибут2) заменяются на

Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2)

или, возможно, Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2),

или Сущность1Сущность2(Ключ1, Атрибут1, Ключ2, Атрибут2).

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

Рассмотрим связь 1:M, способ 2. Переименован внешний ключ.



Рис. 9 – Связь 1:М, переименован внешний ключ

Сущность1(Ключ1, Атрибут1, ЕщеОдинКлюч1).

Для связей с арностью более 2 обычно применяется тот же способ, что и для бинарной связи M:M - создается новая таблица, содержащая ключевые поля всех связанных таблиц: Сущность1Сущность2Сущность3(Ключ1, Ключ2, Ключ3).

Правила преобразования ER-модели в реляционную

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

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

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

Правило 4. В каждое отношение, соответствующее подчиненной сущности, добавляется набор атрибутов основной сущности, являющейся первичным ключом основной сущности.

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

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

Расширенная ER-модель (EER-модель)

Понятий обычной ER-модели достаточно для представления большинства схем баз данных, например, для большинства коммерческих систем БД. Однако такие области, как системы автоматизированного проектирования, системы автоматизированной подготовки производства и др. предъявляют более сложные требования к БД. Для их семантического моделирования ER-модель была дополнена новыми понятиями и трансформирована в EER-модель (Enhanced ER – model – расширенная модель «сущность–связь»). Такая модель содержит все элементы ER – модели плюс дополнительные понятия, а именно понятия генерализации, специализации, и агрегирования.

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

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

Агрегирование – это процесс объединения нескольких независимых сущностей (типов) в агрегированный (комплексный) тип.

Концептуальные ER-модели

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

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

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

Элемент данных (поле) – наименьшая поименованная единица данных. Используется для представления значения атрибута.

С элементом данных неразрывно связано понятие «тип данных», который может принимать соответствующее поле. В разных СУБД могут использоваться разные типы данных, наиболее распространенными из которых, используемые во многих СУБД, являются следующие: числовой (numeric), символьный (char), дата (date) и т.д.

Запись – поименованная совокупность полей. Используется для представления совокупности атрибутов сущности (записи о сущности).

Экземпляр записи – запись с конкретными значениями полей.

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

Файл – поименованная совокупность экземпляров записей одного типа. Используется для представления однородного набора сущностей.

Набор файлов – поименованная совокупность файлов, обрабатываемых в системе. Используется для представления нескольких наборов сущностей.

Понятие «группа» является обобщающим понятием «файл» и «запись».

Группа – это поименованная совокупность элементов данных и других групп.

Важнейшим понятием концептуальной модели является понятие связи между сущностями (наборами сущностей). В моделях данных СУБД соответствующее понятие отражается понятием «групповое отношение».

Групповое отношение – поименованное бинарное отношение, заданное на двух множествах экземпляров рассматриваемых групп. По характеру бинарных связей различают групповые отношения вида 1:1, 1:M, M:1, M:N. Пары чисел называют коэффициентами группового отношения. В групповом отношении один член группы назначается владельцем отношения, другой – членом.

Для представления группового отношения используется две формы:

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

По типу графов различают:

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

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

Примеры ER-моделей

Пример 1

ER-модель: ЖЭК

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



Рис. 10 – Пример ER-модели ЖЭКа

Пример 2

ER-модель конторы «Рога и копыта»

Описание задачи: Контора «Рога и копыта» занимается коммерческой деятельностью по реализации продукции, произведенной из рогов и копыт, и предоставлению магических услуг.

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

Организация работает с предприятиями-клиентами. Каждое предприятие имеет название и адрес. С предприятием может быть заключено несколько договоров.

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

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



Рис. 11 – Пример ER-модели конторы «Рога и копыта»

Пример разработки простой ER-модели

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

1. Список сущностей предметной области.

2. Список атрибутов сущностей.

3. Описание взаимосвязей между сущностями.

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

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

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

• 
  Хранить информацию о покупателях.
  
• 
  Печатать накладные на отпущенные товары.
  
• 
  Следить за наличием товаров на складе.
  

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

• 
  Покупатель - явный кандидат на сущность.
  
• 
  Накладная - явный кандидат на сущность.
  
• 
  Товар - явный кандидат на сущность
  
• 
  (?) Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
  
• 
  
  (?) Наличие товара – это, скорее всего, атрибут, но атрибут какой сущности?
  

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



Рис. 12 – Первый вариант ER-диаграммы

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

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



Рис. 12 – Второй вариант ER-диаграммы

Теперь необходимо задуматься об атрибутах сущностей. Выясняется следующее:

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

Каждый товар имеет наименование, цену, а также характеризуется единицами измерения.

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

Каждый склад имеет свое наименование.

Снова выпишем все существительные, которые будут потенциальными атрибутами, и проанализируем их:

Юридическое лицо – термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.

Наименование покупателя – явная характеристика покупателя.

Адрес – явная характеристика покупателя.

Банковские реквизиты – явная характеристика покупателя.

Наименование товара – явная характеристика товара.


(?) Цена товара – похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?

Единица измерения – явная характеристика товара.

Номер накладной – явная уникальная характеристика накладной.

Дата накладной – явная характеристика накладной.

(?) Список товаров в накладной – список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.

(?) Количество товара в накладной – это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".

(?) Цена товара в накладной – опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше – это одно и то же?

Сумма накладной – явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.

Наименование склада – явная характеристика склада.

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

С возникающим понятием "Список товаров в накладной" все довольно ясно. Сущности "Накладная" и "Товар" связаны друг с другом отношением типа много-ко-многим. Такая связь должна быть расщеплена на две связи типа один-ко-многим. Для этого требуется дополнительная сущность. Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами - "каждая накладная обязана иметь несколько записей из списка товаров в накладной", "каждая запись из списка товаров в накладной обязана включаться ровно в одну накладную", "каждый товар может включаться в несколько записей из списка товаров в накладной", " каждая запись из списка товаров в накладной обязана быть связана ровно с одним товаром". Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Теперь можно внести все это в диаграмму:



Рис. 13 – Третий (итоговый) вариант ER-диаграммы