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

В этом смысле моделирование предметной области, базирующееся на использовании графических диаграмм, является удачным решением. Графическая форма позволяет отобразить в компактном виде (за счет наглядных условных обозначений) типологию и свойства сущностей и связей, а формализмы, положенные в основу 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) имеет тип «многие ко многим»: один сотрудник может участвовать во многих проектах, и в проекте могут участвовать многие сотрудники.

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

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 . Несколько экземпляров сущности одного класса связаны с несколькими экземплярами сущности другого класса. Примером является связь между классами сущностей ФАКУЛЬТЕТ и СПЕЦИАЛЬНОСТЬ (на факультете может быть несколько специальностей и одна и та же специальность может быть на нескольких факультетах).

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

ER-модели в отрыве от тематики проектирования реляционных баз данных.

Но если требуется одновременно использовать термины 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.2.

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

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

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

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

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

Концептуальная модель базы данных это

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

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

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

1. Объект или сущность . Это фактическая вещь или объект (для людей) за которой пользователь (заказчик) хочет наблюдать. Например, Иванов Иван Иванович;
2. Атрибут это характеристика объекта, соответствующая его сущности. Например. Задаем себе вопрос: Какую информацию нужно хранить об Иванове Иване Ивановиче? Ответы на этот вопрос и будут атрибуты объекта Иванов Иван Иванович;
3. Третье понятие в проектировании концептуальной базы данных это связь или отношения между объектами.

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

Концептуальная модель базы данных условные обозначения

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

Диаграмма сущность/отношения (объект/связь) называют ER-диаграммой или EDR (entity-relationship diagram). Сама модель сущность-связь была предложена профессором Peter Pin-Shen Chen (Питер Чен) в 1976 году. Правила написания и условные обозначения ER-диаграммы называют нотацией. Распространены две основные нотации ER-диаграмм:

• Нотация Питера Чена;
• Нотация Gordon Everest (Гордона Эверста). Под назаванием Crow’s Foot или Fork (вилка).

Обозначения ER-диаграммы по Питеру Чену

Чен предложил и это приняли следующие условные обозначения для ER-диаграмм:

• Сущность или объект обозначать прямоугольником;
• Отношения обозначать ромбом;
• Атрибуты объектов, обозначаются овалом;
• Если сущность связана с отношением, то их связь обозначается прямой линией со стрелкой. Необязательная связь обозначается пунктирной линией. Мощная связь обозначается двойной линией.

Каждый атрибут может быть связан с одним объектом (сущностью).

Нотация Gordon Everest

Gordon Everest ввел новое обозначение связей, которые получили название вилка или воронья лапа. Также он ввел, что объект должен обозначаться прямоугольником с названием типа объекта в виде имени существительного внутри прямоугольника. Причем, это имя должно быть уникальным в пределах создаваемой базы данных.

Атрибуты не выделяются в отдельную фигуру, а вписываются в прямоугольник объекта именем существительным с уточняющим словом.

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

концептуальная модель базы данных ERD Fork

Дополнения

Атрибуты в ER диаграмме, могут иметь свои собственные атрибуты (композитный) атрибут.

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

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

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

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

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

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

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

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

Задача: разработать ER-модель для АИС некоторой оптовой торговой фирмы .

Основные этапы решения задачи

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

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

· Хранить информацию о покупателях.

· Печатать накладные на отпущенные товары.

· Следить за наличием товаров на складе.

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

· Покупатель - кандидат на сущность.

· Накладная - кандидат на сущность.

· Товар - кандидат на сущность.

· (?) Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.

· (?) Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

3. Определение связей между сущностями. Для рассматриваемого примера сразу возникает очевидная связь между сущностями: «Покупатели могут покупать много Товаров » и «Товары могут продаваться многим Покупателям ». Первый вариант диаграммы выглядит так:

Задав дополнительные вопросы менеджеру, были выявлены новые данные о том, что:

· фирма имеет несколько складов, а каждый товар может: храниться на нескольких складах; быть проданным с любого склада;

· покупатели покупают товары, получая при этом накладные, в которые внесены данные о количестве и цене купленного товара;

· каждый покупатель может получить несколько накладных;

· каждая накладная выписывается на одного покупателя;

· каждая накладная содержит хотя бы один товар (не бывает пустых накладных);

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

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

Учитывая новые сведения, диаграмма примет следующий вид:

4. Определение атрибутов сущностей. Беседуя с сотрудниками фирмы, были выяснены следующие обстоятельства:

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

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

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

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

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

· Юридическое лицо – т.к. фирма работает только с юридическими лицами (не работает с физическими лицами), то такой атрибут выделять нет смысла.

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

· Адрес - характеристика покупателя.

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

· Наименование товара - характеристика товара.

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

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

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

· Дата накладной - характеристика накладной.

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

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

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

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

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

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

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

Атрибуты Количество товара в накладной и Цена товара в накладной являются атрибутами сущности Список товаров в накладной .

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

В результате ER-диаграмма примет вид:

Модели данных

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

Модель данных определяется тремя компонентами:

· допустимой организацией данных;

· ограничениями целостности (семантической);

· множеством операций, допустимых над объектами модели данных.

Допустимая организация данных определяется разнообразием и количеством типов объектов модели данных, ограничениями на структуру данных.

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

Ряд ограничений целостности поддерживается моделью данных по умолчанию и распространяется на все типовые ситуации, возникновение которых возможно при внесении изменений в БД. Например, если между записями типа ГРУППА и СТУДЕНТ установлена иерархическая связь, то СУБД воспрепятствует удалению сведений о студенческой группе, если с ней связана хотя бы одна запись о студенте.

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

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

Поддерживаемые СУБД модели данных традиционно разбиваются на: сетевые , иерархические , реляционные (имеются также другие модели данных). Эта классификация условна, т.к. каждая СУБД поддерживает свою оригинальную модель данных. И даже если модель данных относится к одной из выделенных разновидностей, она может содержать достаточно много отличительных особенностей. Наиболее распространенными моделями являются реляционные модели данных (РМД).