ПРИЛОЖЕНИЕ А. Логическая модель БД «БИБЛИОТЕКА»

Здесь представлены результаты логического моделирования учебной БД «БИБЛИОТЕКА». Диаграмма связей между отношениями необходима для понимания структуры реляционной базы данных. В ней отношения представлены только ключевыми атрибутами, которые используются для связей между ними. Спецификация отношений позволяет получить представление о свойствах сущностей, которые учувствуют в процессе учёта выдачи и приёма книг в библиотеке. Логическая модель является исходной точкой для физического моделирования БД «БИБЛИОТЕКА». Его результаты представлены в приложении Б.

Вы должны понимать, что представленная Вам логическая модель БД «БИБЛИОТЕКА» не совершенна. Логику процесса учёта выдачи и приёма книг в библиотеке можно описать по-разному. Она зависит от множества факторов, приводить перечень которых здесь не имеет смысла. Попробуйте сделать свой вариант модели. Перед этим определитесь с назначением реляционной базы данных, которую Вы создадите на базе своей логической модели.

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

Диаграмма связей даёт представление о структуре данных БД «БИБЛИОТЕКА» (рис. А.1). Поэтому в ней отображаются только ключевые атрибуты каждого отношения, которые участвуют в обеспечении ссылочной целостности базы данных «БИБЛИОТЕКА». Остальные атрибуты, включая ключевые, описываются отдельно для каждого отношения. Список всех отношений БД «БИБЛИОТЕКА» вы найдёте в самом начале приложения Б.

Рис. А.1. Диаграмма связей между отношениями БД «БИБЛИОТЕКА»

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

Описание отношения «ЧИТАТЕЛИ» входит в первую часть логической модели. Она посвящена организации хранения информации о библиотекарях и читателях. Вместе с отношением «ЧИТАТЕЛИ» в первую часть логической модели входят отношения «БИБЛИОТЕКАРИ», «ПАСПОРТНЫЕ ДАННЫЕ», «ТЕЛЕФОНЫ» и «ТИПЫ ТЕЛЕФОНОВ».

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

ЧИТАТЕЛИ(Код, Фамилия, Имя, Отчество, № читательского билета, Код паспорта, Место основной работы, Должность, Примечание)

Первичный ключ: Код

Потенциальный ключ: № читательского билета

Потенциальный ключ: Код паспорта

Внешний ключ: Код паспорта

Итак, потенциальными ключами отношения являются следующие его атрибуты: «Код», «№ читательского билета», «Код паспорта». Каждый из них в отдельности может служить для обеспечения целостности сущностей в отношении «ЧИТАТЕЛЬ». Однако, в качестве первичного ключа выбран атрибут «Код». Он специально добавлен в отношение. Его формат будет неизменен на протяжении всего жизненного цикла БД. Он определяется разработчиком. Это важно для обеспечения ссылочной целостности БД. Формат остальных потенциальных ключей не зависит от разработчика.

Атрибут «Код паспорта» является одновременно потенциальным и внешним ключом. Он обеспечивает связь 1:1 (один к одному) между отношениями «ЧИТАТЕЛИ» и «ПАСПОРТНЫЕ ДАННЫЕ». Это значит, что одному кортежу в отношении «ЧИТАТЕЛИ» всегда соответствует один кортеж в отношении «ПАСПОРТНЫЕ ДАННЫЕ».

Отношение «БИБЛИОТЕКАРИ» предназначено для хранения информации о библиотекарях, которые зарегистрированы в БД «БИБЛИОТЕКА». Список его атрибутов – это результат логического моделирования БД «БИБЛИОТЕКА». Названия атрибутов были выбраны таким образом, чтобы было понятно их назначение.

БИБЛИОТЕКАРИ(Код, Табельный номер, Фамилия, Имя, Отчество, Код паспорта, Должность, Домашний телефон, Примечания)

Первичный ключ: Код

Потенциальный ключ: Табельный номер

Потенциальный ключ: Код паспорта

Внешний ключ: Код паспорта

Обратим внимание на ключевые атрибуты: «Код», «Табельный номер», «Код паспорта». Все они являются потенциальными ключами. Атрибут «Табельный номер» используется для идентификации внутри организации. В нашем случае это библиотека. «Код паспорта» идентифицирует работника библиотеки по его паспортным данным. Это требование законодательства страны. Тем не менее в ходе логического проектирования в качестве первичного ключа выбран атрибут «Код». В логике процесса учёта книг он не играет никакой роли. Он специально добавлен в отношение "БИБЛИОТЕКАРИ". Если этого не сделать, то ссылочная целостность БД «БИБЛИОТЕКА» будет зависеть от формата значений потенциального ключа (например, «Табельный номер»). Если оставить эту зависимость, то изменение формата значения первичного ключа приведёт к необходимости создания механизмов поддержки ссылочной целостности для старого и нового варианта его значений. Мы уже сталкивались с этой проблемой для отношения "ЧИТАТЕЛИ".

Атрибут «Код паспорта» является одновременно потенциальным и внешним ключом. Он служит для обеспечения ссылочной целостности между отношением «БИБЛИОТЕКАРИ» и отношением «ПАСПОРТНЫЕ ДАННЫЕ». Любому кортежу в отношении «БИБЛИОТЕКАРИ» всегда соответствует только один кортеж в отношении «ПАСПОРТНЫЕ ДАННЫЕ». Такая связь между отношениями называется 1:1 (один к одному).

Между отношениями «ЧИТАТЕЛИ» и «БИБЛИОТЕКАРИ» много общего. Во-первых, в обоих отношениях ведется учет людей, которым необходимо иметь удостоверение личности. Во-вторых, обе группы людей вовлечены в процесс выдачи и получения книг в библиотеке. В-третьих, один и тот же человек может быть одновременно и читателем, и библиотекарем. Ведь никто не запрещает работникам библиотеки читать книги из ее собраний. Для такого случая необходимо наличие как атрибутов читателя («№ читательского билета», «Код паспорта», «Место основной работы», «Должность», «Примечания») так и атрибутов библиотекаря («Табельный номер» «Код паспорта», «Должность», «Домашний телефон», «Примечания»). Причём, значения атрибутов «Код паспорта» и «Должность» в отношении «ЧИТАТЕЛИ» и «БИБЛИОТЕКАРИ» для такого человека должны быть одинаковыми.

Вернемся к несовершенству логической модели БД «БИБЛИОТЕКА». Об этом мы уже говорили. А теперь мы хотели бы обратить Ваше внимание на то, что отношения «ЧИТАТЕЛИ» и «БИБЛИОТЕКИ» содержат атрибуты «Фамилия», «Имя» и «Отчество». Для человека, который одновременно является библиотекарем и читателем, значения этих атрибутов должны быть одинаковыми в обоих отношениях. Есть простой способ сделать это. В нашем случае имеет смысл определить эти атрибуты в отношении «ПАСПОРТНЫЕ ДАННЫЕ». Затем их необходимо удалить из отношений "ЧИТАТЕЛИ" и "БИБЛИОТЕКАРИ". Это дает возможность вводить значения в атрибуты «Фамилия», «Имя» и «Отчество» в одном месте для каждого человека и исключает дублирование этой информации. Кроме того, уменьшается размер базы данных «БИБЛИОТЕКА». А какие улучшения логической модели БД «БИБЛИОТЕКА» вы можете предложить?

В этом отношении хранятся паспортные данные всех людей, которые были зарегистрированы в базе данных «БИБЛИОТЕКА». Другую информацию об этих людях вы можете найти в отношениях «ЧИТАТЕЛИ» и «БИБЛИОТЕКАРИ». С каждым из них отношение «ПАСПОРТНЫЕ ДАННЫЕ» имеет связь 1:1 (один к одному). Перейдите к описанию этих отношений. Там есть соответствующие пояснения.

ПАСПОРТНЫЕ ДАННЫЕ(Код, Серия паспорта, № паспорта, Дата рождения, Место рождения, Пол, Место выдачи паспорта, Дата выдачи паспорта, Примечания)

Первичный ключ: Код

Потенциальный ключ: Серия паспорта, № паспорта

Рассмотрим ключевые атрибуты отношения «ПАСПОРТНЫЕ ДАННЫЕ». У отношения нет внешних ключей. Есть составной потенциальный ключ. Обратите внимание, что впервые в логической БД «БИБЛИОТЕКА» мы имеем дело с составным потенциальным ключом. Он включает в себя атрибуты «Серия паспорта» и «№ паспорта». Мы можем идентифицировать паспорт любого человека по значениям этих двух атрибутов. Речь идет об Украине. В других странах идентификационная карта может содержать другую информацию. Поэтому в отношение был добавлен специальный ключевой атрибут «Код». Он выбран в качестве первичного ключа. Это дает возможность уйти от какой-либо зависимости от законодательства для обеспечения ссылочной целостности базы данных «БИБЛИОТЕКА».

Не забывайте, что база данных «БИБЛИОТЕКА» была создана для изучения организации реляционных баз данных. Поэтому Вам предложили два подхода к хранению информации о контактах людей. Неважно, какие контакты. Это могут быть номера телефонов, почтовые адреса, адреса электронной почты и многое другое. Для базы данных «БИБЛИОТЕКА» мы выбрали наиболее понятный для широкой аудитории вид контактов – телефоны.

Оба подхода основаны на требованиях пользователей. Если вы договорились с пользователями, что для связи с человеком достаточно одного номера телефона, то воспользуйтесь самым простым вариантом. Для этого в отношение «БИБЛИОТЕКАРИ» добавлен атрибут «Домашний телефон». Если при ведении базы данных выяснилось, что одного контакта недостаточно для одного человека, то Вам нужен второй вариант. Этот вариант предназначен для лиц, зарегистрированных в качестве читателей в базе данных «БИБЛИОТЕКА». Он реализован в трех отношениях: «ЧИТАТЕЛИ», «ТЕЛЕФОНЫ» и «ТИПЫ ТЕЛЕФОНОВ».

ТЕЛЕФОНЫ(Код читателя, Код типа телефона, № телефона)

Потенциальный ключ: Код читателя, № телефона

Внешний ключ: Код читателя

Внешний ключ: Код типа телефона

Спецификация отношения «ТЕЛЕФОНЫ» является результатом нормализации отношений БД «БИБЛИОТЕКА». Более подробно об этом будет написано в методических указаниях для практических работ «Доработка логической модели и нормализация отношений». Потенциальный ключ отношения «ТЕЛЕФОНЫ» состоит из двух атрибутов: «Код читателя» и «№ телефона». Этому есть логическое объяснение.

Рассмотрим атрибут «Код читателя». Он не может использоваться в качестве потенциального ключа. Ведь мы рассматриваем вариант, когда для одного человека можно указать более одного контакта. В нашем случаи это номера телефонов. Поэтому, в отношении «ТЕЛЕФОНЫ» могут быть добавлены несколько кортежей с одинаковыми значениями атрибута «Код читателя». Это противоречит определению потенциального ключа.

Рассмотрим атрибут «№ телефона». Итак, похоже, мы нашли потенциальный ключ! Ведь мы не найдем в мире двух одинаковых телефонных номеров. Но тогда ответьте на вопрос: могут ли два читателя быть из одной семьи? Мы считаем, что могут. Они оба могут зарегистрировать телефонный номер, установленный в их доме. Это означает, что по крайней мере два кортежа отношения «ТЕЛЕФОНЫ» могут содержать один и тот же номер. Поэтому атрибут «№ телефона» не может быть потенциальным ключом.

Есть ли смысл указывать один и тот же номер телефона для одного и того же читателя несколько раз? Думаем, что ответ очевиден: нет. После всех этих рассуждений становится ясно, что пара значений в атрибутах «Код читателя» и «№ телефона» может быть потенциальным ключом отношения «ТЕЛЕФОНЫ». Всегда критически относитесь к своим логическим выводам. Это поможет вам стать лучшим в том, чем вы занимаетесь.

Отношение «ТИПЫ ТЕЛЕФОНОВ» содержит информацию о типах телефонов читателей. Оно завершает первую часть логической модели БД «БИБЛИОТЕКА». Напомним, что первая часть содержит информацию обо всех читателях и библиотекарях.

ТИПЫ ТЕЛЕФОНОВ(Код, Наименование)

Первичный ключ: Код

Потенциальный ключ: Наименование

Отношение имеет всего два атрибута. Каждый из них является потенциальным ключом. Атрибут «Код» был специально добавлен в отношение «ТИПЫ ТЕЛЕФОНОВ». Эта методика была объяснена ранее. Атрибут «Код» необходим для обеспечения независимости ссылочной целостности базы данных от внешних факторов (см. отношения "ЧИТАТЕЛИ", "БИБЛИОТЕКАРИ" и другие). С одной стороны, такой подход усложняет отношение «ТИПЫ ТЕЛЕФОНОВ» и базу данных «БИБЛИОТЕКА». Однако, с другой стороны, он уменьшает объем памяти, который база данных будет занимать на диске. Мы легко можем это доказать.

Предположим, что для атрибута «Имя» отношения «ТИПЫ ТЕЛЕФОНОВ» выделено двадцать символов. Количество байтов на символ зависит от кодировки множества символов алфавита. В лучшем случае один символ — это один байт. Следовательно, для каждого значения внешнего ключа «Тип телефона» в отношении «ТЕЛЕФОНЫ» должно быть зарезервировано минимум двадцать байт.

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

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

КНИГИ(Код, Название, Год издания, Тираж, Издательство, Универсальный десятичный классификатор, Шифр, Примечания)

Первичный ключ: Код

Потенциальный ключ: Название, Издательство, Год издания

Обратите внимание на ключевые атрибуты отношения «КНИГИ». У него есть два потенциальных ключа. Потенциальный «Код» был выбран в качестве первичного ключа. Этот подход описан для отношений «ЧИТАТЕЛИ», «БИБЛИОТЕКАРИ», «ПАСПОРТНЫЕ ДАННЫЕ» и других, которые представлены в базе данных «БИБЛИОТЕКА». Второй потенциальный ключ - составной. Он включает атрибуты «Название», «Издательство» и «Год издания». Ни один из этих атрибутов сам по себе не может однозначно идентифицировать книгу. Даже любая пара этих атрибутов, которая была включена в потенциальный ключ, не гарантирует целостности сущностей в отношении «КНИГИ». Однако значения всех трех атрибутов однозначно идентифицируют кортеж отношения, в котором хранится информация об отдельной книге. Эти утверждения основаны на информации, полученной от людей в организации, для которой вы выполняете логическое моделирование реляционной базы данных. Не забывайте, что база данных «БИБЛИОТЕКА» является учебной.

В отношении хранятся сведения об авторах книг. Рассмотрим его спецификацию.

АВТОРЫ КНИГ(Код, Фамилия, Имя, Отчество, Дата рождения, Дата смерти, Краткая биография, Примечания)

Первичный ключ: Код

Обратите внимание на ключевой атрибут «Код» отношения «АВТОРЫ КНИГ». В отношения «ЧИТАТЕЛИ», «БИБЛИОТЕКАРИ», «ПАСПОРТНЫЕ ДАННЫЕ» и «КНИГИ» он был добавлен для независимости ссылочной целостности базы данных «БИБЛИОТЕКА» от внешних факторов. В отношение «ТИПЫ ТЕЛЕФОНОВ» он был добавлен, чтобы уменьшить объём памяти, занимаемой базой данных «БИБЛИОТЕКА». Причина добавления атрибута «Код» в отношение «АВТОРЫ КНИГ» не совпадает ни с одной из приведенных выше.

Чтобы понять это, попробуйте самостоятельно найти потенциальные ключи отношения «АВТОРЫ КНИГ». Вы увидите, что ни один атрибут отношения не может однозначно идентифицировать его кортеж. Атрибуты «Краткая биография» и «Примечания» проблематично использовать как часть потенциального ключ. Это текстовые атрибуты. Их размер не позволит идентифицировать кортежи отношения в разумные сроки. Кроме того, размер специальных файлов, в которых хранятся значения потенциальных ключей, будет слишком большим.

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

Следовательно, в отношении «АВТОРЫ КНИГ» нет атрибутов или их набора, которые могли бы сформировать потенциальный ключ. Это причина добавить атрибут «Код» в качестве ключа-кандидата, а затем выбрать его в качестве первичного ключа.

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

СОАВТОРСТВО(Код книги, Код автора)

Потенциальный ключ: Код книги, Код автора

Внешний ключ: Код книги

Внешний ключ: Код автора

Зачем так сложно связать отношения «КНИГИ» и «АВТОРЫ КНИГ» друг с другом? Все дело в устранении связи N:M (многие ко многим) между этими отношениями. Один автор может написать несколько книг. С другой стороны, у одной книги может быть несколько авторов. Это означает, что несколько кортежей в отношении «КНИГИ» могут соответствовать нескольким кортежам в отношении «АВТОРЫ». В реляционной модели данных нет механизмов, которые могли бы реализовать такой случай.

Однако, любую связь N:M между отношениями можно реализовать с помощью двух связей 1:M и промежуточного отношения. Отношение «СОАВТОРСТВО» имеет структуру именно такого отношения. Оно является промежуточным между отношениями «КНИГИ» и «АВТОРЫ» и состоит из двух атрибутов, каждый из которых является внешним ключом. Атрибут «Код книги» поддерживает связь 1:M между отношениями «КНИГИ» и «СОАВТОРСТВО». Атрибут «Код автора» поддерживает связь 1:M между отношениями «АВТОРЫ» и «СОАВТОРСТВО». Потенциальный ключ отношения «СОАВТОРСТВО» состоит из всех его атрибутов.

Отношение содержит список наименований всех библиотечных фондов, в которые входят книги. Его структура точно такая же, как и у отношения «ТИПЫ ТЕЛЕФОНОВ». Там вы найдёте исчерпывающую информацию о логике создания подобных отношений в реляционных базах данных. Поэтому, мы приводим только его спецификацию.

ТИПЫ ФОНДОВ КНИГ(Код, Наименование)

Первичный ключ: Код

Потенциальный ключ: Наименование

Это отношение завершает описание второй части логической модели БД «БИБЛИОТЕКА». Оно содержит информацию о каждом экземпляре книги в библиотеке.

ИНВЕНТАРНЫЕ НОМЕРА КНИГ(Код, Код книги, Код фонда, Инвентарный номер, Стоимость)

Первичный ключ: Код

Потенциальный ключ: Инвентарный номер

Внешний ключ: Код книги

Внешний ключ: Код фонда

У каждого экземпляра книги есть свой уникальный инвентарный номер. Атрибут «Инвентарный номер» содержит его значение. Это потенциальный ключ отношения. Однако в отношение был введен специальный атрибут «Код». Он выбран в качестве первичного ключа для поддержания ссылочной целостности с отношением «УЧЁТ ВЫДАЧИ КНИГ». Это сделано для независимости ссылочной целостности базы данных «БИБЛИОТЕКА» от внешних факторов (см. отношения «ЧИТАТЕЛИ», «БИБЛИОТЕКАРИ», «ПАСПОРТНЫЕ ДАННЫЕ» и «КНИГИ»).

Между отношениями «ИНВЕНТАРНЫЕ НОМЕРА КНИГ» и «УЧЁТ ВЫДАЧИ КНИГ» поддерживается связь типа 1:M (один ко многим). Между отношениями «КНИГИ» и «ТИПЫ ФОНДОВ КНИГ» поддерживаются связь М:1 (много к одному). Это значит, что у одной книги может быть несколько экземпляров в разных библиотечных фондах. Для большей наглядности смотрите диаграмму связей между отношениями БД «БИБЛИОТЕКА» (Рис. А.1).

В отношении «УЧЁТ ВЫДАЧИ КНИГ» сливаются в единое целое две части логической модели. Первая посвящена людям, а вторая – книгам. На нём заканчивается описание логической модели учебной БД «БИБЛИОТЕКА».

УЧЕТ ВЫДАЧИ КНИГ(Код, Код читателя, Код библиотекаря, выдавшего книгу, Код инвентарного номера книги, Дата выдачи книги, Дата возврата книги, Дата фактического возврата книги, Код библиотекаря, принявшего книгу)

Потенциальный ключ: Код инвентарного номера книги, Код читателя, Дата выдачи книги

Внешний ключ: Код читателя

Внешний ключ: Код библиотекаря, выдавшего книгу

Внешний ключ: Код библиотекаря, принявшего книгу

Внешний ключ: Код инвентарного номера книги

Начнем с потенциального ключа. В его состав входит три атрибута: «Код инвентарного номера книги», «Код читателя», «Дата выдачи книги». Почему их достаточно, чтобы определить кортеж отношения? Давайте рассуждать. Один читатель может взять несколько книг. Это означает, что одно и то же значение кода читателя может присутствовать в нескольких кортежах отношения. Этого недостаточно для однозначной идентификации кортежа отношения. Одну книгу можно брать несколько раз. Это случай один к одному похож на случай с атрибутом «Код читателя». Возьмем пару атрибутов «Код читателя» и «Код инвентарного номера книги». Мы нашли потенциальный ключ? Но кто мешает читателю взять один и тот же экземпляр книги в библиотеке несколько раз? Особенно, если эта книга ему понравилась.

Добавим к этим атрибутам дату выдачи книги. И сразу зададим вопрос: может ли один и тот же читатель взять в библиотеке один и тот же экземпляр книги в течение суток несколько раз? Конечно может! Сперва читатель взял книгу сразу после открытия библиотеки. Затем после прочтения сдал её до обеда. Потом он вспомнил, что ему необходимо что-то уточнить, и снова взял этот экземпляр книги перед закрытием библиотеки. Так что, потенциальный ключ в спецификации отношения «УЧЁТ ВЫДАЧИ КНИГ» указан не верно?

Все зависит от типа данных атрибута «Дата выдачи книги» в физической модели БД «БИБЛИОТЕКА». Мы уже второй раз обращаем Ваше внимание на тесную связь между физическим и логическим моделированием реляционной базы данных. Первый случай был описан для отношения «ТИПЫ ТЕЛЕФОНОВ».

Тип данных атрибута «Дата выдачи книги» должен фиксировать момент выдачи книги с точностью до секунды. Это позволит потенциальному ключу, состоящему из атрибутов «Инвентарный номер книги», «Код читателя», «Дата выдачи книги», однозначно идентифицировать кортеж отношения «УЧЁТ ВЫДАЧИ КНИГ». Рассуждая таким образом, Вы можете найти ещё потенциальные ключи в этом отношении. Они специально не указаны в его спецификации.

Рассмотрим внешние ключи отношения «УЧЁТ ВЫДАЧИ КНИГ». Каждый из них состоит всего из одного атрибута и определяет связь типа M:1 (многие к одному) отношения «УЧЁТ ВЫДАЧИ КНИГ» с тремя другими отношениями базы данных «БИБЛИОТЕКА»: «ЧИТАТЕЛИ», «БИБЛИОТЕКАРИ» и «ИНВЕНТАРНЫЕ НОМЕРА КНИГ». Более того, с отношением «БИБЛИОТЕКАРИ» есть две связи M:1 (многие к одному). Нам нужно знать не только библиотекаря, выдавшего книгу, но и библиотекаря, который ее принял.

На этом описание логической модели будем считать законченным.