135489 (База даних "Теорія та практика прикладного програмування"), страница 2

Повний етап проектування бази даних складається з трьох частин:

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

2. Даталогічного проектування.

3. Фізичного проектування.

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

Концептуальне проектування — це збір, аналіз та редагування вимог до даних. Для цього здійснюються наступні заходи:

• обстеження предметної області, вивчення її інформаційної структури;

• виявлення всіх фрагментів, кожен з яких характеризується користувальницьким поданням, інформаційними об'єктами і зв'язками між ними, процесами над інформаційними об'єктами;

• моделювання та інтеграція всіх уявлень.

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

Зв'язок — це асоціювання двох чи більш сутностей. Якби призначенням бази даних було тільки збереження окремих, не пов'язаних між собою даних, то її структура могла б бути дуже простою. Проте одна з основних вимог до організації бази даних — це забезпечення можливості відшукання одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. А так як в реальних базах даних нерідко містяться сотні або навіть тисячі сутностей, то теоретично між ними може бути встановлено більше мільйона зв'язків. Наявність такої безлічі зв'язків і визначає складність інфологічних моделей. [4]

У даній інформаційній системі основними об'єктами є:

• Глава з властивостями: Код параграфа, Затрата времени на изучение, Код оператора, Компоненты, Код таблицы, Код рисунка, Код примечания, Код листингов, Дата разработки записи;

• Листинги з властивостями: Названия листинга, Работа с формой, Листинг;

• Операторы з властивостями: Ключевые слова, Синтаксис оператора, Семантика оператора, Пример использования;

• Параграфы з властивостями: Название параграфа, Краткое содержание, Начальная страница, Конечная страница;

• Примечания з властивостями: Страница, Примечание;

• Рисунки з властивостями: Название рисунка, Страница расположения рисунка, Рисунок;

• Таблицы властивостями: Название таблицы, Страница нахождения, Таблица.

2.1.1 Побудова ER-діаграми

В даний час при моделюванні структур баз даних однією з найпоширеніших нотацій є модель даних Entity-Relation (Сутність-Зв'язок), запропонована П. Ченом. При ER-моделюванні в предметній області виділяються певні класи реальних чи логічних об'єктів, які називаються сутностями. Далі між сутностями встановлюються різні зв'язки і взаємозалежності, які називають відносинами.

Результати ER-моделювання зазвичай представляють у вигляді ER-діаграм, на яких у вигляді прямокутників позначаються модельовані сутності, а у вигляді з'єднуючих їх ліній — відносини.

Модель "сутність-зв'язок" (ER-модель) (англ. Entity-relationship model або entity-relationship diagram) — модель даних, яка дозволяє описувати концептуальні схеми за допомогою узагальнених блочних конструкцій. ER-модель — це мета-модель даних, тобто засіб опису моделей даних. [5]

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

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

Рисунок 2.1.1 – ER-діаграма

Для цього використовуються наступні позначення:

1. Сутність зображається прямокутниками.

2. Атрибути позначаються овалами (або прямокутниками з закругленими кутами).

3. Зв’язки зображаються ромбами.

2.1.2 Нормалізація даних

Нормалізація таблиць бази даних — перший крок на шляху реалізації структури реляційної бази даних.

Теорія нормалізації реляційних баз даних була розроблена у кінці 70-х років 20 століття. Відповідно до неї, виділяються шість нормальних форм, п'ять з яких так і називаються: перша, друга, третя, четверта, п'ята нормальна форма, а також нормальна форма Бойса-Кодда, що лежить між третьою і четвертою.

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

Головна мета нормалізації бази даних — усунення надмірності та дублювання інформації. В ідеалі при нормалізації треба домогтися, щоб будь-яке значення зберігалося в базі в одному примірнику, причому значення це не повинно бути отримано розрахунковим шляхом з інших даних, що зберігаються в базі.

Перша нормальна форма: [6]

• Забороняє повторювання стовпців, що містять однакову за змістом інформацію;

• Забороняє множинні стовпці (що містять значення типу списку і т.п.);

• Вимагає визначити первинний ключ для таблиці, тобто той стовпець або комбінацію стовпців, які однозначно визначають кожен рядок.

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

Щоб таблиця перебувала в третій нормальній формі, необхідно, щоб неключові стовпці в ній не залежали від інших неключових стовпців, а залежали лише від первинного ключа. Найпоширеніша ситуація в даному контексті — це розрахункові стовпці, значення яких можна отримати шляхом будь-яких маніпуляцій з іншими стовпцями таблиці. Для приведення таблиці в третю нормальну форму такі стовпці з таблиць треба видалити.

Нормальна форма Бойса-Кодда вимагає, щоб в таблиці був тільки один потенційний первинний ключ. Найчастіше у таблиць, що знаходяться в третій нормальній формі, так і буває, але не завжди. Якщо виявився другий стовпець (комбінація стовпців), що дозволяє однозначно ідентифікувати рядок, то для приведення до нормальної форми Бойса-Кодда такі дані треба винести в окрему таблицю.

Для приведення таблиці, що знаходиться в нормальній формі Бойса-Кодда, до четвертої нормальної форми необхідно усунути наявні в ній багатозначні залежності. Тобто забезпечити, щоб вставка / видалення будь-якого рядка таблиці не вимагала б вставки / видалення / модифікації інших рядків цієї ж таблиці.

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

Рисунок 2.1.2 – Нормалізована ER-діаграма (3НФ)

2.2 Даталогічне проектування баз даних

При переході від інфологічної моделі до даталогічної слід мати на увазі, що інфологічна модель включає в себе всю інформацію про предметну область, необхідну для проектування БД. Це не означає, що всі суті, зафіксовані в ІЛМ, повинні в явному вигляді відображатися в даталогічній моделі. Перш ніж будувати даталогічну модель, необхідно вирішити, яка інформація буде зберігатися в базі даних. Наприклад, у інфологічній моделі мають бути відображені показники, що обчислюються, але зовсім не обов'язково, щоб вони зберігалися в базі даних.

Таблиця 2.2.1. «Глава»

Поле	Тип даних	Розмір
№ п/п	Лічильник	Довге ціле
Код параграфа	Числовий	Довге ціле
Затрата времени на изучение	Числовий	Довге ціле
Код оператора	Числовий	Довге ціле
Компоненты	Логічний
Код таблицы	Числовий	Довге ціле
Код рисунка	Числовий	Довге ціле
Код примечания	Числовий	Довге ціле
Код листингов	Числовий	Довге ціле
Дата разработки записи	Дата/час

Таблиця 2.2.2. «Листинги»

Поле	Тип даних	Розмір
Код листинга	Лічильник	Довге ціле
Название листинга	Текстовий	50
Работа с формой	Логічний
Листинг	Поле МЕМО

Таблиця 2.2.3. «Операторы»

Поле	Тип даних	Розмір
Код оператора	Лічильник
Ключевые слова	Текстовий	200
Синтаксис оператора	Текстовий	240
Семантика оператора	Текстовий	255
Пример использования	Числовий	Довге ціле

Таблиця 2.2.4. «Параграфы»

Поле	Тип даних	Розмір
Код параграфа	Лічильник
Название параграфа	Текстовий	50
Краткое содержание	Текстовий	250
Начальная страница	Числовий	Довге ціле
Конечная страница	Числовий	Довге ціле

Таблиця 2.2.5. «Примечания»

Поле	Тип даних	Розмір
Код примечания	Лічильник
Страница	Числовий	Довге ціле
Примечание	Поле МЕМО

Таблиця 2.2.6. «Рисунки»

Поле	Тип даних	Розмір
Код рисунка	Лічильник
Название рисунка	Текстовий	65
Страница расположения рисунка	Числовий	Довге ціле
Рисунок	Поле МЕМО

Таблиця 2.2.7. «Таблицы»

Поле	Тип даних	Розмір
Код таблицы	Лічильник
Название таблицы	Текстовий	60
Страница нахождения	Числовий	Довге ціле
Таблица	Поле МЕМО

Структура таблиць відноситься до 3 НФ:

1) кожен стовпець таблиці неподільний і в рамках однієї таблиці немає стовпців з однаковими за змістом значеннями.

2) первинні ключі таблиць однозначно визначають запис і не надмірні.

3) значення будь-якого поля не входить у первинний ключ, не залежить від значення іншого поля, що також не входить у первинний ключ.

2.3 Фізичне проектування інформаційних систем

Фізичне проектування — це безпосереднє проектування програмних модулів, з яких збирається додаток; це точка зору програміста на додаток.