ДОДАТОК А. Логічна модель БД «БІБЛІОТЕКА»

Тут представлені результати логічного моделювання навчальної БД «БІБЛІОТЕКА». Діаграма зв'язків між відношеннями необхідна для розуміння структури реляційної бази даних. У ній відношення представлені тільки ключовими атрибутами, які використовуються для зв'язків між ними. Специфікація відношень дозволяє отримати уявлення про властивості сутностей, які приймають участь в процесі обліку видачі і прийому книжок в бібліотеці. Логічна модель є вихідною точкою для фізичного моделювання БД «БІБЛІОТЕКА». Його результати представлені у додатку Б.

Ви повинні розуміти, що представлена Вам логічна модель БД «БІБЛІОТЕКА» не досконала. Логіку процесу обліку видачі і прийому книжок в бібліотеці можна описати по-різному. Вона залежить від безлічі факторів, наводити перелік яких тут не має сенсу. Спробуйте зробити свій варіант моделі. Перед цим требо визначитись з призначенням реляційної бази даних, яку Ви створите на базі своєї логічної моделі.

На нашу думку, процес навчання вимагає наступної послідовності викладання логічної моделі. Діаграма зв'язків між відношеннями приведена на початку (рис. А.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 (багато до одного). Нам потрібно знати не тільки бібліотекара, який видав книгу, але й бібліотекара, який її прийняв.

На цьому опис логічної моделі будемо вважати завершеним.