2.1 Проектування концептуальної моделі бази даних «Абітурієнт» Опрацювання індивідуального завдання.

Після отримання завдання виконуємо наступні дії:

1. Опрацювання завдання і формулювання головної мети розробки.

Мета розробки полягає в якісному опрацюванні запропонованої теми та всього належного матеріалу з метою придбання корисних навичок для роботи з базами даних і знань, та роботи в середовищі Borland C++ Builder 6 nf Microsoft SQL Server;

2.2 Розроблення нормальних форм.

2.1. Розробка відношень у першій, другій та третій нормальних формах відповідно варіанту свого проекту.

2.2. Виділення первинних ключів, функціональних та транзитивних залежностей.

2.3. Опрацювання різних теоретичних відомостей та фактів, що допоможуть в розв’язанні поставленої мети, застосування та придбання власних навичок та вмінь для створення власної підсистеми “РОЗДРІБ”.

Логічна структура представляє собою не нормалізовану таблицю базі даних.

Нормалізація – це розбиття таблиці на одну чи більше, що мають кращі якості включення розбиття та видалення даних. Мета нормалізації – отримання такого проекту бази даних, в якому кожен факт зустрічается лише в одному місці. Тобто позбавитись від збитковості даних та транзитивних зв’язків.

Для преведення таблиці до нормальної форми використовують процедуру нормалізації.

Її суть у послідовному переведені таблиці від першої до n-ї нормальної форми. Фактично нормальна форма від таблиці це – її декомпозиція на декілька таблиць.

Перша нормальна форма (1NF)

Відношення знаходиться в першій нормальній формі (1НФ) тоді і тільки тоді, коли в будь-якому допустимому значенні відношення кожен його кортеж містить тільки одне значення для кожного з атрибутів.

У реляційній моделі відношення завжди знаходиться в першій нормальній формі за визначенням поняття відношення. Що ж стосується різних таблиць, то вони можуть не бути правильними уявленнями відносин і, відповідно, можуть не перебувати в 1НФ.

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

Першим кроком є створення першої нормальної форми, яка містить лише прості атрибути, що виділяються шляхом розбиття складних на частини.

На рис. 1 бачимо таблицю в 1 N F .

рис. 1

Первинний зчеплений ключ: личный номер+предмет+номер специальности. При умові, що кожний абітурієнт не може здавати один і той же предмет на спеціальність кілька разів.

Друга нормальна форма (2NF)

Відношення знаходиться в другій нормальній формі, якщо воно знаходиться в першій нормальній формі, і при цьому будь-який його атрибут, який не входить до складу потенційного ключа, функціонально повно залежить від кожного потенційного ключа. Функціонально повна залежність означає, що атрибут функціонально залежить від всього складеного потенційного ключа, але при цьому не знаходиться у функціональній залежності від будь-якої з вхідних в нього частин. Або іншими словами: в 2NF немає неключових атрибутів, залежних від частини складного потенційного ключа.

Друге важливе значення другої нормальної форми полягає в тому, що вона за визначенням забороняє наявність неключових атрибутів, які взагалі не залежать від потенційного ключа. Таким чином, 2NF забороняє створювати відносини як незв'язані (хаотичні, випадкові) набори атрибутів.

Тепер приводимо наше відношення в другу нормальну форму шляхом виключення часткових функціональних залежностей неключових атрибутів від ключа.

На рис. 2.1 бачимо таблицю в 2 N F – «Институт».

Институт

Первинний ключ: Реєстраційний номер

рис. 2.1

Третя нормальна форма (3NF).

Третя нормальна форма (3НФ) — нормальна форма використовна в нормалізації баз даних. 3НФ первісно була визначена Едгаром Коддом в 1971. Визначення Кодд каже, що таблиця знаходиться в 3НФ тоді і тільки тоді, коли виконуються наступні умови:

• відношення R (таблиця) знаходиться в 2НФ

• кожен неключовий атрибут відношення R нетранзитивно залежить (тобто залежить безпосередньо) від кожного потенційного ключа в R.

Неключовий атрибут R — атрибут, що не є частиною будь-якого потенційного ключа. Транзитивною називають таку функціональну залежність, в якій X → Z (X визначає Z) непрямо, а через X → Y і Y → Z (і невірно, що Y → X).

Інше визначення 3НФ тотожне до визначення Кодда, дав Карло Заніоло в 1982. Це визначення стверджує, що таблиця в 3НФ тоді і тільки тоді, коли для кожної її функціональної залежності X → A, вірна хочаб одна з наступних умов:

• X містить A (тоді X → A це тривіальна функціональна залежність), або

• X це суперключ, або

• A-X, різниця множин A і X це ключовий атрібут (тобто, A-X міститься в потенційному ключі).

Шляхом виключення транзитивних залежностей неключових атрибутів від первинного ключа приводимо таблиці до третьої нормальної форми.

На рис. 3.1 бачимо таблицю в 3 N F – «Предмет», і на рис. 3.2 –таблицю «Специальность».

Предмет

рис. 3.1

Рис.3.1

Специальность

рис. 3.2

Рис.3.2

Створення бази даних «Абітурієнт»

Для створення користувача необхідно вибрати потрібну базу даних, вибрати об’єкт Users, та вибрати Newdatabaseuser, після чого з’явиться вікно для створення нового користувача для бази даних «Абітурієнт» рис.3.4 В полі Loginname вибираємо зі списку раніше створений логін або вибираємо пункт new, після чого створюємо новий логін рис.3.5

рис. 3.4. рис. 3.5.

В даномі вікні необхідно ввести ім’я логіну в полі name, з випадаючого списку Domain, вибрати потрібний домен та з випадаючого списку Database вибрати назву бази даних Абітурієнт.

Потім потрібно повернутись до вікна рис.3.4, та в полі Loginname вибрати створений логін, а в полі Username вводимо ім’я користувача та натискаємо ok. Користувач “426-033DD49E45A\Администратор” створений рис.3.6.

рис.3.6.Створений користувач в списку користувачів бази даних “Абітурієнт”.

Отже, база даних готова до роботи.