Основи проектування баз даних




Сторінка4/5
Дата конвертації18.12.2016
Розмір7.52 Kb.
1   2   3   4   5
та Оцінка.
У табл. 3.17 первинним ключем є складений ключ, той, що був у початковій таблиці. Атрибут Оцінка є описовим, який функціонально залежний від ключа у цілому
Табл. 3.16. Перша таблиця відношення СЕСІЯ для переходу до 2NF
Прізвище,
ініціали
Спеціальність
Номер групи
Номер у списку
Котляр І.І.
ЛА
61 15
Котляр І.І.
ЛА
61 15
Котляр І.І.
ЛА
61 15
Бовкун П.П.
ЛЕ
71 3

84
Табл. 3.17. Друга таблиця відношення СЕСІЯ для переходу до 2NF
Спеціальність
Номер групи
Номер у списку
Дисципліна
Оцінка
ЛА
61 15
Інформатика відмінно
ЛА
61 15
Вища математика добре
ЛА
61 15
Фізика добре
ЛЕ
71 3
Інформатика добре
Цей набір відношень (таблиць) не містить неповних функціональних залежностей, тому можна сказати, що кожне відношення знаходиться в другій нормальній формі.
Третя нормальна форма. Відношення знаходиться у ЗNF, якщо виконуються обмеження 2NF і всі описові атрибути відношення взаємно незалежні і повністю залежать від первинного ключа, тобто кожний описовий атрибут не транзитивно залежить від ключа.
У більшості випадків третя нормальна форма є компромісом між повною нормалізацією і функціональністю в сукупності з легкістю реалізації. Існують нормальні форми вище ЗNF, але на практиці вони ускладнюють розробку структур даних і знижують їх функціональність.
Наведемо складніший приклад нормалізації відношень, для чого розглянемо предметну область ЛІТЕРАТУРНІ ДЖЕРЕЛА З БАЗ
ДАНИХ.
Один автор може написати декілька книг, що вийшли в різних видавництвах. Кожна книга, що вийшла у видавництві, має певного автора.
У БД повинні бути наступні дані: прізвище та ініціали автора книги, назва книги, шифр УДК, видавництво, що опублікувало книгу, рік видання
і кількість сторінок.
У табл. 3.18 та 3.19 наведено дані для створення БД у початковому виді, коли до розгляду запропоновано інформаційні об’єкти АВТОР і
ВИДАВНИЦТВО.

85
Таблиця 3.18. Інформація про авторів видань у початковому виді
АВТОР
ПІП/б
Назва книги
Кількість
сторінок
Рік
видання
Хомоненко А.Д.
Базы данных
Базы данных
Основы современных компьютерных технологий
Работа с базами данных в Delphi
Работа с базами данных в Delphi
416 672 730

656 640 2000 2002 2005

2001 2005
Фуфаев Э.В.
Базы данных
320 2005
Заверач М.М.
Бази даних. Інформа- ційні системи
303 2007
Карпова Т.С.
Базы данных: Модели, разработка, реализация
304 2002
Таблиця 3.19. Інформація про видавництва у початковому виді
ВИДАВНИЦТВО
Назва
Адреса
Назва книги
Автор книги
Рік
вид.
Кільк
стор.
Шифр
УДК
Корона принт
Санкт-
Петербург,
Мойка., д.2
Базы данных
Базы данных
Хомонен- ко А.Д.
Хомонен- ко А.Д.
2000

2002 416

672 681.5

681.5
БХВ-
Петербург
Санкт-
Петербург,
Морской просп., д.4
Работа с базами данных в Delphi
Работа с базами данных в Delphi
Хомонен- ко А.Д.
Хомонен- ко А.Д.
2001 2005 656 640 678.9 678.9
Академия
Москва, ул.
Правды, д.24
Базы данных
Фуфаев Э.В. 2005 320 681.5
Вид-во
Хмельни- цького нац. ун-ту (ХНУ)
Хмельницький, ул.
М.Кривоноса, б.7
Бази даних.
Інформаційні системи
Заверач М.М. 2007 303 685.2
Питер
Санкт-
Петербург, ул.
Благодатная, д.67
Базы данных:
Модели, разрабо- тка, реализация
Карпова Т.С. 2002

304

681.3


86
Як видно з таблиць, подання даних у них не задовольняє вимог навіть першої нормальній форми. Приведемо їх до (табл.3.20, 3.21).
Таблиця 3.20. Відношення АВТОР у
1NF
АВТОР
Прізвище,
ініціали
Назва книги
Кільк. стор.
Хомоненко А.Д.
Базы данных
416
Хомоненко А.Д.
Базы данных
672
Хомоненко А.Д..
Работа с базами данных в
Delphi
656
Хомоненко А.Д..
Работа с базами данных в
Delphi
640
Фуфаев Э.В.
Базы данных
320
Заверач М.М.
Бази даних. Інформа-ційні системи
303
Карпова Т.С.
Базы данных: Модели, разработка, реализация
304
Таблиця 3.21. Відношення ВИДАВНИЦТВО у
1NF
ВИДАВНИЦТВО
Назва
Місто
Вулиця Буд
Назва
книги
Автор
книги
Рік
вид.
Кільк.
стор.
Шифр

УДК
Корона принт
Санкт-
Петербург
Мойка
2
Базы данных
Хомоненко
А.Д.
2000 416 681.5
Корона принт
Санкт-
Петербург
Мойка
2
Базы данных
Хомоненко
А.Д.
2002 672 681.5
БХВ-
Петербург
Санкт-
Петербург
Морской просп
4
Работа с ба- зами данных в
Delphi
Хомоненко
А.Д.
2001 656 678.9
БХВ-
Петербург
Санкт-
Петербург
Морской просп
4
Работа с ба- зами данных в
Delphi
Хомоненко
А.Д.
2005 640 678.9
Академия
Москва
Правды
24
Базы данных. Фуфаев Э.В. 2005 320 681.5
Вид-во
Хмельни- цького нац. ун-ту
(ХНУ)
Хмель- ницький
М.Криво
-носа
7
Бази даних.
Інформаційні системи
Заверач
М.М.
2007 303 685.2
Питер
Санкт-
Петербург
Благодат
-ная
67
Базы данных:
Модели, разработка, реализация
Карпова
Т.С.
2002 304 681.3


87
Для створення первинних ключів цих відношень уведемо атрибути
Код автора і Код видавництва, наприклад, типу Лічильник.
Оскільки в обох відношеннях первинний ключ не складений, то від
1NF переходимо відразу до 3NF.
У відношенні АВТОР від первинного ключа функціонально залежить тільки атрибут Прізвище, ініціали. Запишемо 3NF для АВТОР (табл.3.22).
Таблиця 3.22. Відношення АВТОР у
3NF
АВТОР
Код автора
Прізвище, ініціали
1
Хомоненко А.Д.
2
Фуфаев Э.В.
3
Заверач М.М.
4
Карпова Т.С.
У відношенні ВИДАВНИЦТВО від Коду видавництва залежать атрибути Назва, Місто, Вулиця, Будинок. Винесемо їх в окреме відношення у 3NF (табл.3.23).
Таблиця 3.23. Відношення ВИДАВНИЦТВО у
3NF
ВИДАВНИЦТВО
Код
видавництва
Назва
Місто
Вулиця
Будинок
1
Корона принт
Москва
Мойка
2 2
БХВ-Петербург
Москва
Морской просп
4 3
Академия
Москва
Правды
24 4
Вид-во
Хмельницького нац. ун-ту (ХНУ)
Хмельницький
М.Кривоноса
7 5
Питер
Санкт-
Петербург
Благодатная
67

88
З першого і другого відношень залишилися не використаними наступні атрибути, що характеризують літературне джерело: Назва книги;
Рік видання; Кількість сторінок; Шифр УДК. Для того, щоб врахувати ці атрибути, створимо додатково інформаційний об’єкт КНИГА, за первинний ключ для нього уведемо атрибут Код книги. Для зв'язку КНИГА з відношеннями АВТОР і ВИДАВНИЦТВО уведемо в нього зовнішні ключі Код автора і Код видавництва. Одержане відношення у 3NF має вигляд (табл.3.24):
Таблиця 3.24. Відношення КНИГА у
3NF
КНИГА
Код
книги
Назва книги
Рік
видання
Кількість
сторінок
Шифр
УДК
Код
автора
Код
вид-ва
1
Базы данных
2000 416 681.5 1
1 2
Базы данных
2002 672 681.5 1
1 3
Базы данных
2005 320 681.5 2
3 4
Работа с базами данных в Delphi
2001 656 678.9 1
2
Работа с базами данных в Delphi
2005 640 678.9 1
2 3
Бази даних. Інформа- ційні системи
2007 303 685.2 3
4 4
Базы данных: Модели, разработка, реализация
2002 304 681.3 4
5
Розглянутий приклад показує, як може змінитися попередня уява про структуру БД при застосуванні процедури нормалізації. Тепер зрозуміло, що нормалізація відношень - не марне витрачання часу. Багаторазове дублювання інформації в базі даних, крім різних аномалій редагування
(аномалія вставки, аномалія редагування, аномалія видалення) призводить до зниження продуктивності СКБД. Кожен елемент даних повинен зберігатися в базі в одному і лише одному екземплярі, що і досягається нормалізацією.

89
3.7. Створення схеми даних
При визначенні логічної структури РБД на основі реляційної моделі даних кожний інформаційний об’єкт (відношення) відображають таблицею, а зв’язки між таблицями відповідають зв’язкам між об’єктами.
Схемою даних називають умовне графічне зображення об’єктних відношень РБД та зв’язків між ними. Створення схеми даних є одним з етапів створення РБД. Вона дозволяє не тільки отримати уяву про структуру БД, але і забезпечує об’єднання відношень при обробці даних і цілісність БД.
Розташування інформації про об’єкт в окремій таблиці і подальше зв’язування цих таблиць запобігає повторенню даних у таблицях і спрощує пошук у БД, забезпечує цілісність взаємопов’язаних даних при їхньому коригуванні. Створення схеми даних спрощує створення багатотабличних об’єктів РБД, таких як запити, форми та звіти.
На схемі даних умовно зображують інформаційні об’єкти і зв’язки між ними. Об’єкт позначають прямокутником, у верхній частині якого вказують його ім’я, нижче

атрибути, причому першим (першими при складеному ключі) подають ключовий атрибут. Прямокутники з’єднують лініями, які позначають зв’язки між сутностями. Лінію починають від ключа головного об’єкта і закінчують на відповідному атрибуті
(атрибутах) підпорядкованого.
При виконанні схеми даних засобами СКБД мова йде про таблиці.
Приклад схеми даних РБД у середовищі MS Access зображено на рис.
3.3.

90

Рис. 3.3. Приклад схеми даних РБД з предметної області
ЛІТЕРАТУРНІ ДЖЕРЕЛА З БАЗ ДАНИХ
3.8. Узагальнений алгоритм проектування реляційної бази даних
Перед створенням бази даних необхідно мати детальний опис предметної області, з якого буде зрозуміло, які в ній діють реальні об'єкти і процеси, і які задачі користувачів треба задовольняти інформацією з цієї бази даних.
Проектування БД передбачає виконання цілої низки кроків, які дозволять перейти від загальної постановки задачі до створення необхідної структури даних. Структуру відображають спочатку інфологічною та даталогічною моделями, а потім тими об’єктами, які передбачені конкретною СКБД, у реляційних – таблицями.
Існують два підходи для дослідження властивостей предметної області. Перший підхід передбачає першочерговим – визначення основних
завдань, для яких власне і створюють БД, а другий – визначення об'єктів
предметної області. Гарні результати дає сполучення зазначених підходів.
Це пояснюється тим, що на початку проектування ще відсутній вичерпний перелік необхідних задач.
Використання такої технології можливе завдяки гнучким засобам сучасних реляційних СКБД, зокрема MS Access, а це дозволяє на будь- якому етапі проектування внести зміни в БД і модифікувати її структуру.

91
Реляційна база даних складається з взаємопов’язаних таблиць.
Структура таблиці визначається сукупністю стовпців (полів), типом і розміром даних кожного стовпця, а також первинним ключем таблиці.
Рядки таблиці однозначно ідентифікуються значенням ключа. Логічні зв'язки між таблицями в реляційній базі даних реалізуються за рахунок однакових полів в зв'язуваних таблицях.
Отже, у результаті проектування має бути визначена логічна структура бази даних, тобто склад реляційних таблиць, їх структура і міжтабличні зв'язки.
Створеною вважають БД, у таблиці якої внесені необхідні дані, з якими працює користувач БД.
Наведемо спрощений алоритм проектування РБД:
1.
визначити мету створення бази даних;
2.
визначити інформаційні об’єкти, які містяться в базі даних;
3.
визначити зв’язки між об’єктами;
4.
визначити основні властивості об’єктів;
5.
визначити зв’язки між властивостями об’єктів;
6.
визначити відношення між таблицями баз даних, базуючись на зв’язках між об’єктами даних, що містяться в таблиці, і включити цю
інформацію до словника даних;
7.
передбачити операції, що треба виконати при створенні та зміні
інформації таблиць, включаючи забезпечення цілісності даних;
8.
визначити користувачів, яким дозволений доступ до даних, їх редагування, а також зміна при необхідності структури таблиць;
Добре ілюструє етапи проектування схема, подана на рис.3.4.

92
Побудова моделі даних ПО
Визначення структури
РБД
Конструювання таблиць засобами
СКБД
Створення схеми даних засобами СКБД
Заповнення даними таблиць БД
Інформаційний об”єкт
Інформаційний об”єкт
Інформаційний об”єкт
Інфологічна модель
Інфологічна модель
Звітні документи предметної області
Проект структури БД
Table
Table
Table
Проект структури БД
Порожні таблиці
Порожні таблиці
Table
Table
Table
Схема даних РБД
Схема даних РБД
Дані
Заповнені таблиці
Проект структури БД
Інформаційний об”єкт
Інформаційний об”єкт
Інформаційний об”єкт
1 2
3 4
5
Рис. 3.4. Схема етапів проектування РБД

93
Розглянемо проектування БД на прикладі предметної області
НАВЧАЛЬНИЙ ПРОЦЕС.
Нехай на поточний момент навчальний процес супроводжують наступні звітні документи:
1)
екзаменаційні і залікові відомості для кожної студентської групи з певної навчальної дисципліни, у відомостях треба вказувати, який викладач приймає ці види семестрової звітності, у табл. 3.25 наведемо приклад відомості.
Таблиця 3.25. Екзаменаційна відомість
2) списки студентських груп, у табл. 3.26 наведемо приклад списку для групи ЛА-01
Таблиця 3.26. Список студентської групи
Гр. ЛА-01
Номер за списком
Відмітка для старости
Прізвище,
ім’я, по - батькові
Дата народження
Адреса
Телефони
Бюджет / контракт
1
Аненков
Петро
Гнатович
12.09.1997 м.Київ, в.
Гетьмана, б.10, кв.6 454- 67- 90,
095-675-65-89
Б
2
С
Борчук
Наталія
Семенівна
03.10.1998 м. Чернівці, в.
Федорова, б. 5, кв. 8 254- 17- 94,
093-135-63-83
К






Назва групи ЛА-11
Вид семестрової звітності Екзамен
Назва предмету Комп’терні технології
Прізвище, ім’я, по-батькові викладача Акінфієв Павло Миколойович
№ п/п
Прізвище,
ініціали студента
Оцінка
Підпис викладача
1
Антощук І.А.
Відмінно
2
Андрійко В.В.
Добре





94 3) списки викладачів кафедр, у табл. 3.27 наведемо приклад списку.
Таблиця 3.27. Список викладачів кафедри АСК
Назва кафедри АСК
Код кафедри 306
Завідувач каф.
Жуков А.І.
Телефон каф.
241-56-76


Таб. номер
Прізвище, ім’я, по – батькові
Посада
Вч. звання
Вч. ступінь
642
Акінфієв Павло Миколойович професор професор д.т.н.
643
Барклай Інна Федорівна професор доцент к.т.н.
642
Жадан Марта Павлівна ст. викладач немає немає





4) інформація про педагогічне навантаження викладачів, у табл. 3.28 наведемо приклад
Таблиця 3.28. Педагогічне завантаження викладачів каф. АСК
Прізвище,
ім’я, по – батькові
Назва предмету
Вид занять
Кількість годин
Шифр групи
Семестрова звітність
Акінфієв
Павло
Миколайович
Комп’ютерні технології
Лекції
36
ЛА-11 екзамен
” – “
Комп’ютерні технології
Лабор. роботи
18
ЛА-11
-
” – “
Числові методи
Практичні заняття
18
ЛА-12
-
Барклай Інна
Федорівна
Числові методи
Лекції
36
ЛА-12 залік
” – “
Метрологія
Лекції
36
ЛА-01 екзамен
” – “
Метрологія
Практичні заняття
36
ЛА-01
-
Метрологія
Практичні заняття
36
ЛА-02
-






Наведені документи ПО слід розглядати як основу для створення таких об’єктів БД, як форми і звіти.
На основі цих документів звітності виділимо інформаційні об’єкти
ПО.

95
Звернемось до списку студентської групи (табл.3.26).
Можна побачити, що кожний студент згідно з задачами деканату має такі властивості: прізвище, ім’я, по – батькові, дату народження, адресу, телефони, джерело фінансування (бюджет або контракт). Спільними властивостями для усіх студентів є шифр групи (надають в залежності від спеціальності), її номер (визначають роком вступу), а також прізвище, ім’я, по-батькові (ПІПб) старости. Деканат вирізняє старост оскільки через них відбувається зв’язок з групою по загальних питаннях. Відзначимо, що усі зазначені властивості можуть співпасти для декількох студентів групи.
Неповторним для студента є його порядковий номер у групі. Враховуючи наявність однакових порядкових номерів у різних групах, за ключ відношення візьмемо декілька властивостей: Шифр_групи, Номер_групи,
Номер_у групі. Решту зазначених атрибутів розглядаємо як описові.
Аналізуючи цю інформацію, визначимо відношення (об’єкт) СТУДЕНТ і запишемо його схему:
СТУДЕНТ (Шифр_групи, Номер_групи, Номер_у групі,

Прізвище_ім’я_
по – батькові, Дата народження, Адреса, Телефони, Джерело
фінансування).
Тепер запишемо схему з такими назвами полів, які будуть у MS
Access:
СТУДЕНТ (Шифр_групи, Номер_групи, Номер_у групі,

ПІПб, Дата_нар,
Адреса, Телефони, Фінанс).
Зі списків студентських груп стає зрозумілим, що можна виокремити ще один об’єкт

СТУДЕНТСЬКА ГРУПА або просто ГРУПА. Кожна група володіє наступними властивостями: шифр, номер, кількість студентів, ПІПб старости, ПІПб куратора та іншими, які визначає деканат.
За ключ об’єкта візьмемо дві з них Шифр_групи та Номер_групи.

96
Решта зазначених атрибутів є описовими. Запишемо можливу схему відношення ГРУПА:
ГРУПА (Шифр_групи, Номер_групи, ПІПб_старости, ПІПб_куратора,
Рік_вступу).
Тепер запишемо схему з такими назвами полів, які будуть у MS Access:
ГРУПА (Шифр_групи, Номер_групи, Староста, Куратор, Рік_вступу).
Між об’єктами ГРУПА та СТУДЕНТ існує зв’язок 1:N, оскільки група може складатися з декількох студентів, а студент навчається в одній групі
1
ГРУПА – головна, СТУДЕНТ – підпорядкована сутності. Для їхнього зв’язування у СТУДЕНТ вже існують атрибути Шифр_групи,
Номер_групи, що є складеним первинним ключем сутності ГРУПА.
Студенти – суб’єкти навчального процесу з одного боку. З іншого суб’єктами є викладачі. З ними пов’язана інформація, наведена у табл.3.25,
3.27, 3.28.
Розглянемо дані, пов’язані з сутністю ВИКЛАДАЧ. Властивостями кожного викладача є табельний номер, прізвище, ім’я та по – батькові, назва кафедри, на якій вони працюють, посада, вчений ступінь, предмети, які вони викладають, типи занять, відповідні їм назви груп, час та аудиторії занять тощо. Цей великий перелік властивостей підказує, що вони можуть характеризувати декілька об’єктів.
Зокрема, з табл. 3.27 видно, що усім викладачам однієї кафедри притаманні спільні риси: назва кафедри, ПІПб завідувача кафедри, телефон кафедри, розташування або кабінет завідувача, телефон кафедри тощо.
Тому виділимо кафедру як окремий об’єкт КАФЕДРА.
1
Випадок, коли студент набуває другу освіту у тому самому закладі, не розглядаємо.

97
Нехай він володіє такими властивостями: код кафедри, назва, ПІПб завідувача, телефон, кабінет завідувача. За ключ доцільно взяти код кафедри. Інші властивості розглядатимемо як описові. Запишемо схему відповідного відношення:
КАФЕДРА (Код_кафедри, Назва_кафедри, ПІПб_завідувача,
Телефон, Кабінет_завідувача).
Запишемо схему з такими назвами полів, які будуть у MS Access:
КАФЕДРА (Код_кафедри, Назва, Завідувач, Телефон, Каб_зав).
З таблиць 3.25, 3.27, 3.28 виокремимо тепер інформаційний об’єкт
ВИКЛАДАЧ. Він володітиме в нашому випадку такими властивостями: табельний номер, прізвище, ім’я та по – батькові, назва кафедри, на якій викладач працює, посада, вчений ступінь. За ключ відповідного відношення візьмемо табельний номер, інші – описові властивості.
Запишемо схему відношення з такими назвами полів, які будуть у MS
Access:
ВИКЛАДАЧ (Таб_номер, ПІПб, Назва_каф, Посада, Вч_ступінь).
Між сутностями КАФЕДРА та ВИКЛАДАЧ існує зв’язок типу 1:N, перша – головна, а друга – підпорядкована. Для того, щоб їх зв’язати уведемо у підпорядковану сутність ВИКЛАДАЧ атрибут Код_кафедри.
Остаточно схема відношення ВИКЛАДАЧ з такими назвами полів, які будуть у MS Access, набуде такого вигляду
ВИКЛАДАЧ (Таб_номер, Код_кафедри, ПІПб, Назва_каф, Посада,
Вч_ступінь).
Розглянемо табл. 3.28 з даними про педагогічне навантаження викладачів. У ній є інформація про навчальні дисципліни (предмети), які

98 повинні вивчати студенти різних груп (за спеціальностями), та про
викладачів. Ця таблиця досить складна у порівнянні з іншими з точки зору виділення інформаційних об’єктів. Оскільки об’єкти ГРУПА та
ВИКЛАДАЧ вже створені, то виокремимо об’єкт ПРЕДМЕТ. Судячи з табл. 3.28, він повинен мати наступні властивості: назва предмету, загальний обсяг годин на його вивчення (обмежимося аудиторними заняттями), види занять (лекції, практичні та лабораторні заняття) та їхні обсяги, вид семестрової звітності (екзамен чи залік), програма предмету
(перелік розділів та тем), назва групи, яка вивчає цей предмет. За ключ відповідного об’єкту доцільно взяти штучний атрибут – код предмету, який іноді вказують навіть у навчальних планах.
Запишемо схему відношення ПРЕДМЕТ:
ПРЕДМЕТ ( Код_предм, Назва_предм, Загальн_обсяг, Лекц, Практ,
Лаб, Звітність, Програма, Шифр_групи, Номер_групи)
Зробимо попередній висновок з наведених таблиць звітної документації – нами виділено такі об’єкти: СТУДЕНТ, ГРУПА,
КАФЕДРА, ВИКЛАДАЧ та ПРЕДМЕТ. Ці сутності добре зрозумілі і користувачам і проектувальникам.
Зауважимо, що ВИКЛАДАЧ теж може містити інформацію про види занять, які проводить кожний викладач. Отже, у об’єктів ПРЕДМЕТ і
ВИКЛАДАЧ могли б бути спільні властивості. Треба тепер з’ясувати, чи можна обмежитися цими сутностями для задоволення вимог реляційної
БД. Для цього вивчимо властивості зв’язків між сутностями: один викладач може проводити заняття з декількох предметів, а один предмет може викладатися декількома викладачами, тобто зв’язок типу N:M.
Розглянемо наступну пару об’єктів – ГРУПА та ВИКЛАДАЧ. З однією групою працює декілька викладачів, а один викладач може

99 викладати у декількох групах, отже зв’язок між сутностями також типу
N:M.
Розглянемо дві сутності – ГРУПА та ПРЕДМЕТ. Студентська група вивчає декілька предметів, а один предмет може викладатися у декількох групах, отже зв’язок між сутностями також типу N:M.
На рис. 3.5 зобразимо ER – діаграму для зазначених сутностей у нотації Чена.
Викладач
Викладач
Викладає
Викладає
M
Предмет
Предмет
N
Студент
Студент
Вивчає
Вивчає
N
M
Навчає
Навчає
M
N
Рис. 3.5. ER – діаграма для сутностей ВИКЛАДАЧ, ПРЕДМЕТ

Поділіться з Вашими друзьями:
1   2   3   4   5


База даних захищена авторським правом ©divovo.in.ua 2017
звернутися до адміністрації

войти | регистрация
    Головна сторінка


загрузить материал