2. Основні конструктивні елементи інфологічної моделі

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

Основними конструктивними елементами інфологічної моделі є:

• сутності;

• зв'язки між ними;

• їх властивості (атрибути).

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

Поняття тип сутності відноситься до набору однорідних особистостей, предметів, подій чи ідей, що виступають як ціле.

Екземпляр сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути Аеропорт, а екземплярами - Шеремєтьєво, Бориспіль, Хітроу і т.д.

Рис. 4.2. Приклад сутності «АЕРОПОРТ».

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

Атрибут - пойменована характеристика сутності. Його ім’я повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДІМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність. Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР, ПОТУЖНІСТЬ ДВИГУНА і т.д. Тут також існує розходження між типом і екземпляром. Тип атрибута КОЛІР має багато чи екземплярів значень: червоний, синій, банановий, біла ніч і т.д., однак кожному екземпляру сутності привласнюється тільки одне значення атрибута.

Абсолютна різниця між типами сутностей і атрибутами відсутня. Атрибут є таким тільки в зв'язку з типом сутності. В іншому контексті атрибут може виступати як самостійна сутність. Наприклад, для автомобільного заводу колір - це тільки атрибут продукту виробництва, а для лакофарбової фабрики колір - тип сутності.

Ключ - мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виключення з набору будь-якого атрибута не дозволяє ідентифікувати сутність по що залишилися. Так, наприклад, для сутності «Розклад (польотів літаків)» ключем буде атрибут Номер_ рейса або набір: Пункт_відправлення, Час_вильоту і Пункт_призначення (за умови, що з пункту в пункт вилітає в кожен момент часу один літак).

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

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

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

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

Створюється певна структура даних про деяку предметну область.

СТРУКТУРА ДАНИХ у базі даних — це уявлення користувача про дані, що не залежить від способу їхнього збереження в базі даних. Кожна СУБД визначає типи даних і правила композиції, з якими може працювати користувач бази даних. Тип даних визначає безліч значень, що можуть приймати відповідні йому дані. Прикладами властивостей типу можуть бути:

• ім'я даного;

• категорія значення (число, рядок, дата та ін.);

• замок захисту для керування доступом до даного й ін.

База даних складається зі структурних елементів різного типу, причому елементи одного типу можуть складатися чи конструюватися з елементів інших типів.

Опис кожної структури в термінах властивостей, властивим усім даним, що належать до структури даного типу, складає схему даних.

Наприклад, схема бази даних СУБД ORACLE може містить у собі наступні структурні елементи: таблиці, уявлення, послідовності, синоніми, індекси, кластери, процедури, функції, пакети і зв'язки бази даних (рис. 4.3).

Рис. 4.3. Схема бази даних СУБД ORACLE.

При класичному підході до проектування бази даних кінцевим результатом роботи на даному етапі є створення так називаного сценарію. Сценарій записується за допомогою спеціальних операторів мови SQL (structure query language – мова структурованих запитів) - мови опису даних (DDL -Data Definition Language). Приклад операторів створення структури таблиці «КАФЕДРА» і індексу для неї приведений на Рис. 4.4.

CREATE TABLE KAFEDRA ( NUMKAF NUMBER NOT NULL, NOMER SMALLINT, MYNAMES VARCHAR(50)) CREATE ASCENDING INDEX NUMKAF_NDX ON KAFEDRA (NUMKAF).

Рис. 4.4. Приклад визначення таблиці KAFEDRA мовою опису даних.

Однак, СУБД ACCESS, роботу з який ми будемо вивчати в практичній частині нашого курсу, дозволяє в значній мірі автоматизувати різні дії, зв'язані зі створенням схеми бази даних. Використовуючи дану СУБД проектувальник може зовсім не знати про існування мови структурованих запитів, більш того, йому не потрібно писати абсолютно ніяк коду для створення таблиць, чи запитів форм. завдання типів полів і т.д. СУБД ACCESS за допомогою спеціальних засобів пропонує йому зробити вибір, залишається тільки клацнути мишкою - і об'єкт схеми БД готовий.

Схема бази даних СУБД ACCESS (рис. 4.5) містить у собі наступні елементи: таблиці, форми, звіти, запити, модулі і макроси. Етап даталогічного проектування з використанням СУБД ACCESS складається в завданні таблиць і наборів стовпців для кожної таблиці. Кожній таблиці і кожному стовпцю дається ім'я. Для кожного стовпця вибирається потрібний ТИП ДАНИХ (такий як CHAR, DATE чи NUMBER), а також ШИРИНА (яка може бути визначена типом даних, як у випадку DATE) чи МАСШТАБ і ТОЧНІСТЬ (тільки для типу даних NUMBER). Далі виробляється конструювання і зв'язування таблиць для забезпечення цілісності бази даних і для можливості добування повної інформації про об'єкт. Потім можна перейти до проектування форм для введення інформації. Форми складаються з полів, за допомогою яких здійснюється введення чи перегляд даних.

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

Рис. 4.5. Схема бази даних ACCESS.

Microsoft SQL| Server| — це реляційна СУБД, яка використовує мову|язик| TRANSACT-SQL| для пересилки повідомлень|сполучень| між комп'ютером клієнта і комп'ютером, на якому працює SQL| Server|.

Рис. 4.5. Схема бази даних Microsoft SQL Server.

Реляційна СУБД складається з механізму баз даних, власне баз даних і додатків|застосувань|, необхідних для управління даними і компонентами реляційної СУБД. Реляційна СУБД організовує дані у вигляді зв'язаних рядків і стовпців, складових базу даних. Реляційна СУБД відповідає за підтримку структури бази даних і вирішує|рішає| наступні|слідуючі| завдання|задачі|:

• підтримує зв'язки між даними в базі;

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

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