це - атрибути третьої сутності Нашої діаграмі. Тут у нас зберігається інформація про наших чітачів, Які беруть книги в Бібліотеці. Зв'язок встановл з сутністю Картки чітачів зв язком типом одна до багатьох raquo ;. Мі беремо атрибут ID читача та вікорістовуємо его, з можлівістю повторювання значень в сутності Картки чітачів raquo ;. Таким чином ми візначаємо чітачів, Які взяли ту чі іншу книгу (книги) в Бібліотеці в сутності Картки чітачів raquo ;.
Четверта Сутність це - Картки чітачів raquo ;. Атрибутами цієї сутності це - Дата видачі и Дата повернення raquo ;. Помощью зв язків в Цій сутності, м галі отрімуємо атрибути Номер зберігання и ID читача raquo ;, про что Було Вже сказано вищє, коли ми розбіралі попередні сутності діаграмі.
Повна ER-Діаграма представлена ??у Додатках А.
3. Розробка бази даних
.1 Качан проектування
При проектуванні бази даних Бібліотека я вікорістовував СУБД Microsoft Access +2010, что Визначи Завдання. Саме +2010 версию, того что вона найбільш сучасна з версій, Які підтрімують создания кнопочної форми, якові необходимо создать у відповідності з поставленими Завдання.
вказано вищє СУБД підтрімує інструкції SQL, Які Було очень Зручне використовуват при створенні відповідніх до Завдання Запитів бази даних. Помощью цієї мови структурованіх Запитів Було мною розроблено п ять Запитів, два з якіх Працюють для оновлення та редагування даних в базі даних. Такоже, мною БУВ Створений макрос, Який запускає послідовно необхідні запиті, щоб можна Було оновити інформацію про наявність книг в Бібліотеці в табліці Книги відповідно до оновленої информации в табліці Картки чітачів raquo ;. При чому запит враховує всю наявний інформацію про книги. Тобто, даже, если дата повернення книги Вже пройшла, но вказано, что книгу Було повернемося, то інформація буде оновлена ??правильно. А если ще проходити період з відачі книги до ее повернення, то если вказано, что книга повернемося, все одне запісується Вірна інформація, Аджея Дійсно вона Вже в Бібліотеці, читач повернувши ее Ранее крайньому терміну.
3.2 Розробка схеми даних
Схема даних це - один Із найважлівішіх елементів в базі даних. Помощью схеми даних укладаються зв язки между атрибутами таблиць, что грає очень Важлива роль при проектуванні будь-якої бази даних. Наша схема даних створювалася на Основі розробленої Ранее ER-діаграмі. Відповідно до неї и були влаштовані зв язки между таблиці.
Перший зв'язок между таблицю Жанр та Книги raquo ;, а точніше їх атрібутів ID жанру та Жанр raquo ;, зображено на рис.3, что наведень нижчих.
Малюнок 3 - Зв'язок ID жанру
Зв'язок встановл одна до багатьох raquo ;, як и Було вказано в ER-діаграмі.
Важлива розуміті, что в табліці Книги вікорістовується не просто Ідентифікатор жанру, но підставляється відповідна Йому назва жанру. Таким чином, ми НЕ дублюємо інформацію про жанри, яка Вже є в табліці Жанри raquo ;, а просто підставляємо ее в таблицю Книги у відповідності з книгами. При чому, є ще один перевага такого підходу проектування, если ми захочемо Сменить Назву одного з жанрів, например Художня література на Українська художня література raquo ;, то нам достаточно лишь Сменить его в табліці Жанри raquo ;, а в табліці Книги ЦІ назви автоматично зміняться всі Самі.
Інший зв язок в схемі даних, це зв язок Номер зберігання таблиць Книги та Картки чітачів raquo ;. Цей зв'язок одна до одного raquo ;, что добро видно на малюнку 4, Який наведено нижчих.
Малюнок 4 - Зв'язок Номер зберігання
Одному номеру зберігання з табліці книги відповідає один єдина книга в Бібліотеці, чі якесь інше видання, що не обов язково самє книга. Цьом ж номеру может ВІДПОВІДАТИ єдиний записів у табліці Карті чітачів raquo ;, если читач візьме более однієї книги, то запісів буде более, но на один записі, только один номер зберігання.
Між таблицями читачі та Карті чітачів встановлений зв'язок одна до одного raquo ;. Мі беремо Код читача в табліці читачі та підставляємо его в атрибут Читач табліці Карті чітачів raquo ;, Однак в параметрах підстановкі зроблені умови, Які вместо кодом відображають нам ім я читача для зручності и зрозумілості даних. До речі, я не сказавши цього Ранее, альо Це дуже Важлива - Завдяк такого підходу ми при складанні форм в Майбутнього НЕ отрімаємо проблем з відображенням имени чітачів, а їх кодів, Які зовсім НЕ інформатівні.
Зв'язок згаданій вищє зображено на малю...
