Проектування БД складається з декількох етапів:
- аналіз предметної області,
- концептуальне проектування,
- логічне проектування,
- фізичне проектування.
Аналіз предметної області потрібно здійснювати в залежності від технічних умов завдання або від наданих множин даних.
Для прикладу, розглянемо предметну область "Бібліотека".
Для спрощення завдання, розглянемо перехід від паперового обліку бібліотечної літератури та читання її читачами до електронної форми. Тобто, переведемо бібліотеку на електронний варіант ведення документації.
Проаналізуємо ті дані, які зберігаються у бібліотеці в паперовому вигляді. Інформація про книжки, журнали, газети і т.п.. Таким чином ми виділяємо множину "Література". Кожна бібліотека створена для того, щоб надати можливість відвідувачам (читачам) отримати доступ до літератури. Отже, виділяємо ще одну множину – "Читачі". Зрозуміло, що читачі читають літературу і цей процес повинен бути зафіксований в обліку, тому утворюємо нову множину даних "Облік читання". Дана структура БД є дуже грубою, тому що потрібно враховувати типи, жанри, видання, авторів та інші підмножини даних.
На основі цього поверхневого аналізу даних отримуємо наступну структуру БД:
| Проектування бази даних СКБД MS Access 2010 | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Створення БД (створення таблиць, встановлення зв'язків та введення даних)
Визначені множини даних пов’язані між собою, їх відношення в реляційній моделі даних можуть бути:
Якщо проаналізувати зв’язок множин "Література" та "Облік читання" очевидним є відношення один до багатьох, що можна розуміти так: одну книгу можуть читати багато разів, або багато читачів. Аналогічний зв’язок і між множинами "Читачі" та "Облік читання", один читач може багато разів відвідувати бібліотеку, або читати багато книжок. Виникає питання, яке відношення між множинами "Література" та "Читачі"? В даному випадку відношення між цими множинами, розглядається з обох боків: одну книгу може брати багато читачів та один читач може читати багато книжок. Таким чином відношення: багато до багатьох.
Насправді система керування базами даних (СКБД) не може аналізувати назви наших множин та з цих назв самостійно складати відношення. Відношення автоматично визначаються при встановленні зв’язків між множинами (таблицями). Напрклад, в СКБД Microsoft Access при встановлені зв’язків у схемі даних ми перетягуємо маніпулятором поля з одної таблицю в іншу. Для створення зв’язку СКБД аналізує такі факти:
Якщо зв’язок допустимий, тобто поля однотипні, СКБД визначає тип відношення. Ключове поле з не ключовим – відношення один до багатьох, ключове з ключовим – один до одного, не ключове з не ключовим – невизначене відношення. Але іноді в таблиці ключових полів може бути декілька, тоді це означає що дані в одному з ключових полів можуть повторюватися, а ось одночасно у всіх ключових полях повтори не допускаються. В такому випадку зв’язок з одним з таких ключових полів розглядається як з не ключовим полем і відповідно тип відношення визначається або один до багатьох або невизначений.
Повернемося до нашої предметної області та визначимо структуру таблиць:
Таблиця "Література"
Таблиця "Облік читання"
Таблиця "Читачі"
Наведемо приклад загальної облікової таблиці з даними. З цієї таблиці дані потрібно буде розподілити по трьом таблицям. Здебільшого з таких таблиць і починають розподіл структур даних.
З загальної таблиці обліку видно, що деякі читачі відвідували бібліотеку декілька разів та деякі книги читалися кількома читачами. Але це не означає, що читачів потрібно заповнювати стільки разів, скільки книг вони читали, а достатньо внести їх в БД один раз, а запис із вказівкою на читача про читання кожної книги повинен весь час додаватися. Із загальної таблиці обліку читання видно, що читачів в БД 5 чоловік, а найменувань книжок 7. Таким чином при заповненні БД у таблиці "Література" утворюємо 6 записів, у таблиці "Читачі" 5 записів, а у таблиці "Облік читання" 11 записів.
Заповнена таблиця "Література"
|
Заповнена таблиця "Читачі"
| № чит квитка | дата запису | ПІБ | стать | дата нар | адреса | телефон | місце роботинавчання | посада |
| 1 | 10.01.2014 | Андрушко І.К. | ж | 11.04.1989 | Озерна | 0972084538 | ТОВ "Крок" | інженер |
| 2 | 12.01.2014 | Багрі́й С.О. | ж | 04.05.2000 | Ракове | 0673671827 | НВК10 | |
| 3 | 13.01.2014 | Білик В.А. | ж | 21.07.1999 | Дубове | 0689297756 | СЗОШ21 | |
| 4 | 22.02.2014 | Шпичко В.В. | ч | 27.11.1996 | Лезніво | 0972959482 | гімназія №2 | |
| 5 | 27.02.2014 | Кордиш О.М. | ч | 30.03.1996 | Виставка | 0675482267 | гімназія №2 |
Заповнена таблиця "Облік читання"
| № чит квитка | код літератури | дата видачі | дата повернення | строк | примітка |
| 1 | 1 | 10.01.2014 | 18.01.2014 | 10 | |
| 2 | 2 | 12.01.2014 | 15.01.2014 | 7 | |
| 3 | 3 | 13.01.2014 | 15.01.2014 | 2 | |
| 4 | 4 | 22.02.2014 | 05.03.2014 | 10 | |
| 5 | 5 | 27.02.2014 | 10.03.2014 | 12 | |
| 2 | 1 | 03.03.2014 | 12.03.2014 | 5 | пеня |
| 3 | 5 | 08.03.2014 | 15.03.2014 | 10 | |
| 4 | 6 | 11.03.2014 | 12.03.2014 | 1 | |
| 1 | 7 | 11.03.2014 | 17.03.2014 | 5 | пеня |
| 5 | 1 | 11.03.2014 | 13.03.2014 | 3 | |
| 2 | 5 | 15.03.2014 | 24.03.2014 | 7 | пеня |
Немає коментарів:
Дописати коментар