2.1 Сущности, типы сущностей
Сущность — Это реальный или воображаемый объект, информация о котором представляет интерес. В диаграммах Er-модели сущность представляется в виде прямоугольника, содержащего имя сущности. При этом имя сущности — это имя типа, а не конкретного объекта — экземпляра этого типа. Каждый экземпляр сущности должен быть отличим от любого экземпляра той же сущности. В зависимости от режима представления диаграммы прямоугольник может содержать имя сущности, ее описание, список ее атрибутов и другие требования.
Каждая сущность должна обладать следующими свойствами:
иметь уникальный идентификатор;
содержать один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь с другими сущностями;
содержат совокупность атрибутов, однозначно идентифицирующих каждый экземпляр сущности;
Любая сущность может иметь произвольное количество связей с другими сущностями. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.
Определите три ядра класса объектов: удочка, ассоциативная и характерная, и также подкласс ассоциативных объектов — назначения
Ассоциативный аромат (ассоциация) является передачей типа «многие — к — многие» между двумя или больше объектами или копиями объектов. Ассоциации рассматривают как полные объекты:
— Они могут участвовать в других ассоциациях и назначениях таким же образом, как объекты удочки,
— Может обладать свойствами, то есть иметь не только коммутируемый из ключевых атрибутов, необходимых для инструкций связи, но также и любого числа других атрибутов, характеризующих передачу. Характерный аромат (характеристика) является передачей типа «многие — к — один» или «один — к — один» между двумя объектами (особый случай ассоциации). Единственная цель характеристики в рамках продуманной области данных состоит в описании или спецификации некоторого другого аромата. Необходимость их воскресает, потому что у объектов реального мира иногда есть многозначные свойства. 0бозначающая аромат или назначение — передача типа «многие — к — один» или «один — к — один» между двумя объектами и отличаются от характеристики, которая не зависит от определяемого аромата.
Назначения используют для хранения повторяющихся значений больших текстовых атрибутов: наказания «кодификаторы», изученные студентами, именами устройств и их отделов, материально-технических ресурсов, и т.д.
Пустите нам переопределять теперь аромат удочки как аромат, который не является ни ассоциацией, ни назначением, характеристикой. У таких объектов есть независимое существование, хотя они и могут определять другие объекты как, например, инспектор назначает отдел кадров.
Есть два типа сущностей: зависимая и независимая. Если экземпляры сущности могут быть уникально идентифицированы без определения ее связей с другими сущностями, она называется независимой. В противном случае сущность называют зависимой. Зависимая сущность отображается в Erwin прямоугольником с закругленными углами.
Что такое сущность в программировании
СУБД (Система Управления Базой Данных) — программное средство, совокупность программ, предназначенных для поддержки всех основных этапов работы базы данных. С помощью СУБД создается база данных, редактируются, удаляются и добавляются компоненты базы, осуществляется ввод информации и интерфейсные функции.
Основные понятия и определения
- сущность
- связь
- атрибут
- модель данных
Каждый экземпляр сущности должен быть отличим от любого другого экземпляра той же сущности.
- Один к одному
- Один ко многим
- Многие к одному
- Многие ко многим
Пример связи «один ко многим» — Фамилия — Человек. Фамилия Иванов одна, а людей с такой фамилией — много.
Пример связи «многие ко многим» — Врачи — Пациенты.
Рассмотрим пример связи «многие к одному» необязательную с одного конца. Связь между сущностями БИЛЕТ и ПАССАЖИР связывает билеты и пассажиров. При том конец сущности с именем «для» позволяет связывать с одним пассажиром более одного билета, причем каждый билет должен быть связан с каким-либо пассажиром. Конец сущности с именем «имеет» означает, что каждый билет может принадлежать только одному пассажиру, причем пассажир не обязан иметь хотя бы один билет.
- Каждый БИЛЕТ предназначен для одного и только одного ПАССАЖИРА;
- Каждый ПАССАЖИР может иметь один или более БИЛЕТОВ.
Атрибутом сущности является любая деталь, которая служит для уточнения, идентификации, классификации, числовой характеристики или выражения состояния сущности. Имена атрибутов заносятся в прямоугольник, изображающий сущность, под именем сущности и изображаются малыми буквами, возможно, с примерами.
Уникальным идентификатором сущности является атрибут, комбинация атрибутов, комбинация связей или комбинация связей и атрибутов, уникально отличающая любой экземпляр сущности от других экземпляров сущности того же типа.
Модель данных — способ отражения сущностей, атрибутов сущностей и их связей.
Введение
Рассматриваются предложения определения данных SQL. Удобно разделить эти предложения на два больших класса, которые весьма грубо можно охарактеризовать как логический и физический. Предложения «логического» класса должны иметь дело с объектами, которые на самом деле представляют интерес для пользователей, например с базовыми таблицами и представлениями, а «физического» — с объектами, которые представляют интерес, главным образом, для системы, например дисковые тома.
Ниже перечислены основные предложения логического определения данных:
| CREATE TABLE | CREATE VIEW | CREATE INDEX |
| ALTER TABLE | ||
| DROP TABLE | DROP VIEW | DROP INDEX |
В курсе лекций также рассматриваются различные предложения SQL, такие как DELETE, INSERT, UPDATE. А также, самое главное предложение SQL — SELECT.
Базовые таблицы
Базовая таблица — (важный) специальный случай более общего понятия «таблица». Поэтому давайте начнем с того, что несколько уточним это более общее понятие.
Определение
- Строка заголовков столбцов специфицирует один или более столбцов, задавая наряду с прочим тип данных для каждого из них;
- Каждая строка данных содержит в точности одно значение данных для каждого из столбцов, специфицированных в строке заголовков столбцов. Кроме того, все значения в заданном столбце имеют один и тот же тип, а именно: тип данных, специфицированный для этого столбца в строке заголовков столбцов.
- Отметим, что в этом определении нет никакого упоминания об упорядочении строк. Строго говоря, строки реляционной таблицы считаются неупорядоченными. (Отношение — это математическое множество — множество строк, а множество в математике не обладает каким-либо упорядочением.) Как мы увидим, можно, однако, задавать некоторый порядок для этих строк, когда осуществляется их выборка в ответ на запрос, но такое упорядочение следует считать не чем иным, как удобством для пользователя. Оно не существенно для понятия таблицы.
- В отличие от строк столбцы таблицы предполагаются упорядоченными слева направо. (По крайней мере, они считаются упорядоченными таким образом в большинстве систем). Однако на практике существует очень немного ситуаций, когда такое упорядочение слева направо является существенным. Подобных ситуаций можно избегать при некоторой дисциплине, и это рекомендуется делать, как будет показано позднее.
Предложение CREATE TABLE
Теперь мы подробно обсудим предложение CREATE TABLE. Это предложение имеет следующий общий формат:
CREATE TABLE имя_базовой_таблицы (определение_столбца [, определение_столбца] . ) [другие параметры];
Здесь «определение_столбца» в свою очередь имеет формат:
имя_столбца тип_данных [NOT NULL]
Прямые скобки в синтаксических определениях используются для того, чтобы указать, что конструкции, заключенные в эти скобки, являются необязательными (т. е. могут быть опущены). Многоточие указывает, что непосредственно предшествующая ему синтаксическая единица может повторяться один или более раз. Конструкции, представленные прописными буквами, должны быть записаны в точности так, как показано. Наконец, конструкции, представленные строчными буквами, должны заменяться конкретными значениями, выбранными пользователем.
Рассмотрим пример предложения CREATE TABLE для таблицы Поставщики:
create table Поставщики (Номер_Поставщика int, Фамилия char(20), Город char (15));
Результат этого предложения состоит в том, что создается новая пустая базовая таблица, названная xyz. Поставщики, где xyz-имя, под которым известен системе пользователь, издающий предложение CREATE TABLE. В системный каталог при этом помещается статья, описывающая эту таблицу. Пользователь xyz может обращаться к таблице по ее полному имени xyz. Поставщики или по сокращенному имени Поставщики. Другие пользователи должны обращаться к ней только по ее полному имени. Данная таблица состоит из трёх столбцов с именами xyz.Поставщики.НОМЕР_ПОСТАВЩИКА, xyz.Поставщики.ФАМИЛИЯ xyz.Поставщики.ГОРОД, имеющих указанные в определении типы данных. (Типы данных будут рассматриваться ниже). Пользователь xyz может обращаться к этим столбцам по их полным или по сокращенным именам: Поставщики.HOMEP-ПОСТАВЩИКА, Поставщики.ФАМИЛИЯ и Поставщики.ГОРОД. Другие пользователи должны применять только полные имена столбцов. Заметим, однако, что независимо от того, включается ли в имя часть «xyz», часть «Поставщики» может быть опущена, если это не приводит к двусмысленности, но ее включение никогда не является ошибкой. Вообще относительно имен справедливы следующие правила. Имена пользователей, например xyz, являются уникальными во всей системе. Имена таблиц (неуточненные) уникальны для пользователя. Имена столбцов (неуточненные) уникальны для таблицы.
Кроме того, в качестве имен не могут использоваться ключевые слова языка SQL (CREATE, TABLE, SELECT и т. д.). Первая литера любого имени должна быть буквой ( А-Z или одной из специальных литер #, $, @), а остальные литеры — буквами, цифрами (0-9) или знаком подчеркивания. Имена таблиц и столбцов могут содержать максимум 18 литер, а имена пользователей — максимум 8 литер. Под «таблицей» здесь понимаются как базовые таблицы, так и представления. Таким образом, представление не может иметь такое же имя, как и базовая таблица. После того как таблица создана, в нее могут быть введены данные с помощью предложения INSERT (вставить) языка SQL. Вариант заполненной таблицы Поставщики.
Типы данных
| INTEGER | двоичное целое число, занимающее полное машинное слово, 31 бит со знаком |
| SMALLINT | двоичное целое число, занимающее полуслово, 15 бит со знаком |
| DECIMAL (p,q) | упакованное десятичное число, включающее р цифр и знак (0 254, то поле является и «длинным полем», и объектом строгих ограничений. Длинные поля предназначены для того, чтобы иметь дело с данными в свободном формате, такими, как длинные текстовые строки, а не с простыми форматизированными данными, например номер поставщика или объем поставки. По существу, единственной операцией, в которой могут в качестве операндов использоваться такие поля, является операция присваивания базе данных (INSERT или UPDATE) либо из базы данных (SELECT). He допускаются какие-либо операции, которые предполагают сравнение с длинным полем. Поэтому, например, длинные поля не могут быть индексированными, на них нельзя ссылаться во фразах WHERE, GROUP BY или ORDER BY и т. п.) |
Числовые типы
Числовые типы позволяют хранить числовые данные (целые числа, действительные числа и числа с плавающей точкой), представлять величины и выполнять вычисления.
BINARY-INTEGER
Тип данных BINARY-INTEGER используется для представления целых чисел со знаком. Диапазон его значений: -2147483647 ..2147483647. Значения BINARY-INTEGER требуют для своего хранения меньше памяти, чем значения типа NUMBER.
Тип данных NUMBER используется для представления чисел с фиксированной или плавающей точкой практически любого размера. Диапазон абсолютной величины его значений: 1 .0Е-130 .. 9.99Е125. Для значений этого типа вы можете указать также точность, т.е. общее число значащих цифр, и масштаб, который определяет, с какого разряда после десятичной точки начинается округление. Спецификация типа имеет следующий синтаксис:
NUMBER[(точность, масштаб)]
При объявлении переменной, предназначенной для хранения чисел с фиксированной точкой, обязательно указывается масштаб, и спецификация типа должна иметь следующую форму:
NUMBER(точность, масштаб)
При объявлении переменной, предназначенной для хранения чисел с плавающей точкой, нельзя указывать точность или масштаб, поскольку десятичная точка «плавает» (и может занять любую позицию); в этом случае спецификация типа должна иметь следующую форму:
NUMBER
При объявлении переменной, предназначенной для хранения целых чисел, которые не имеют десятичной точки, спецификация типа должна иметь следующую форму:
NUMBER(точность) -- то же самое, что и NUMBER(точность,0)
Для указания точности и масштаба нельзя использовать константы или переменные — они должны быть заданы целочисленными литералами. Максимальная точность чисел типа NUMBER — 38 десятичных разрядов. Если точность не указана, по умолчанию она будет установлена равной 38 или максимально возможному для вашей системы значению, если оно меньше 38.
Масштаб может быть задан любым числом в диапазоне от -84 до 127 и определяет, с какого разряда после десятичной точки начинается округление. Например, при масштабе, равном 2, округление будет производиться до ближайших сотых (вместо 3.456 будет 3.46). Масштаб может быть отрицательным, что вызовет округление в разрядах слева от десятичной точки. Например, при масштабе, равном -3, округление будет производиться до ближайших тысяч (вместо 3456 будет 3000). При масштабе, равном нулю, округление происходит до ближайшего целого. Если масштаб не указан, по умолчанию он принимается равным нулю.
INTEGER используется при объявлении переменных, предназначенных для хранения целых чисел с максимальной точностью до 38 десятичных цифр.
Символьные типы
Символьные типы позволяют хранить алфавитно-цифровые данные, представлять слова и текст, а также оперировать символьными строками.
Тип данных CHAR используется для представления символьных данных фиксированной длины. Внутреннее представление символов зависит от установленной кодировки базы данных, которая может быть, например, 7-битовым кодом ASCII или кодовой страницей 500 для кода EBCDIC.
Спецификация типа данных CHAR имеет необязательный параметр, который позволяет указать максимальную длину до 32767 байтов. Спецификация имеет следующий синтаксис:
CHAR[(максимальная длина)]
Максимальную длину нельзя задавать константой или переменной -можно использовать только целочисленный литерал со значением в диапазоне 1 .. 32767.
Если максимальная длина не указана, по умолчанию она устанавливается равной 1. Обратите внимание, что максимальная длина переменной указывается в байтах, а не в символах. Таким образом, если переменная со спецификацией char (n) используется для хранения многобайтовых символов, то ее максимальная длина в символах будет меньше n. В базе данных максимальный размер столбца типа char не может превышать 2000 байтов. Поэтому в столбец типа char невозможно поместить значение типа char, если оно длиннее 2000 байтов.
Любое значение типа char (n) можно поместить в столбец базы данных, имеющий тип long, поскольку такой столбец может содержать значения с длиной до 2147483647 байтов, т.е. 2 гигабайтов. Однако вы не можете выбрать в переменную типа char (n) значение из столбца типа long, если оно длиннее 32767 байтов.
Тип данных VARCHAR используется для представления символьных данных переменной длины. Внутреннее представление символов зависит от установленной кодировки базы данных, которая может быть, например, 7-битовым кодом ASCII или кодовой страницей 500 для кода EBCDIC.
Спецификация типа данных VARCHAR имеет обязательный параметр, который позволяет указать максимальную длину до 32767 байтов. Спецификация имеет следующий синтаксис:
VARCHAR(максимальная длина)
Максимальную длину нельзя задавать константой или переменной — можно использовать только целочисленный литерал со значением в диапазоне 1 .. 32767.
Обратите внимание, что максимальная длина переменной указывается в байтах, а не в символах. Таким образом, если переменная со спецификацией VARCHAR (n) используется для хранения многобайтовых символов, то ее максимальная длина в символах будет меньше n. В базе данных максимальный размер столбца типа VARCHAR не может превышать 4000 байтов. Поэтому в столбец типа VARCHAR невозможно поместить значение типа VARCHAR, если оно длиннее 4000 байтов.
Любое значение типа VARCHAR (n) можно поместить в столбец базы данных, имеющий тип LONG, поскольку такой столбец может содержать значения с длиной до 2147483647 байтов. Однако вы не можете выбрать в переменную типа VARCHAR (n) значение из столбца типа LONG, если оно длиннее 32767 байтов.
Другие типы
Тип данных boolean используется для представления булевых значений true и false, а также пустого значения null, которое применяется в случаях, когда настоящее значение отсутствует, неизвестно или неприменимо. К переменным типа boolean могут применяться только логические операции.
Спецификация типа данных boolean не имеет никаких параметров. Переменной типа boolean могут быть присвоены только значения true и false, а также пустое значение null. Значения true и false нельзя поместить в столбец базы данных. Вы не можете также выбрать значение из столбца базы данных в переменную типа boolean.
Хотя это и в некоторой степени отступление от основной темы данной главы, сейчас удобно рассмотреть различные виды констант:
| Целочисленная | записывается как десятичное целое число со знаком или без знака, без десятичной точки; примеры: 4 -95 +364 0 |
| Десятичная | записывается как десятичное число со знаком или без знака, с десятичной точкой; примеры: 4,0 -95.7 +364.05 0.007 |
| С плавающей точкой | записывается как десятичная константа, за которой следует буква Е с последующей целочисленной константой; примеры: 4ЕЗ -95.7Е46 +364Е-5 0.7Е1 (примечание: выражение хЕу представляет значение х*(10**у)) |
| Строковая | записывается либо как строка литер, заключенная в одиночные кавычки, либо как строка пар шестнадцатиричных цифр, представляющих рассматриваемые литеры в коде EBCDIC, заключенная в одиночные кавычки, которой предшествует буква X; примеры: ‘123 Main St.’ ‘PIG’ X’FlF2F340D481899540E2A34B’ X’D7C9C7′ (первый и третий примеры представляют одно и то же значение, так же как второй и четвертый) |
Предложение ALTER TABLE
Точно так же, как в любое время можно с помощью предложения CREATE TABLE создать новую базовую таблицу, можно также в любое время изменить существующую базовую таблицу, добавляя к ней справа новый столбец. Для этого используется предложение ALTER TABLE:
ALTER TABLE имя_базовой_таблицы ADD имя_столбца тип_данных ;
ALTER TABLE Поставщики ADD СКИДКА SMALLINT;
Это предложение добавляет к таблице Поставщики столбец СКИДКА. Все существующие записи таблицы Поставщики расширяются с трёх значений полей данных до четырёх, и во всех случаях новое пятое поле принимает неопределенное значение. Спецификация NOT NULL в предложении ALTER TABLE не допускается. Заметим, между прочим, что только что описанное расширение существующих записей, не означает, что в это время физически обновляются записи в базе данных. Изменяется лишь хранимое в каталоге описание таблицы. Отдельные записи физически не изменяются до тех пор, пока они в следующий раз не станут целевыми для предложения UPDATE языка SQL.
Предложение DROP TABLE
Существующую базовую таблицу можно в любое время уничтожить с помощью предложения:
DROP TABLE имя-базовой-таблицы;
Специфицированная базовая таблица удаляется из системы (точнее, из каталога удаляется описание этой таблицы). Автоматически удаляются также все индексы и представления, определенные над этой базовой таблицей.
В дальнейших примерах будет использованы следующие таблицы:
| Номер_Поставщика | Фамилия | Город |
| 1 | Смит | Лондон |
| 2 | Джонс | Париж |
| 3 | Блейк | Париж |
| 4 | Кларк | Лондон |
| 5 | Адамс | Атенс |
| Номер_Поставщика | Название | Вес | Цвет |
| 1 | гайка | 12 | красный |
| 1 | болт | 15 | зеленый |
| 3 | винт | 17 | голубой |
| 4 | винт | 15 | красный |
| 4 | шуруп | 20 | голубой |
Сущности и связи — JS: Предметно-ориентированное проектирование
ERM — Модель данных, позволяющая описывать концептуальные схемы предметной области.
Сущности
Этот подход включает в себя два основных понятия: сущность и связь. Проще всего начать с примеров:
- Пользователь
- Кинозал
- Фильм
- Билет
- Показ фильма
Это сущности нашей предметной области, с которыми предстоит работать в коде. Как видите, понятие сущность довольно интуитивно. Но также оно обладает и рядом формальных характеристик:
- Идентификация
- Время жизни
Идентификация означает, что мы можем рассматривать сущности независимо и выделять одни среди других. Например, у нас есть разные кинозалы, и это разные сущности. Другой пример это пользователи. Даже если два человека имеют одинаковые ФИО, мы всё равно сможем их различить на основе дополнительных признаков. В программировании обычно сущностям присваивается идентификатор (суррогатный ключ), который и используется для этой цели. Чаще всего эта задача возлагается на базу данных. В нашей ситуации базы нет, поэтому мы будем задавать его самостоятельно.
const user = new User('Илон'); console.log(user.id); // 896b677f-fb14-11e0-b14d-d11ca798dbac // User.js import uuid from 'uuid/v4'; class User constructor(name) this.id = uuid(); this.name = name; > > Библиотека uuid позволяет генерировать уникальный идентификатор, который можно использовать для идентификации. Кстати uuid очень полезная штука, может пригодиться в некоторых типах задач.
Время жизни означает, что наша сущность в какой-то момент появилась и когда-то может исчезнуть.
Связи
Между собой сущности образуют связи. Например, человек может быть владельцем нескольких машин, но машина может принадлежать только одному человеку. Пользователи Хекслета проходят много курсов, каждый курс доступен всем пользователям.
Таким образом можно выделить три основных типа связи: один к одному (o2o), один ко многим (o2m) и многие ко многим (m2m).
Выше представлена диаграмма Entity-Relationship. Она входит в стандарт UML и неплохо помогает понять то, какие сущности составляют вашу предметную область и как они друг с другом связаны.
Что можно сказать глядя на диаграмму?
- В одном зале может быть много показов фильмов;
- Один фильм может быть показан много раз;
- Фильмы и залы связаны друг с другом как «многие ко многим». То есть один фильм показывается в разных залах, а в одном зале идут разные фильмы.
Всё это довольно очевидно и соответствует нашему опыту посещения кинозалов. В других предметных областях это уже не так просто, и то, как вы проектируете сущности и их связи, имеет сильное влияние на ваше приложение. Общее правило такое, чем больше связей и чем более они разнообразные, тем сложнее приложение. Часто бывает такое, что программисты «закладываются на будущее» (которое не факт, что наступит) и пытаются делать чуть ли не все связи m2m. Чаще всего такой подход оказывается примером over-engineering (гиперпроектирование), другими словами, не надо добавлять сложности там, где нет реальной потребности.
Кроме влияния на логику работы, связи также сильно влияют на способ хранения сущностей в базе данных. Например, в реляционных базах данных, связь m2m всегда подразумевает наличие промежуточной таблицы. В свою очередь рефакторинг базы данных не такое простое занятие, как изменение кода.
Пример
На Хекслете есть курсы. Каждый курс состоит из уроков. Урок не может существовать без курса. Вот как может быть представлена эта модель в коде:
const course = new Course('JS: DDD'); const lesson1 = new Lesson(course, 'Введение'); const lesson2 = new Lesson(course, 'Модель Сущность-Связь'); Передача курса в конструктор удобна по двум причинам. Сразу становится видна и понятна связь урока с курсом. А также на уровне языка заложено бизнес-правило, что урок не может существовать без курса.
Объекты-значения (Справочники)
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно
- 130 курсов, 2000+ часов теории
- 1000 практических заданий в браузере
- 360 000 студентов
Наши выпускники работают в компаниях:
Модель «сущность—связь»
Одной из наиболее популярных семантических моделей данных на этапе ин- фологического проектирования является неформальная модель «сущность- связь» — ER-модель. Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. В связи с наглядностью представления концептуальных схем баз данных (и не только их) ER-модели получили широкое распространение в CASE -системах. CASE-система — набор инструментов и методов программной инженерии для проектирования программного обеспечения, который помогает обеспечить высокое качество программ, отсутствие ошибок и простоту в обслуживании программных продуктов. Также под CASE понимают совокупность методов и средств проектирования информационных систем с использованием CASE-инструментов.
Базовыми конструктивными понятиями инфологических моделей в терминах ER-модели являются: сущность, экземпляр сущности, связь между сущностями, свойства (атрибуты) сущности, домен и ключ сущности.
Сущность — это различимый класс однотипных объектов предметной области (класс объектов, который мы можем отличить от другого класса объектов), информация о которых должна быть учтена в модели, а затем храниться в базе данных.
Каждая сущность должна иметь наименование. Сущностью, например, могут быть люди, места, самолеты, рейсы, цвета, студенты, накладные и др.
Экземпляр сущности — это конкретный представитель данной сущности. Например, представителем сущности СТУДЕНТ может быть Петров И. И. Экземпляры сущностей должны быть различимы, т. е. сущности должны иметь некоторые свойства, уникальные для каждого экземпляра этой сущности.
Таким образом, необходимо различать такие понятия, как класс (тип) сущности и экземпляр сущности. Понятие «тип сущности» относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром — Москва, Киев и т. д.
Атрибут сущности — это именованная характеристика сущности, являющаяся (определяющаяся) некоторым свойством сущности и принимающая значения из некоторого множества значений. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Например, Цвет может быть определен для многих сущностей: собака, автомобиль, дым и т. д. Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются Тип, Марка, Номерной знак. Цвет и т. д. Здесь также существует различие между типом и экземпляром. Тип атрибута Цвет имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т. д., однако каждому экземпляру сущности присваивается только одно значение атрибута.
Домен — это диапазон допустимых значений, которые может принимать атрибут.
Ключ сущности — это не избыточный (минимальный) набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся атрибутам, т. е. нарушает его уникальность. Например, для сущности СОТРУДНИК ключом является атрибут Табельный номер или набор: Фамилия, Имя, Отчество, Должность. Необходимо отметить, что сущность может иметь несколько различных ключей.
Связь — это некоторая ассоциация между двумя сущностями, представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Одна сущность может быть связана с другой сущностью или сама с собой. Связи позволяют по одной сущности находить другие сущности, связанные с ней.
Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Например, связь между сущностями может выражаться следующей фразой: «Каждый студент обязан числиться ровно в одной группе».
При построении инфологических моделей в качестве инструмента моделирования будем использовать язык ER-диаграмм (диаграмм «сущность—связь», ER, Entity—Relationship).
Первый вариант модели «сущность—связь» был предложен в середине 1970-х годов Питером Пин-Шен Ченом. К настоящему времени существуют различные способы описания ER-моделей — так называемые НОТАЦИИ.
В данном пособии сущности будем изображать прямоугольниками с наименованиями, атрибуты изображать в пределах прямоугольника, определяющего сущность, причем ключевые атрибуты будем подчеркивать, связи изображаем линией, соединяющей сущности (рис. 5.3-1).
Рис. 5.3-1. Способы описания ER-моделей
Каждая связь имеет два конца и одно или два наименования. Наименование обычно выражается в неопределенной глагольной форме: «иметь», «принадлежать» и т. п. Каждое из наименований относится к своему концу связи. Обычно наименования не пишутся ввиду их очевидности.
Каждая связь может иметь один из следующих типов связи (рис. 5.3-2).
Такой способ изображения связей соответствует нотации Баркера. В нотации IDEF1X мощность связи со стороны «много» изображается черным кружком (рис. 5.3-3).
Рис. 5.3-2. Виды связей
Рис. 5.3-3. Нотация IDEF1X
Связь типа один-к-одному (1:1) означает, что один экземпляр первой сущности (левой) связан с одним экземпляром второй сущности (правой). Связь один-к-одному чаще всего свидетельствует о том, что на самом деле мы имеем всего одну сущность, неправильно разделенную на две.
Связь типа один-ко-многим (1:М) означает, что один экземпляр первой сущности (левой) связан с одним или несколькими экземплярами второй сущности (правой).
Связь типа много-ко-многим (N:M) означает, что один экземпляр первой сущности (левой) связан с одним или несколькими экземплярами второй сущности (правой), а также что один экземпляр второй сущности (правой) связан с одним или несколькими экземплярами первой сущности (левой).
При большом объеме ввод лишь нескольких основных атрибутов в описание значительно усложнит ER-диаграмму. В связи с этим язык ER-диаграмм используется для построения небольших моделей и иллюстрации отдельных фрагментов больших. Чаще же применяется менее наглядный, но более содержательный язык инфологического моделирования (ЯИМ), в котором сущности и ассоциации представляются предложениями вида:
СУЩНОСТЬ (атр_1, атр_2, . атр_п)
АССОЦИАЦИЯ [СУЩНОСТЬ S1, СУЩНОСТЬ S2. ] (атр_1, атр_2. атр_п)
Атрибуты, входящие в ключ, должны быть отмечены с помощью подчеркивания.
Для выявления связей между сущностями необходимо, как минимум, определить сами сущности. Но это не простая задача, так как в разных предметных областях один и тот же объект может быть сущностью, атрибутом или ассоциацией.
Все связи требуют описания, т. е. формализации. Описание должно обеспечивать: идентификацию связи; формулировку имен связи с точки зрения каждой участвующей сущности; вид связи (множественность и условность); формулировку того, как связь была формализована.
Цель формализации связей состоит в том, чтобы позволить установить связь экземпляра одной сущности с экземпляром другой. Это выполняется размещением вспомогательных атрибутов в соответствующих сущностях на модели. Когда это выполнено, говорят, что связь формализована.
Для формализации связи «один-к-одному» вспомогательные атрибуты могут быть добавлены к любой сущности, но не к обоим.
Для формализации связи «один-ко-многим» вспомогательные атрибуты должны быть добавлены к сущности на стороне «много».
Для формализации связи «много-ко-многим» создают отдельную ассоциативную сущность (сущность-связку), которая содержит ссылки на идентификаторы каждого из участвующих экземпляров. Подобно любой другой, ассоциативная сущность может иметь дополнительные атрибуты и участвовать в связях с другими сущностями
Отметим здесь, что первичный ключ дочерней сущности, как правило, является внешним ключом родительской сущности, а первичный ключ ассоциативной сущности строится из первичных ключей сущностей, связи между которыми она формализует.
Пример 5.3-1. Создать ER-диаграмму (модель) предметной области БИБЛИОТЕКА.
1. Описание предметной области.
База данных должна содержать данные о книгах в библиотеке. Кроме того, БД должна содержать данные о читателях, а также о факте выдачи книги соответствующему читателю. Одна книга имеет много экземпляров и поэтому может быть выдана многим читателям.
2. Уточнение задания.
Данные о книгах: номер книги в библиотеке (код книги), автор, название, количество. Данные о каждом читателе: номер читательского билета (код читателя), ФИО читателя. Данные о факте выдачи: дата сдачи книги в библиотеку.
3. Описание сущностей.
Опишем сущности на языке инфологического моделирования:
КНИГИ (КодКниги, Автор, Название, Количество)
ЧИТАТЕЛИ (КодЧитателя, ФИО)
4. Назначение ключевых атрибутов.
В сущности КНИГИ ключевой атрибут — КодКниги, в сущности ЧИТАТЕЛИ ключевой атрибут — КодЧитателя.
5. Описание связей.
Одна книга может быть выдана многим читателям, так как она имеет много экземпляров, один читатель может получить много книг. Таким образом, связь между сущностями КНИГИ И ЧИТАТЕЛИ — «МНОГО-КО-МНОГИМ».
6. Формализация связей.
При формализации связи «много-ко-многим» вводится дополнительная сущность—связь. Название такой сущности — ВЫДАЧА. Ключи сущностей книги и ЧИТАТЕЛИ входят как внешние в сущность ВЫДАЧА и образуют составной ключ. Таким образом, на языке мифологического моделирования описание сущностей выглядит следующим образом:
КНИГИ ( КодКниги, Автор, Название, Количество)
ВЫДАЧА [КНИГИ, ЧИТАТЕЛИ]( КодКниги, КодЧитателя, ДатаСдачи)
ЧИТАТЕЛИ( КодЧитателя, ФИО)
Представление ER-модели.
7. ER-модель разрабатываемой БД представлена на рис. 5.3-4, где РК — это обозначение ключевого параметра (Primary Key, первичный ключ).
Рис. 5.3-4. ER-модель БД
Как мы уже обсуждали, процесс проектирования БД представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.
Этап логического проектирования не заканчивается проектированием схемы отношений, а является лишь его первым этапом, где используются способы «хорошего» или «правильного» проектирования реляционных отношений. Будем считать, что проблема логического проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений должна состоять база данных, какие атрибуты должны быть у этих отношений.
Очевидно, что для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Например, можно спроектировать несколько отношений с большим количеством атрибутов или, наоборот, разнести все атрибуты по большому числу мелких отношений. В общем случае проектирование схемы БД может быть выполнено двумя путями:
- • путем декомпозиции (разбиения), когда исходное множество отношений, входящих в схему БД, заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;
- • путем синтеза, т. е. путем компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.
Классическая технология проектирования реляционных БД связана с теорией нормализации, основанной на анализе функциональных зависимостей между атрибутами отношений. Понятие функциональной зависимости является фундаментальным в теории нормализации реляционных БД и определяет устойчивые отношения между объектами и их свойствами в рассматриваемой предметной области.