1. Проектування баз даних

Проектування баз даних – це процес створення схеми бази і визначення її обмежень цілісності.

До основних задач, які повинне вирішувати проектування БД можна віднести:

• забезпечення збереження необхідної інформації і цілісності в БД

• забезпечення можливості отримання даних по всіх необхідним запитам

• запобігання повторення (дублювання) записів

Серед основних етапів проектування БД можна виділити наступні:

• концептуальне проектування

• логічне проектування

• фізичне проектування

На даній дипломній роботі ми будемо розглядати перші два етапи.

1. Концептуальне (інфологічне) проектування

Під концептуальним проектуванням моделі предметної області розуміють побудову моделі на найбільш високому рівні абстракції. Така модель не є орієнтованою на будь яку СУБД. Для побудови концептуальної моделі ми будемо використовувати нотації Пітера Чена, в якому сутності позначаються прямокутниками, атрибути – овалами, а відношення між сутностями позначаються у вигляді ромбів.

Досліджуючи предметну область АНС можна виділити наступні сутності (рис. 2.1):

• Студент

• Адміністратор (викладач)

• Лекція

• Тестова частина

• Практична частина

• Результат

Рис. 3.1 Інфологічна модель

2. Логічне (даталогічне) проектування

За логічним проектуванням розуміють створення схеми бази даних на основі конкретної бази даних. При такому моделюванні, як правило, присутній набір схем відношень, зазвичай, з зазначенням первинних ключів, а також зв’язків між відношеннями.

На основі інфологічної моделі (рис. 2.1.) була розроблена модель баз даних, яка включає в себе наступні таблиці:

Таблиця 3.1 «Група»

Назва поля	Опис	Тип даних
Ідентифікатор	Унікальний ключ групи	Текстовий
Спеціальність	Спеціальність групи	-||-
Кафедра	Кафедра у ВНЗ	-||-

Сутність «Група» однозначно ідентифікується атрибутом «Ідентифікатор.Група», він і встановлюється первинним ключем.

Таблиця 3. 2 «Адміністрація»

Назва поля	Опис	Тип даних
ПІБ	ПІБ адміністрації	Текстовий
Пароль	Пароль для доступу	-||-

Таблиця 3.3 «Студент»

Назва поля	Опис	Тип даних
ПІБ	ПІБ студента	Текстовий
Пароль	Пароль для доступу	Текстовий
Ідентифікатор	Унікальний номер	Числовий
Група	Відношення до групи	Текстовий

Між сутностями «Студент» і «Група» встановлюється зв'язок «багато до одного», оскільки у одній групі може бути безліч студентів. Сутність «Студент» однозначно ідентифікується атрибутом «Ідентифікатор.Студент», його і призначаємо первинним ключем.

Таблиця 3.4 «Лекція»

Назва поля	Опис	Тип даних
Назва	Унікальна назва лекції	Текстовий
Автор	Автор лекції	-||-
Спеціальність	Спеціальність	-||-
Дисципліна	Назва предмету	-||-

Сутність «Лекція» однозначно ідентифікується атрибутом «Назва.Лекція». Він і буде первинним ключем.

Таблиця 3.5 «Практика»

Назва поля	Опис	Тип даних
Практична	Назва практичної	Текстовий
Лекція	Відношення до лекції	-||-
Автор	Автор практичної	-||-
Постановка задачі	Умова задачі	-||-
Результат	Правильна відповідь	-||-
Додаток	Присутність додатку	Логічний
Шлях додатку	Шлях до додатку	Текстовий
Час проходження	Час практичної	Числовий

Між сутностями «Практика» і «Лекція» можна встановити зв'язок «багато до одного», оскільки до однієї лекції можна написати безліч практичних завдань. У сутності «Практика» однозначним ідентифікатором призначаємо атрибут «Практична.Практика».

Таблиця 3.6 «Тест»

Назва поля	Опис	Тип даних
Ідентифікатор	Назва тестування	Текстовий
Автор	Автор тесту	-||-
Кількість питань	Кількість питань у тесті	Числовий
Час проходження	Час тестування	-||-
Лекція	Відношення до лекції	Текстовий

Між сутностями «Лекція» і «Тест» встановлюється зв'язок «один до багатьох», оскільки до однієї лекції можливо написати безліч тестів. Сутність «Тест» ідентифікуємо атрибутом «Ідентифікатор.Тест».

Таблиця 3.7 «Питання»

Назва поля	Опис	Тип даних
№Питання	Номер запитання у тесті	Числовий
Завдання	Текст запитання	Текстовий
Варіант1	Відповідь 1	-||-
Варіант2	Відповідь 2	-||-
Варіант3	Відповідь 3	-||-
Варіант4	Відповідь 4	-||-
Правильна відповідь	Номер вірної відповіді	Числовий
№Тесту	Відповідність тесту	Текстовий
Вага питання	Значимість питання	Числовий

Між сутностями «Питання» і «Тест» можливо встановити зв'язок «Безліч до одного», оскільки у одному тесті можлива присутність багатьох запитань. Ідентифікаторами у сутності «Питання» призначаємо два атрибути: «№Питання» і «№Тесту».

Таблиця 3.8 «Результат Тест»

Назва поля	Опис	Тип даних
№Студент	Відповідність студенту	Текстовий
№Тест	Відповідність тесту	-||-
Кількість вірних відповідей	Лічильник відповідей тестування	Числовий
Оцінка	Результат оцінювання	-||-
Дата проходження	Дата проведення тесту	Дата

Між сутностями «Результат тест» і «Студент» встановлюється зв'язок «багато до одного», оскільки у одного студента є можливість мати безліч результатів до тестів; між сутностями «Тест» і «Результат Тест» встановлюємо зв'язок «один до багатьох», через можливість отримання безлічі результатів на один тест різними студентами. Первинні ключі відсутні.

Таблиця 3.9 «Результат Практика»

Назва поля	Опис	Тип даних
№Студент	Відповідність студенту	Текстовий
№Практична	Відповідність практичній	-||-
Оцінка	Результат	Числовий
Дата проходження	Дата проведення	Дата

Між сутностями «Результат практика» і «Студент» встановлюється зв'язок «багато до одного», оскільки у одного студента є можливість мати безліч результатів до різних практичних завдань; між сутностями «Практика» і «Результат Практика» встановлюємо зв'язок «один до багатьох», через можливість отримання безлічі результатів на одну практичну роботу різними студентами. Сутність не має однозначних ідентифікаторів, первинні ключі відсутні.

Рис. 3.2. ER – діаграма

Виходячи з вище наведених таблиць, за допомогою програми Microsoft Access, ми можемо створити необхідну нам в подальшому базу даних і згенерувати ER діаграму (рис. 2.2). ER-модель зручна при проектуванні інформаційних систем, баз даних, архітектур комп'ютерних програм та інших систем (моделей). За допомогою такої моделі виділяють найсуттєвіші елементи (вузли, блоки) моделі і встановлюють зв'язки між ними.