- •Міністерство освіти і науки україни
- •1. Стратегія автоматизації предметної області 3
- •1. Стратегія автоматизації предметної області
- •1.1. Загальні положення
- •1.2. Мета, цілі та задачі створення бази даних
- •1.3. Вимоги до інформаційного забезпечення
- •2. Аналіз предметної області
- •2.1. Загальні положення системного аналізу по
- •2.2. Загальні положення проходження практики
- •2.3. Системний аналіз предметної області
- •2.3.1. Сутність Навчальний план
- •2.3.2. Сутність Запланована практика
- •2.3.3. Сутність Вид практики
- •2.3.4. Сутність Кваліфікаційний рівень
- •2.3.5. Сутність Спеціальність
- •2.3.6. Сутність Курс
- •2.3.7. Сутність вуз
- •2.3.8. Сутність Інститут
- •2.3.9. Сутність Факультет
- •2.3.10. Сутність Кафедра
- •2.3.11. Сутність Група
- •2.3.12. Сутність Студент
- •2.3.13. Сутність База практики
- •2.3.14. Сутність Договір
- •2.3.15. Сутність Керівник
- •2.3.16. Сутність Практика студента
- •2.3.17. Сутність Звіт
- •2.4. Інформаційно-довідкові задачі
- •3. Концептуальне моделювання предметної області
- •3.1. Теоретичні положення концептуального моделювання
- •3.2. Мова er—моделювання по
- •3.2. Побудова концептуальної моделі проходження практики студентами
- •4. Логічне та фізичне проектування бази даних
- •4.1. Логічне проектування
- •Institute
- •4.2. Фізичне проектування
- •4.2.1. Скрипти створення бази даних
- •4.2.2. Інформаційно–пошукові запити
- •4.2.2.1.Інформаційні запити, що пов’язані з проходженням практики
- •4.2.2.2.Інформація організаційного характеру
- •4.2.2.3.Інформація про керівників практики
- •Висновки
3.2. Побудова концептуальної моделі проходження практики студентами
На основі проведеного аналізу предметної області була побудована концептуальна модель з використанням мови ER–моделювання. Концептуальна модель наведена на наступному рисунку. Дамо декілька зауважень:
По–перше, ця модель не містить опису атрибутів сутностей у зв’язку з відсутністю місця для їх зображення. Передбачається, що атрибути сутностей разом з їх властивостями (бізнес–правилами) детально описані на етапі аналізу.
По–друге, мова ER–моделювання не передбачає детального представлення інформаційно–довідкових задач. Ми припускаємо, що вони мають звичайний текстовий опис, який представлений на етапі аналізу.
І, по-третє, наша концептуальна модель не містить інших складових, а саме, докладний і строгий опис сховищ даних, та детальний опис потоків даних. Це не було зроблено, так як опис цих складових концептуальної моделі виходить за рамки курсової роботи.
4. Логічне та фізичне проектування бази даних
Завдання цього етапу полягає у проведенні логічного та фізичного проектування бази даних.
Логічне проектування— це розробка логічної структури системи баз даних без прив'язки до конкретної СУБД, структур збереження, методам доступу і т.д..
Фізичне проектування– це проект системи бази даних для конкретної СКБД. Під час виконання даного етапу модель сутностей і зв'язків перетворюється в схему бази даних і специфікації позамашинного збереження.
4.1. Логічне проектування
У якості логічній моделі бази даних була обрана реляційна модель, оскільки саме реляційна модель використовується у більшості розвинених СКБД.
Для перетворення концептуальної моделі, представленої у вигляді мови ER–моделювання, у реляційну модель, був використаний наступний алгоритм.
Крок 1. Перетворення сутностей у таблиці. Кожна сутність перетворюється у таблицю. Ім’я сутності представляється у вигляді семантично осмисленого імені у латинському алфавіті.
Крок 2. Перетворення атрибутів у стовпці. Кожний атрибут перетвориться в стовпець. Ім’я атрибуту представляється у вигляді семантично осмисленого імені у латинському алфавіті. У цей момент уточнюється формат представлення значень стовпця. Факультативні атрибути стають NULL-стовпцями. Обов'язкові атрибути стають NOT NULL-стовпцями.
Крок 3. Подання унікальних ідентифікаторів ключами таблиць. Складові унікального ідентифікатора сутності стають первинним ключем таблиці. Нагадаємо, що сутність може мати більш ніж один унікальний ідентифікатор Тому вибирається той, котрий використовується найбільше часто. Всі інші унікальні ідентифікатори приймають обмеження цілісності UNIQUE NOT та NOT NULL.
Рис. Концептуальна ER-модель проходження практики студентами
Сутність може унікально ідентифікуватися комбінацією атрибутів і/або зв'язків. При використанні в ідентифікаторі сутності зв'язку до складу первинного ключа включається зовнішній ключ, який посилається на ту таблицю, з якою пов’язаний той або інший зв’язок.
Крок 4. Перетворення зв'язків багато-до-одного й один-до-одного в зовнішні ключі. Зв'язки типу багато-до-одного й один-до-одного породжують зовнішні ключі. Інакше кажучи, необхідно взяти унікальні ідентифікатори кожної сутності, розташованої в закінчення зв'язку зі ступенем один, і ввести його у відношення, розташоване з боку зв'язку "багато" як стовпці. Факультативним зв'язкам відповідаютьNULL-стовпці. Обов'язковим зв'язкам відповідаютьNOT NULL-стовпці.
Крок 5. Введення спеціальних первинних ключів. Для більш адекватного відображення логічного проекту бази даних у фізичний, вводимо у всі таблиці один спеціальний стовпець з обмеженням цілісності первинного ключа. Всі ті стовпці, які мають властивість первинного ключа згідно з концептуальною моделлю, набувають обмеження цілісностіUNIQUE та NOTNULL.
Повна логічна база даних на основі концептуальної моделі з урахуванням обмежень цілісності та наведеного вище алгоритму детально представлена в наступних таблицях.
Таблиця 1. Відношення сутності НАВЧАЛЬНИЙ ПЛАН
EDU_PLAN
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
EPID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Num |
строка |
8 |
Номер навч. плану |
Унікальний, обов’язковий |
Ass_date |
дата |
|
Дата затвердження |
Обов’язковий |
Prs |
строка |
40 |
Особа, що затвердила |
Обов’язковий |
SPID |
ціле число |
10 |
Зв’язок зі спеціальністю |
Зовнішній ключ, що посилається на первинний ключ відношення SPECIALITY. Обов’язковий |
Таблиця 2. Відношення сутності ЗАПЛАНОВАНА ПРАКТИКА
PLAN_PRACTICE
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
PPID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Dur_type |
строка |
1 |
Одиниці виміру терміну проходження практики. Приймає значення „Д”–дні, „Т”–тижні |
Обов’язковий |
Duration |
ціле число |
3 |
Термін проходження практики |
Обов’язковий |
QLID |
ціле число |
10 |
Зв’язок з кваліфікаційним рівнем |
Зовнішній ключ, що посилається на первинний ключ відношення QUALI_LEVEL. Обов’язковий |
CUID |
ціле число |
10 |
Зв’язок з курсом |
Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов’язковий |
PTID |
ціле число |
10 |
Зв’язок з видом практики |
Зовнішній ключ, що посилається на первинний ключ відношення PRAC_TYPE. Обов’язковий |
EPID |
ціле число |
10 |
Зв’язок з навчальним планом |
Зовнішній ключ, що посилається на первинний ключ відношення EDU_PLAN. Обов’язковий |
Обмеження цілісності таблиці |
Сукупність стовпців (CUID,EPID) має обмеження унікальності та обов’язковості. |
Таблиця 3. Відношення сутності ВИД ПРАКТИКИ
PRAC_TYPE
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
PTID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Назва практики |
Унікальний, обов’язковий. Приймає значення: схемотехнічна; комп’ютерна; технологічна; експлуатаційна (для спеціалістів науково-дослідна (для магістрів). |
Descr |
строка |
255 |
Змістовний опис |
Факультативний |
Таблиця 4. Відношення сутності КВАЛІФІКАЦІЙНИЙ РІВЕНЬ
QUALI_LEVEL
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
QLID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Name |
строка |
15 |
Назва кваліфікаційного рівня |
Унікальний, обов’язковий. Приймає значення: бакалавр; спеціаліст; магістр. |
Descr |
строка |
255 |
Змістовний опис |
Факультативний |
CUID |
ціле число |
10 |
Зв’язок з курсом |
Зовнішній ключ, що посилається на первинний ключ відношення COURSE. Обов’язковий |
Таблиця 5. Відношення сутності СПЕЦІАЛЬНІСТЬ
SPECIALITY
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
SPID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Num |
строка |
20 |
Номер спеціальності |
Унікальний, обов’язковий. |
Name |
строка |
100 |
Назва спеціальності |
Обов’язковий |
Таблиця 6. Відношення сутності КУРС
COURSE
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
CUID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Num |
ціле число |
1 |
Номер курсу |
Унікальний, обов’язковий. Приймає значення: 1-6. |
Descr |
строка |
255 |
Змістовний опис |
Факультативний |
Таблиця 7. Відношення сутності ВУЗ
UNIVERSITY
Ім’я стовпця |
Тип |
Довжина |
Призначення |
Обмеження цілісності стовпців |
UNID |
ціле число |
10 |
Унікальний ID |
Первинний ключ |
Short_Name |
строка |
10 |
Скорочена назва ВУЗу |
Факультативний. |
Long_Name |
строка |
50 |
Повна назва ВУЗу |
Обов’язковий, унікальний |
Address |
строка |
50 |
Адреса ВУЗу |
Факультативний |
Rector |
строка |
30 |
ПІБ ректора |
Обов’язковий, унікальний |
Таблиця 8. Відношення сутності ІНСТИТУТ