Основи інформаційних систем. Бази даних.
План.
1. Основні поняття.
2. Класифікація баз даних.
3. Моделі даних.
4. Інформаційні об'єкти та зв'язки.
5. Проектування баз даних.
6. Склад файлу БД. Архітектура СУБД.
7. Зв'язування таблиць. Цілісність даних.
8. Види запитів. Структура запитів.
Основні поняття.
У розвитку обчислювальної техніки спостерігалося два основних напрями її застосування.
Перше пов'язані з виконанням великих чисельних розрахунків, які важко чи неможливо зробити вручну. Розвиток цієї галузі сприяло прискоренню розвитку методів математичного моделювання, чисельних методів, мов програмування високого рівня, розрахованих зручне уявлення обчислювальних алгоритмів.
Другий напрямок пов'язаний з використанням обчислювальної техніки для створення, зберігання та обробки великих масивів даних. Такі завдання вирішують інформаційні системи(ІВ). До них належать пошукові, довідкові, банківські системи, автоматизовані системи керування підприємством.
Для завдань першого типу характерні великі обсяги обчислювальної роботи за відносно невеликих потреб у пам'яті. Завдання другого типу, навпаки, вимагають великих обсягів зовнішньої пам'яті за відносно невеликих розрахунків. Друга сфера застосування виникла трохи пізніше першої. Це з тим, що у перших етапах зовнішня пам'ять обчислювальних систем була недосконалою, тобто. надійне зберігання великих обсягів даних було неможливо.
Для полегшення обробки інформації створюються інформаційні системи. Інформаційна система є апаратно-програмний комплекс, що забезпечує виконання наступних функцій:
· Введення даних про об'єкти деякої предметної області;
· надійне зберігання та захист даних у зовнішній пам'яті обчислювальної системи;
· Доповнення, видалення, зміна даних;
· Сортування, вибірка даних за запитами користувачів;
· Виконання специфічних для даної предметної області перетворень інформації;
· Надання користувачам зручного інтерфейсу; узагальнення даних та складання звітів.
Обсяг даних ІС може обчислюватися мільярдами байт. Звідси потреба пристроїв, що зберігають великі обсяги даних у зовнішній пам'яті. Число користувачів ІС може сягати десятків тисяч, що створює чимало проблем у реалізації ефективних алгоритмів функціонування ІВ. Успішно вирішуються ці завдання, якщо дані в інформаційній системі структуровані.
прикладструктурованих даних – студентська група. Кожен член групи багато в чому індивідуальний, і характеризувати його можна з різних боків. Але деканат, швидше за все, зацікавлять такі дані (предметна область): прізвище студента, ім'я, по батькові, курс, найменування групи, масив оцінок з дисциплін, що вивчаються. Отже, з усього різноманіття даних вибираються лише деякі, тобто. створюється інформаційна модель об'єкта. Дані впорядковуються за порядком прямування, за застосовуваними типами (форматами) даних, після чого вони можуть бути оброблені автоматично, яким є комп'ютер.
Сукупність взаємозалежних даних називається структурою даних. Сукупність структурованих даних, які стосуються однієї предметної області, називається базою даних (БД) . Сукупність програм, що реалізують у БД функції ІВ у зручній для користувача формі, називається системою управління базою даних (СУБД). Програми, які виробляють специфічну обробку даних БД, становлять пакет прикладних програм (ППП). Отже, можна зробити висновок, що ІС- це організаційне об'єднання апаратного забезпечення (АТ), однієї чи кількох баз даних (БД), системи управління базами даних (СУБД) та пакетів прикладних програм (ППП).
Класифікація бази даних.
За технологією обробкиданих БД поділяються на централізовані та розподілені.
ЦентралізованаБД зберігається цілком у пам'яті однієї обчислювальної системи. Якщо система входить до складу мережі, то можливий доступ до цієї бази даних інших систем.
РозподіленаБД складається з кількох, які, можливо, перетинаються або дублюють один одного БД, що зберігаються в пам'яті різних обчислювальних систем, об'єднаних в мережу.
За способом доступу до БД розподіляються на локальний і віддалений (мережевий) доступ.
Локальний доступпередбачає, що СУБД обробляє БД, яка зберігається на тій самій обчислювальній системі.
Віддалений доступ- це звернення до БД, яка зберігається на одній із систем, що входять до комп'ютерної мережі. Віддалений доступ може бути виконаний за принципом файл-сервер або клієнт-сервер.
Архітектура файл-серверпередбачає виділення однієї з комп'ютерів мережі (сервер) на зберігання централізованої БД. Решта комп'ютери мережі (клієнти) виконують роль робочих станцій, які копіюють необхідну частину централізованої БД у пам'ять і відбувається обробка. Однак при великій інтенсивності запитів до централізованої БД збільшується навантаження на мережі, що призводить до зниження продуктивності ІС в цілому.
Архітектура клієнт-серверпередбачає, що сервер, виділений зберігання централізованої БД, додатково виробляє обробку клієнтських запитів. Клієнти отримують через мережу вже оброблені дані. Враховуючи широке поширення БД в різних областях, останнім часом архітектура клієнт-сервер застосовується і на одиночних обчислювальних системах. У цьому випадку клієнт-програма, якій знадобилися дані з БД, посилає запит серверу - програмі, що управляє веденням БД, спеціальною універсальною мовою запитів. Сервер пересилає програмі дані, що є результатом пошуку в БД на її запит. Цей метод зручний тим, що програма - клієнт має утримувати всі функції підтримки та ведення БД, цим; займається сервер. В результаті спрощується написання програм - клієнтів. Крім того, до сервера може звертатися будь-яка кількість клієнтів.
Моделі даних.
Для реалізацій основних функцій ІС використовуються різні принципи опису даних. Ядром будь-якої БД є модель представлення даних.
Модель данихвизначає логічну структуру збережених у базі даних (тобто запровадження якихось угод про способи представлення даних) та взаємозв'язку між ними.
До основних моделей представлення даних належать:
· Ієрархічна
· Мережева
· Реляційна
· Постріляційна
· Багатомірна
· Об'єктно-орієнтована
Найбільшого поширення набула реляційна модель даних, вона є найбільш універсальною і до неї можуть бути зведені інші моделі. Реляційна модель даних орієнтована на організацію даних у вигляді двовимірних таблиць.
Найважливішим поняттям реляційних моделей даних є сутність. Сутність- це об'єкт будь-якої природи, дані про який зберігаються у БД. Дані про сутності зберігаються в двовимірних таблицях, які називають реляційними.
Кожна реляційна таблиця повинна мати такі властивості:
· Один елемент таблиці - один елемент даних;
· Кожен стовпець таблиці містить однорідні за типом дані (цілочисленний, числовий, текстовий, і т.д.);
· Кожен стовпець має унікальне ім'я;
· Число стовпців задається при створенні таблиці;
· Порядок записів щодо може бути довільним;
· Записи не повинні повторюватися;
· Кількість записів щодо не обмежена.
Об'єкти, їх взаємозв'язки та відносини представлені у вигляді таблиць. Формальна побудова таблиць пов'язана з фундаментальним поняттям ставлення(термін реляційнапоходить від англійського слова relation- Відношення).
Для заданих довільних кінцевих множин М 1 , М 2 , ..., M N безліч різноманітних наборів виду (μ 1 , μ 2 , …, μ Ν), де μ 1 Є М 1 , μ 2 Є М 2 , …, μ Ν Є M N називають їх декартовим твором М 1 ×М 2 ×...×M N . Відношенням R, визначеним на множині М 1 , М 2 , ..., M N , називається підмножина декартового твору М 1 × М 2 × ... × M N . При цьому множини М 1 , М 2 , ..., M N називаються доменамивідносини, а елементи декартового твору - кортежамивідносини. Число N визначає ступіньвідносини, кількість кортежів - його потужність.
У реляційній таблиці кожен стовпець має домен (його альтернативна назва поле), а сукупність елементів кожного рядка - кортеж (чи запис).
Рядок заголовків називається схемою відношення.
Наприклад, схема відносини СТУДЕНТ може бути наступною:
СТУДЕНТ (Прізвище, ім'я, по-батькові, факультет, курс, група), тут студент - відношення, а прізвище, ім'я і т.д. - Атрибути.
Щодо кожного конкретного примірника сутності представляється рядком, який називається кортежем(або записом).
Наступна таблиця представляє ставлення СТУДЕНТ
| ПРІЗВИЩЕ | Ім'я | ПО БАТЬКУ | ФАКУЛЬТЕТ | КУРС |
| Іванов | Іван | Іванович | ІЕФ | |
| Петров | Петро | Петрович | РТФ | |
| Сидорів | Антон | Єгорович | ВТ |
Первинним ключемВідношення називається поле або група полів, що однозначно визначають запис. Щодо СТУДЕНТ первинним ключем може бути поле Прізвище, якщо у всьому немає однофамільців - це буде простийключ. Якщо є однофамільці, то сукупність полів – прізвище, ім'я, по батькові – створять складовийпервинний ключ. Насправді зазвичай як ключового вибирають поле, у якому збіги свідомо виключені.
Для прикладу таким полем може бути номер залікової книжки студента.
Властивостіпервинного ключа:
· Унікальність - в таблиці може бути призначений тільки один первинний ключ, у складеного ключа поля можуть повторюватися, але не всі;
· Надмірність - не повинно бути полів, які, будучи віддаленими з первинного ключа, не порушать його унікальність;
· До складу первинного ключа не повинні входити поля типу, коментар та графічне.
Щоб уникнути записів, що повторюються, приходять до зв'язування таблиць. Наприклад, якщо щодо СТУДЕНТ треба описати ВНЗ, в якому він навчається, то, на перший погляд, можна було б включити у відношення такі поля СТУДЕНТ (Прізвище ім'я, по-батькові, факультет, курс, група, назва ВНЗ, АДРЕСА). Але при заповненні такої таблиці для кожного студента доведеться вказувати досить довгу назву ВНЗ та його адресу, що незручно. Більше того, будь-яка незначна помилка у введенні цих полів призведе до порушення несуперечності бази даних. Наприклад, помилка на адресу вузу призведе до того, що в БД з'являться два вузи з однаковим найменуванням та різними адресами. Вступають у такому разі так: стосовно СТУДЕНТ вводять поле «код вузу» (ціле число) і додають ще одне відношення ВНЗ (код вузу, назва, адреса). Тоді відносини СТУДЕНТ та ВНЗ при цьому будуть пов'язані по полю «код вишу».
СТУДЕНТ (Прізвище, ім'я, по-батькові, факультет, курс, група, код вузу)
ВНЗ (КІД вузу, НАЗВА, АДРЕСА, ТЕЛЕФОН)
Працюючи з такими таблицями повторюватися можуть лише дані у полі «КІД вузу», проте необхідні відомості про вуз можна взяти з відношення ВНЗ. Зауважимо при цьому, що введення в поле «КІД вузу» цілого числа, замість довгої назви, принесе набагато менше помилок. Щодо ВНЗ поле «КІД вузу» буде первинним ключем, а щодо СТУДЕНТ поле «КІД вузу» буде зовнішнім ключем.
Для зв'язку реляційних таблиць необхідно ввести в обидві таблиці однакові за типом поля, якими визначиться зв'язок між записами обох таблиць. Зв'язки бувають кількох типів "один до одного", "один до багатьох", "багато до багатьох". У наведеному вище прикладі була встановлена зв'язок «один до багатьох», тобто. одного запису у таблиці ВНЗ відповідають багато записів у таблиці СТУДЕНТ.
Інформаційні об'єкти та зв'язки.
Інформаційним об'єктомназивається опис реального об'єкта, процесу або явища у вигляді сукупності його характеристик (інформаційних елементів), які називаються реквізитами. Інформаційний об'єкт певної структури (реквізитного складу) утворює тип (клас), якому надають унікальне ім'я. Інформаційний об'єкт із конкретними характеристиками називають екземпляром. Кожен екземпляр ідентифікується завданням ключового реквізиту (ключа). Одні й самі реквізити у різних інформаційних об'єктах може бути як ключовими, і описовими. Інформаційний об'єкт може мати кілька ключів.
приклад. Інформаційний об'єкт СТУДЕНТ має реквізитний склад: номер(Номер залікової книжки - ключовий реквізит), прізвище, ім'я, по-батькові, дата народження, код місця навчання. Інформаційний об'єкт ОСОБИСТА СПРАВА: номер студента, Домашня адреса, номер атестатуо середній освіті, сімейний стан, діти. Інформаційний об'єкт МІСЦЕ НАВЧАННЯ включає реквізит, код(ключовий реквізит), найменування вузу, факультет, група. Інформаційний об'єкт Викладач: код(ключовий реквізит), Кафедра, прізвище, ім'я, по-батькові, наукова ступінь, вчене звання, посада.
Відносини, що існують між реальними об'єктами, визначаються в інформаційних моделях як зв'язку . Існує три види зв'язків: один до одного (1:1), один до багатьох(1:∞) та багато хто до багатьох (∞:∞).
Зв'язок один до одного визначає відповідність одному екземпляру інформаційного об'єкта X трохи більше одного екземпляра інформаційного об'єкта Y, і навпаки.
приклад. Інформаційні об'єкти СТУДЕНТ та ОСОБИСТА СПРАВА будуть пов'язані ставленням один до одного. Кожен студент має певні унікальні дані щодо особистої справи.
При зв'язку один до багатьох одному примірнику інформаційного об'єкта X може відповідати будь-яка кількість примірників інформаційного об'єкта Y, але кожен екземпляр об'єкта Y пов'язаний не більше ніж з одним екземпляром об'єкта X.
приклад. Між інформаційними об'єктами МІСЦЕ НАВЧАННЯ та СТУДЕНТ необхідно встановити зв'язок один до багатьох. Те саме місце навчання може багаторазово повторюватися для різних студентів.
Зв'язок багато хто до багатьох передбачає відповідність одному екземпляру інформаційного об'єкта X будь-яку кількість екземплярів об'єкта Y, і навпаки.
приклад. Інформаційні об'єкти СТУДЕНТ та Викладач мають зв'язок багато до багатьох. Кожен студент навчається у багатьох викладачів, а кожен викладач навчає безліч студентів.
У Access можна встановити три види зв'язків між таблицями: один до багатьох, багато хто до багатьохі один до одного. Зв'язок один до багатьохє найчастіше використовуваним типом зв'язку між таблицями. Зв'язки багато хто до багатьохреалізується лише за допомогою третьої (сполучної) таблиці, ключ якої складається з, принаймні, двох полів, одне з яких є загальним із таблицею X, а інше - загальним із таблицею Y. Зв'язок один до одноговикористовують не дуже часто, оскільки такі дані можуть бути розміщені в одну таблицю. Зв'язок із ставленням один до одноговикористовують для поділу дуже широких таблиць, відділення частини таблиці з міркувань захисту, і навіть для збереження відомостей, які стосуються підмножини записів у головній таблиці.
Подібна інформація.
База даних як інформаційна модель предметної галузі
Будь-яку предметну область можна як динамічне інформаційне полі, що охоплює властивості об'єктів, їх взаємозв'язку, інформаційні потоки з-поміж них тощо. Зміни, що відбуваються в предметній області, призводять до генерації нової інформації, нових інформаційних елементів або їх зміни, що дозволяє говорити про інформаційне поле і, більше того, динамічне інформаційне поле. Але при цьому виникає питання, яким чином інформаційне поле предметної області відображається на інформаційному просторі баз даних або, іншими словами, які складові предметної області і наскільки повно відображаються в базах даних.
База даних є інформаційною моделлю предметної області.
Інформаційна модель визначає об'єкти та зв'язки між ними. Розробка інформаційної моделі предметної області включає визначення об'єктів предметної області, безлічі атрибутів, що описують властивості цих об'єктів, та встановлення зв'язків між об'єктами.
Усі безліч об'єктів предметної області розбивають на групи однотипних об'єктів, які мають однаковий набір атрибутів (властивостей). Щоб відрізняти кожен об'єкт предметної області від інших об'єктів даного типу, йому призначають певний ідентифікатор, що дозволяє однозначно посилатися на нього. Такий ідентифікатор називається первинним ключем. Як первинний ключ може використовуватися будь-який атрибут або комбінація декількох атрибутів об'єктів. Крім того, використовуються не унікальні ідентифікатори, звані зовнішніми ключами(вторинними ключами) та позначають безліч об'єктів даного типу. До кожної такої множини відносяться об'єкти, яким відповідає однакове значення зовнішнього ключа.
Між об'єктами предметної області можуть існувати зв'язки, що мають різний зміст. Ці зв'язки можуть бути обов'язковими та факультативними (необов'язковими). Обов'язковий зв'язок ЗАМІЩАЄ існує, наприклад, між двома типами об'єктів СПІВРОБІТНИК і ПОСАДА в предметній області «Відділ кадрів організації». Кожен співробітник зараховується на якусь посаду, і не може бути співробітника, який не заміщає якоїсь посади. У той самий час зв'язок ЗАМІЩУЄТЬСЯ між типами об'єктів ПОСАДА і СПІВРОБІТНИК є факультативної, т.к. можуть бути вакантні посади.
Зв'язки між типами об'єктів можуть бути будь-якої розмірності (арності). Найчастіше використовуються бінарні зв'язки, що встановлюють різні відповідності між об'єктами 2-х типів - "один до одного" (1:1), "один до багатьох" (1: n), багато до багатьох" (m: n).
Сукупність типів об'єктів і типів зв'язків з-поміж них характеризує структуру предметної області.
Розглянемо побудову інформаційної моделі предметної області з прикладу. Як предметну область візьмемо вищий навчальний заклад. Одне із завдань, пов'язане з організацією прийому до вузу, - облік відомостей про абітурієнтів. Інтерес представляє наступна інформація: факультет, спеціальність, на яку подаються документи, анкетні дані (прізвище, ім'я, по батькові, рік народження, сімейний, соціальний стан тощо), іспити та оцінки з них. Абітурієнт характеризується унікальним ідентифікатором Id*, що дозволяє однозначно визначати конкретного абітурієнта.
Крім того, відомо про існування таких зв'язків:
ФАКУЛЬТЕТ ®®СПЕЦІАЛЬНОСТІ;
ФАКУЛЬТЕТ ®® Id*;
СПЕЦІАЛЬНІСТЬ ®® Id*;
Id* ®® ПРЕДМЕТ;
Id* ® Прізвище абітурієнта, ім'я, по-батькові, РІК НАРОДЖЕННЯ, …;
Id* ® ПРЕДМЕТ, ОЦІНКА;
ФАКУЛЬТЕТ ® ДЕКАН, НОМЕР ТЕЛЕФОНУ;
ШИФР СПЕЦІАЛЬНОСТІ ® НОМЕР, НАЗВА СПЕЦІАЛЬНОСТІ.
Тут ® - зв'язок типу 1: n; ® – зв'язок типу 1:1.
Тепер розглянемо інформаційну модель тієї частини предметної області, яка пов'язана з організацією прийому до вузу (рис. 1), попередньо виділивши об'єкти "АБІТУРІЄНТ", "ФАКУЛЬТЕТ", "СПЕЦІАЛЬНІСТЬ" та "ПРЕДМЕТ" та формалізувавши зв'язки.
Рис.1. Інформаційна модель згідно з об'єктним аналізом
Об'єкти інформаційної моделі надаються таблицями в реляційній базі даних. Стовпці таблиці задають атрибути об'єктів, рядки таблиці відповідають об'єктам даного типу.
Для завдання зв'язків між об'єктами у реляційній базі даних використовуються первинні та зовнішні ключі. Для визначення зв'язку 1:1 первинний ключ однієї таблиці міститься й у 2-ю таблицю як первинний ключ. Для визначення зв'язку 1: n до другої таблиці додається первинний ключ першої таблиці, але як зовнішній ключ, що вказує на первинний ключ першої таблиці.
Таким чином, базу даних можна розглядати як інформаційну модель предметної області, оскільки в ній знаходять відображення об'єкти, їх властивості та взаємозв'язки між ними – елементи інформаційної структури предметної галузі. Повнота відображення цих елементів визначається результатами етапу інформаційного моделювання.
Діаграма ER-типу:
Спрощення:
1. Розглядаються лише ті мешканці, які мають квартиру.
2. Мешканець може бути зареєстрований лише в одній квартирі.
3. Враховуються лише населені квартири, в яких зареєстровано мешканців.
4. В одній квартирі може бути зареєстровано кілька мешканців.
5. Для однієї квартири один номер телефону.
6. Не у будь-якій квартирі може бути телефон.
7. Є мешканці без джерела доходу (діти).
8. Один житель може мати кілька джерел доходу.
9. Різні види прибутку в різних жителів.
10. Є види доходів, що не використовуються.
Кінець роботи -
Ця тема належить розділу:
Порівняння однотабличної та багатотабличної баз даних
На сайті сайт читайте: "порівняння однотабличною та багатотабличною баз даних"
Якщо Вам потрібний додатковий матеріал на цю тему, або Ви не знайшли те, що шукали, рекомендуємо скористатися пошуком по нашій базі робіт:
Що робитимемо з отриманим матеріалом:
Якщо цей матеріал виявився корисним для Вас, Ви можете зберегти його на свою сторінку в соціальних мережах:
| Твітнути |
Всі теми цього розділу:
Компоненти БНД
Словник даних - "сховище" метаінформації.
Метаінформація – інформація
Етап визначення підсхем
У деяких СУБД є можливість описати логічну структуру БД з погляду конкретної групи користувачів. Така модель називається зовнішньою, а її опис – підсхе.
Інфологічне моделювання предметної галузі. Склад інфологічної моделі (ІЛМ)
1-2. Опис предметної області представляється за допомогою будь-якої знакової системи, тому
Опис об'єктів та їх властивостей. Різновиди властивостей об'єктів
Клас об'єктів – сукупність об'єктів, які мають однаковий набір властивостей.
Класи об'єктів можуть бути як матеріальними, так і абстрактними (наприклад, предмети, як
Діаграма ER-типу
Тип зв'язку 1 до 1. Клас приналежності об'єктів для П і для К необязател
Різновиди складних об'єктів
1. Складовий об'єкт.
2. Узагальнений об'єкт.
3. Агрегований об'єкт.
Складовий об'єкт
Для прискорення доступу до інформації у файлі здійснюється індексування файлу. Як індексний ключ при індексації використовується атрибут або набір атрибутів, визначений щодо. Частина
Метод проектування РБД на основі ІЛМ (правила 1-12)
1. Для кожного простого об'єкта та його одиничних властивостей будується відношення, атрибути якого є ідентифікаторами об'єкта та реквізити відповідають кожному з одиничних властивостей
Визначення складу БД та відносин
Принцип синтезування: До складу БД включають атрибути всіх сутностей + дохід SumD, що обчислюється.
БД складається з 5 відносин: PERSON (Nom, FIO, Rdate, Pol, S
Порівняння однотабличної та багатотабличної баз даних
Можуть виникати проблеми з вставкою, оновленням, видаленням.
Проблема вставки У будь-якій БД не повинно бути полів із невизначеними чи порожніми значеннями.
Наприклад: для од
Structured Query Language
Конкретні реалізації SQL враховують вимоги стандарту, але надають додаткові можливості (SQL1, SQL2(1992), SQL3(1999)) SQL можна використовувати у 2-х режимах: 1. Инт<>, <, >, <=, >Пропозиція Select
Як ТРЗ може бути ім'я стовпця, константа, вираз.
Ім'я стовпця ідентифікує один із стовпців, що містяться в таблиці, яка вказана у реченні FROM. Воно може бути вказано
Вказує, які рядки потрібно відбирати. Визначається умова пошуку, як критерій відбору.
Види умов пошуку: 1. Порівняння. =,
=.
2. Прові
Складові умови пошуку. Таблиці істинності
AND true false null OR true
Агрегатні функції мови SQL
Підсумкові запити можна скласти із різних операторів та агрегатних функцій мови. Усі функції приймають як аргумент будь-який стовпець даних цілком, а повертає одне, підсумоване зн
Запити з угрупуванням та обмеження на них
SELECT *FROM PERSON WHERE EXISTS (SELECT ID FROM HAVE_D, PROVIT WHERE PROVIT.ID
Додавання нових елементів
Найменшою одиницею інформації, яку можна додати до бази даних, є один рядок.
Існує 2 способи додавання нових рядків: 1) однорядковий оператор INSERT, що включають
Видалення існуючих даних
Найменшою одиницею інформації, яку можна видалити з БД, є 1 рядок. Для видалення рядків із 1-ї таблиці використовується оператор DELETE.
DELETE FROM – ім'я_таблиці -------------------
Умови унікальності даних
Візьмемо таблицю PERSON, опишемо її структуру: CREATE TABLE PERSON (INTERBASE) (NOM INTEGER NOT N
Зміна визначення таблиці
ALTER TABLE служить для: 1. додати визначення нового шпальти.
2. змінити значення за промовчанням.
3. змінити чи видалити первинний ключ таблиці.
Індекси
Індекс – це засіб, який забезпечує швидкий доступ до рядків таблиці на основі значення одного або кількох стовпців. В індексі зберігаються значення даних та покажчики на рядок
Друга фаза аналізу предметної області полягає у виборі інформаційних об'єктів, завданні необхідних властивостей для кожного об'єкта, виявленні зв'язків між об'єктами, визначенні обмежень, що накладаються на інформаційні об'єкти, типи зв'язків між ним, характеристики інформаційних об'єктів.
При виборі інформаційних об'єктів необхідно відповісти на низку питань:
1. На які таблиці можна розбити дані, що підлягають зберіганню у БД?
2. Яке ім'я можна надати кожній таблиці?
 |
|||
3. Які найцікавіші характеристики (з погляду користувача) можна назвати?
4. Які імена можна надати вибраним характеристикам?
У разі передбачається завести такі таблиці (рис 4):
Виділимо зв'язок між інформаційними об'єктами (рис.5)
У ході цього процесу необхідно відповісти на такі питання:
1. Які типи зв'язків між інформаційними об'єктами?
2. Яке ім'я можна надати кожному типу зв'язків?
3. Які можливі типи зв'язків, які можуть бути використані згодом?
Спроба встановити обмеження на об'єкти, їх характеристики та зв'язки призводить до необхідності відповіді на такі питання:
1. Яка область значень для числових показників?
Побудова концептуальної моделі
У найпростіших випадках для побудови концептуальної схеми використовують традиційні методи агрегації та узагальнення. При агрегації об'єднуються інформаційні об'єкти (елементи даних) на один відповідно до семантичними зв'язками між об'єктами. Наприклад, урок історії у 10 «а» класі проводиться у кабінеті №7, початок о 9-30. Методом агрегації створюємо інформаційний об'єкт (сутність) РОЗКЛАД із наступними атрибутами: «клас», «предмет», «кабінет», «час». При узагальненні інформаційні об'єкти (елементи даних) поєднуються в родовий об'єкт (рис.7):
Вибір моделі диктується насамперед характером предметної галузі та вимогами до БД. Іншою важливою обставиною є незалежність концептуальної моделі від СУБД, яка має бути обрана після побудови концептуальної схеми.
Моделі «сутність-зв'язок», що дають можливість представляти структуру та обмеження реального світу, а потім трансформувати їх відповідно до можливостей промислових СУБД, є досить поширеними.
Під сутністю розуміють основний зміст того явища, процесу чи об'єкта, про який збирають інформацію для БД. Як сутність можуть виступати місце, річ, особистість, явище тощо. При цьому розрізняють тип сутності та екземпляр сутності. Під типом сутності зазвичай розуміють набір однорідних об'єктів, що є ціле. Поняття «примірник сутності» належить до конкретного предмета. Наприклад:
Тип сутності – учень
Примірник сутності - Іванов, Петров, Сидоров та інших.
У прикладі Школа, Клас, Предмети, Учні, Вчителі, Оцінки – сутності. Проаналізуємо зв'язок між сутностями (рис.8).
Тепер можна перейти до проектування інформаційної (концептуальної) схеми БД (атрибути сутності на діаграмі не показані) (рис.9).
 належить | Школа | |||
 Клас | Вчиться | Учень | ||
  | ||||
| працює | вивчає | |||
 | ||||
| Вчитель | Викладає | Предмет | ||
 | іспит | |||
| Відомість |
Логічне проектування
Логічне проектування є необхідним етапом під час створення БД. Основним завданням логічного проектування є розробка логічної схеми, орієнтованої обрану систему управління базами даних. Процес логічного проектування складається з наступних етапів:
1. Вибір конкретної СУБД;
2. Відображення концептуальної схеми на логічну схему;
3. Вибір мови маніпулювання даними.
Вибір конкретної СУБД
Одним із основних критеріїв вибору СУБД є оцінка того, наскільки ефективно внутрішня модель даних, яку підтримує система, здатна описати концептуальну схему. Системи управління базами даних, орієнтовані персональні комп'ютери, зазвичай підтримують реляційну чи мережну модель даних. Переважна більшість сучасних СУБД – реляційні.
Конструювання баз даних на основі реляційної моделі має низку важливих переваг перед іншими моделями
· Незалежність логічної структури від фізичного та користувальницького уявлення.
· Гнучкість структури бази даних – конструктивні рішення не обмежують можливості розробника БД виконувати у майбутньому найрізноманітніші запити.
Так як реляційна модель не вимагає опису всіх можливих зв'язків між даними, згодом розробник може запитувати будь-які логічні взаємозв'язки, що містяться в базі, а не тільки про ті, які планувалися спочатку.
Інфологічна модель (інформаційно-логічна модель)- орієнтована на людину і не залежна від типу СУБД модель предметної галузі, що визначає сукупності інформаційних об'єктів, їх атрибутів та відносин між об'єктами, динаміку змін предметної галузі, а також характеру інформаційних потреб користувачів. Інфологічна модель предметної області може бути описана моделлю "сутність-зв'язок" (моделлю Чена), в основі якої лежить поділ реального світу на окремі помітні сутності, що знаходяться в певних зв'язках один з одним, причому обидві категорії - сутність та зв'язок вважаються первинними, невизначеними поняттями .
Мета інфологічного моделювання
- забезпечення найбільш природних для людини способів збору та подання тієї інформації, яку передбачається зберігати у створеній базі даних. Тому інфологічну модель даних намагаються будувати за аналогією з природною мовою (остання не може бути використана в чистому вигляді через складність комп'ютерної обробки текстів та неоднозначність будь-якої природної мови). Основними конструктивними елементами інфологічних моделей є сутності, зв'язок між ними та його властивості (атрибути).
Основні поняття
- Сутність- будь-який помітний об'єкт (об'єкт, який ми можемо відрізнити від іншого), інформацію про який необхідно зберігати в базі даних. Сутностями можуть бути люди, місця, літаки, рейси, смак, колір тощо. Необхідно розрізняти такі поняття, як тип сутності та екземпляр сутності. Поняття «тип сутності» відноситься до набору однорідних особистостей, предметів, подій або ідей, що виступають як ціле. Примірник сутності відноситься до конкретної речі в наборі. Наприклад, типом сутності може бути МІСТО, а екземпляром – Москва, Київ тощо.
- Атрибут- Поіменована характеристика сутності. Його найменування має бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДИМ тощо). Атрибути використовуються визначення того, яка інформація має бути зібрана про сутності. Прикладами атрибутів для сутності АВТОМОБІЛЬ є ТИП, МАРКА, НОМЕРНИЙ ЗНАК, КОЛІР тощо. Тут також існує різниця між типом та екземпляром. Тип атрибуту КОЛІР має багато екземплярів або значень: Червоний, Синій, Банановий, Біла ніч і т.д., проте кожному екземпляру сутності надається лише одне значення атрибута.
Абсолютна різниця між типами сутностей та атрибутами відсутня. Атрибут є лише у зв'язку з типом сутності. В іншому контексті атрибут може бути самостійною сутністю. Наприклад, для автомобільного заводу колір – це лише атрибут продукту виробництва, а лакофарбової фабрики колір – тип сутності.
- Ключ- Мінімальний набір атрибутів, за значеннями яких можна однозначно знайти необхідний екземпляр сутності. Мінімальність означає, що виняток із набору будь-якого атрибуту не дозволяє ідентифікувати сутність по решті. Для сутності Розклад ключем є атрибут Номер_рейсу або набір: Пункт_відправлення, Час_вильоту та Пункт_призначення (за умови, що з пункту в пункт вилітає в кожний момент часу один літак).
- Зв'язок- Асоціювання двох або більше сутностей. Якби призначення бази даних було лише зберігання окремих, не пов'язаних між собою даних, то її структура могла б бути дуже простою. Однак одна з основних вимог до організації бази даних - це забезпечення можливості віднайти одних сутностей за значеннями інших, для чого необхідно встановити між ними певні зв'язки. Оскільки в реальних базах даних нерідко містяться сотні і навіть тисячі сутностей, то теоретично з-поміж них може бути більше мільйона зв'язків. Наявність такої множини зв'язків і визначає складність інфологічних моделей.
Вимоги до інфологічної моделі
- Адекватне відображення предметної області
- Недопущення неоднозначного трактування моделі
- Чітке визначення предметної області, що моделюється (кінцевість моделі)
- Легка розширюваність, що забезпечує введення нових даних без зміни раніше визначених, те ж саме відносять і до видалення даних
- Можливість композиції та декомпозиції моделі у зв'язку з великою розмірністю реальних інфологічних моделей
- Легке сприйняття різними категоріями користувачів; бажано, щоб інфологічну модель будував (чи хоча б брав участь у її створенні) фахівець, який працює в даній предметній галузі, а не тільки проектувальник систем машинної обробки даних
- Застосування мови специфікацій моделі як при ручному, так і при автоматизованому проектуванні інформаційних систем
Компоненти інфологічної моделі
- Опис об'єктів та зв'язків між ними, званою ER-моделлю (розшифровується як модель "Сутність-зв'язок")
- Опис інформаційних потреб користувачів
- Алгоритмічні зв'язки атрибутів
- Лінгвістичні відносини, зумовлені особливостями зображення предметної області в мовному середовищі
- Обмеження цілісності
Побудова моделі "Об'єкт - свійство - ставлення"
Класи об'єктів
У предметній області у процесі її обстеження та аналізу виділяють класи об'єктів. Класом об'єктів називають сукупність об'єктів, які мають однаковий набір властивостей. Наприклад, якщо як предметну область розглянути вуз, то в ній можна виділити такі класи об'єктів: учні, викладачі, аудиторії і т. д. Об'єкти можуть бути реальними, як названі вище, а можуть бути і абстрактними, як, наприклад, предмети які вивчають студенти.
При відображенні в інформаційній системі кожен об'єкт представляється своїм ідентифікатором, який відрізняє один об'єкт класу від іншого, а кожен клас об'єктів є ім'ям цього класу. Так, для об'єктів класу «ПРЕДМЕТИ, що вивчаються» ідентифікатором кожного об'єкта буде «НАЗВА ПРЕДМЕТА». Ідентифікатор має бути унікальним.
Кожен об'єкт має певний набір властивостей. Для об'єктів одного класу набір цих властивостей однаковий, які значення, звісно, можуть відрізнятися. Наприклад, для об'єктів класу «СТУДЕНТ» таким набором властивостей, що описує об'єкти класу, може бути «РІК НАРОДЖЕННЯ», «ПОЛ» та ін.
При описі предметної області треба зобразити кожен із існуючих класів об'єктів і набір властивостей, що фіксується об'єктів даного класу.
Будемо використовувати для відображення об'єктів та їх властивостей такі позначення.
Кожному класу об'єктів в інфологічній моделі надається унікальне ім'я. Іменем класу об'єктів є граматичний оборот іменника (іменник, у якого можуть бути прикметники та прийменники). Якщо ім'я складається з кількох слів, то бажано, щоб першим стояло іменник. Іменник має вживатися в єдиному, а не у множині. Тому для розглянутого вище класу об'єктів «ДИСЦИПЛІНИ, які вивчаються», краще дати ім'я «ДИСЦИПЛІНА ВИВЧУВАНА». Якщо в предметній області традиційно використовуються різні імена для позначення будь-якого класу об'єктів (тобто має місце синонімія), то всі вони повинні бути зафіксовані при описі системи, потім одне з них вибирається за основне, і тільки воно має використовуватися надалі в ІЛМ. Крім імені класу об'єктів ІЛМ може використовуватися його коротке кодове позначення.
При побудові інфологічної моделі бажано дати словесну інтерпретацію кожної сутності, якщо можливо неоднозначне тлумачення поняття.
Зв'язки між об'єктом та його властивостями
При описі предметної області треба відобразити зв'язки між об'єктом і властивостями, що його характеризують. Це зображується просто у вигляді лінії, що з'єднує позначення об'єкта та його властивостей.
Зв'язок між об'єктом та його властивістю може бути різним. Об'єкт може мати лише одне значення якогось властивості. Наприклад, кожна людина може мати лише одну дату народження. Назвемо такі властивості одиничними. Для інших властивостей можливе існування одночасно кількох значень одного об'єкта. Нехай, наприклад, при описі «СПІВРОБІТНИКА» фіксується як його властивість «ІНОЗЕМНА МОВА», якою вона володіє. Оскільки співробітник може знати кілька іноземних мов, то таку властивість називатимемо множинним. При зображенні зв'язку між об'єктом та його властивостями для одиничних властивостей будемо використовувати одинарну стрілку, а для багатьох властивостей - подвійну.
Крім того, деякі властивості є постійними, їх значення не може змінитися з часом. Назвемо такі властивості статичними, а властивості, значення яких може змінюватися з часом, будемо називати динамічними.
Інший характеристикою зв'язку між об'єктом та його властивістю є ознака того, чи є ця властивість у всіх об'єктів даного класу або відсутня у деякими об'єктів. Наприклад, для окремих службовців може мати місце властивість «ВЧЕНИЙ СТУПЕНЬ», а інші об'єкти цього класу можуть не мати зазначену властивість. Назвемо такі властивості умовними.
При зображенні зв'язку умовного властивості з об'єктом будемо використовувати пунктирну лінію, а позначення динамічних і статичних властивостей будемо використовувати літери D і S над відповідною лінією.
Іноді в інфологічній моделі корисно ввести поняття «складова властивість». Прикладами таких властивостей можуть бути «АДРЕСА», що складається з «МІСТА», «ВУЛИЦІ», «БУДИНКИ» та «КВАРТИРИ», і «ДАТА НАРОДЖЕННЯ», що складається з «ЧИСЛА», «МІСЯЦЯ» та «РОКУ». Використовуємо в ІЛМ для позначення складової властивості квадрат, з якого виходять лінії, що з'єднують його з позначеннями елементів, що його складають.
Зв'язки між об'єктами
Крім зв'язку між об'єктом та його властивостями, в інфологічній моделі фіксуються зв'язки між об'єктами різних класів. Розрізняють зв'язки типу:
- «один до одного» (1:1): у кожний момент часу кожному представнику (примірнику) сутності А відповідає 1 або 0 представників сутності:
- "один до багатьох" (1: М): одному представнику сутності А відповідають 0, 1 або кілька представників сутності Ст.
- «багато до одного» (М:1)
Іноді ці типи зв'язків називаються ступенем зв'язку. Крім ступеня зв'язку в інфологічній моделі для характеристики зв'язку між різними сутностями треба вказувати так званий клас приналежності, який показує, чи може бути відсутній зв'язок об'єкта даного класу з будь-яким об'єктом іншого класу. Клас власності сутності повинен бути або обов'язковим, або необов'язковим.
Пояснимо сказане на конкретних прикладах. Як зазначалося вище, інфологічна модель будується задля окремого об'єкта, а відображає класи об'єктів та зв'язку з-поміж них. Відповідна діаграма, що відображає це, називається діаграмою ER-типу (така назва обумовлена тим, що англійською слово "сутність" пишеться "Entity", а зв'язок - "Relationship"). Однак іноді, крім діаграм ER-типу, використовуються діаграми ER-примірників.
Припустимо, що в інфологічній моделі відображається зв'язок між двома класами об'єктів: «ОСОБИСТІСТЬ» і «МОВА ІНОЗЕМНА». -
Припустимо, що предметною областю є завод, деякі співробітники якого знають іноземну мову, але жодна з них не володіє більш ніж однією мовою. Природно, що є багато мов, якими не володіє жоден із співробітників, а також деякі з співробітників володіють однією і тією ж іноземною мовою.
Припустимо далі, що предметною областю є інститут, а об'єкт «ОСОБИСТІСТЬ» відображає абітурієнтів, які вступають до цього інституту. Кожен з абітурієнтів обов'язково повинен володіти якоюсь іноземною мовою, але ніхто не володіє більш ніж однією мовою.
Як у першому, і у другому розглянутому разі між сутностями спостерігається ставлення М:1. На діаграмі це відображено з боку об'єкта «ОСОБИСТІСТЬ» подвійною стрілецькою, а з боку об'єкта «МОВА ІНОЗЕМНА» - одинарною стрілкою на лінії, що зображує зв'язок між цими сутностями.
Різниця у аналізованих ситуаціях у тому, що у першому випадку клас власності є необов'язковим обох сутностей, тоді як у другому - для сутності «ОСОБА» клас належності є обов'язковим. На діаграмі це відображено точкою у прямокутнику, який відповідає об'єкту «ОСОБИСТІСТЬ».
Нехай предметна область буде та сама, що й у попередньому випадку, але мають місце ситуації, що деякі абітурієнти знають кілька іноземних мов. І тут зв'язок між об'єктами матиме тип М: М.
Припустимо, що предметною областю є певний лінгвістичний інститут, у якому кожен із співробітників обов'язково знає кілька іноземних мов, і з кожному з відомих науці мов у цьому інституті є хоча б один фахівець, який володіє ним.
У цьому випадку зв'язок між об'єктами» буде М: М, і клас приналежності обох сутностей є обов'язковим».
Прості та складні об'єкти
Об'єкт називається простим, якщо він сприймається як неподільний. Складний об'єкт є об'єднання інших об'єктів, простих або складних, що також відображаються в інформаційній системі. Поняття «простий» та «складний» об'єкт є відносним. В одному розгляді об'єкт може вважатися простим, а в іншому цей об'єкт може розглядатися як складний. Наприклад, об'єкт «стілець» в підсистемі обліку матеріальних цінностей розглядатиметься як простий об'єкт, а для підприємства, що виробляє стільці, це буде складовий об'єкт (що включає «ніжки», «спинку», «сидіння» тощо).
Вирізняють кілька різновидів складних об'єктів: складові об'єкти, узагальнені об'єкти та агреговані об'єкти.
Складовий об'єкт відповідає відображенню відносини «ціле-частина». Прикладами складових об'єктів є ВУЗЛИ - ДЕТАЛІ, КЛАС-УЧНІ і т.п.
Для відображення складових об'єктів в інфологічній моделі зазвичай не використовуються будь-які спеціальні умовні позначення. Зв'язок між складовим і його складовими об'єктами відображається так само, як це було описано вище. Причому характер зв'язку теж може бути різним: так, «ДЕТАЛІ» та «ВУЗЛИ» пов'язані між собою ставленням типу М: М, а «ГРУПА» та «СТУДЕНТИ» - ставленням 1: М.
Узагальнений об'єкт відбиває наявність зв'язку «рід - вид» між об'єктами предметної області. Наприклад, об'єкти СТУДЕНТ, ШКОЛЬНИК, АСПІРАНТ, УЧЕНИЙ ТЕХНІКУМА утворюють узагальнений об'єкт УЧНІ. Об'єкти, що становлять узагальнений об'єкт, називаються його категоріями.
Як «родовий» об'єкт, так і «видові» об'єкти можуть мати певний набір властивостей. Причому спостерігається так зване успадкування властивостей, тобто «видовий» об'єкт має всі ті властивості, якими має «родовий» об'єкт, плюс властивостями, властивими тільки об'єктам цього виду.
Агреговані об'єкти зазвичай відповідають будь-якому процесу, в який виявляються «залученими» інші об'єкти. Наприклад, агрегований об'єкт «ПОСТАВКА» об'єднує в собі об'єкти «ПОСТАЧАЛЬНИК», який постачає продукцію, «СПОЖИВАЧ», який отримує цю продукцію, а також саму «ПРОДУКЦІЮ». Своєрідним об'єктом є «ДАТА ПОСТАЧАННЯ». Агрегований об'єкт може, так само як і простий об'єкт, мати властивості, що характеризують його. У цьому прикладі такою властивістю може бути розмір поставки.
Порівняння методик побудови ER-моделей
ER-моделі дуже широко використовують у практиці проектування баз даних. Причому вони використовуються як при ручному, так і автоматизованому проектуванні. Методики графічного уявлення ER-моделей дещо різняться у різних системах автоматизації проектування й у різних літературних джерелах.
Далі ми розглянемо особливості представлення ER-моделей у трьох найбільш відомих системах автоматизації проектування (CASE-системах): Prokit*WORKBENCH, Desing/IDEF та CASE ORACLE, а також у деяких літературних джерелах.
Можна виділити кілька категорій відмінностей у зображенні моделей ER.
1. Несуттєві відмінності, пов'язані з використанням різних умовних позначень для відображення тих самих сутностей. Так, для позначення об'єкта можуть використовуватися прямокутники, блоки із закругленими кутами, овали і т.д.
Наступна сукупність відмінностей пов'язана із способом зображення зв'язків між об'єктами та завданням імен зв'язків. Так, в деяких методиках для зображення зв'язку в роз'єм лінії, що відображає цей зв'язок, пропонується зображати ромб і всередині нього або поруч з ним писати назву зв'язку (модель Чена). Оскільки зв'язки є двосторонніми, то найменування зв'язку змінюватиметься залежно від цього, з якого боку її розглядати. Тому часто в ІЛМ пропонується вказувати обидві ці назви (наприклад, у системах CASE ORACLE, Prokit). Причому для того, щоб було зрозуміло, до якого з напрямів зв'язку яка назва відноситься, приймають певні угоди про те, як розташовувати ці назви на схемах. Наприклад, зверху лінії поміщати назви, які стосуються лівої стороні зв'язку, а під лінією - до правої. Наявність такого великого числа позначень та підписів захаращує модель. З іншого боку, саме присвоєння назв часто представляє деяку складність, що підвищує трудомісткість інфологічного моделювання. Тому в тих випадках, коли це не призводить до двозначностей і незрозумілостей, якщо це дозволяє система, можна рекомендувати не використовувати особливі позначення та імена для зв'язків.
Різні умовні позначення використовуються для зображення типу зв'язку (1:1, 1: М, М:М). Деякі системи автоматизації проектування, наприклад Prokit, надають користувачеві можливість вибрати з безлічі можливих позначень ті, які більше подобаються або звичні. У цій системі для позначення виду зв'язків між об'єктами можуть використовуватись такі умовні позначення.
Для відображення обов'язковості входження об'єктів у зв'язок («клас власності/членства») також використовуються різні умовні позначення. Так, у CASE ORACLE клас членства передається так; з того боку зв'язку, з яким елемент може не обов'язково входити у зв'язок, використовується Пунктирна лінія, а там, де обов'язкове членство, - суцільна лінія. З урахуванням класу членства можливі типи відносин, що представлені малюнку.
Використовувані в CASE ORACLE позначення зручніші, оскільки якщо об'єкт бере участь у велику кількість зв'язків, то додаткові прямокутники з точками стає незручно розташовувати малюнку.
У Desing IDEF характер членства у зв'язку зображується, як показано на малюнку.
2. Відмінності, також пов'язані зі способом зображення тих чи інших ситуацій, але суттєвіші, що призводять до відмінностей у самих моделях. Наприклад, у системі 3RACLE узагальнений об'єкт зображується шляхом "вкладання" блоків, що позначають "видові" об'єкти, всередину блоку, що зображує "родовий" об'єкт. На малюнку показано зображення об'єкта «ОСОБИСТІСТЬ», розглянутого вище, в умовних позначеннях, що використовуються в CASE ORACLE.
Як випливає з порівняння малюнків, зображення узагальнених об'єктів у порівнюваних методиках відрізняється як формою уявлення. Так, якщо об'єкт класифікується за різними ознаками, то при використанні першого із розглянутих способів зображення узагальнених об'єктів наочно видно, за якою ознакою здійснюється класифікація. Другий спосіб зображення не забезпечує цього. Іншими словами, запропонований на початку глави спосіб зображення узагальнених об'єктів є семантично більш змістовним, інформативним.
На малюнку зображено той самий узагальнений об'єкт ОСОБИСТІСТЬ з використанням синтаксису системи IDEF1X. За своєю семантикою цей спосіб зображення ближче до запропонованого нами базового способу зображення ІЛМ. Різниця полягає в тому, що для сутностей-категорій та «загальних» сутностей в IDEF1X використовуються однакові позначення-
3. Крім відмінності у зображенні тих чи інших сутностей, теоретично інфологічного моделювання спостерігається розбіжність у використовуваної термінології. Наприклад, CASE ORACLE родовий об'єкт називається супертип (syper-type), а видовий - підтип (sub-type). Таких відмінностей у термінології можна навести багато, але це зараз не є нашою метою.
4. Наступне коло відмінностей пов'язане з просторовим зображенням тих чи інших компонентів ІЛМ. Наприклад, властивості об'єкта іноді не відображаються на тій самій схемі, що об'єкти та зв'язки між ними, а їх описи виконуються окремо. Часто «писання властивостей представляють у табличній чи іншій аналітичній формі, а чи не в графічному вигляді.
ІЛМ навіть для невеликої і нескладної предметної області включає опис значної кількості компонентів і зв'язків між ними. При цьому постає проблема наочності загальної схеми. Ця проблема по-різному вирішується при ручному та автоматизованому побудові інфологічної моделі. В автоматизованих системах найчастіше будується єдине зображення ER-моделі і використовується прийом масштабування, коли, зменшуючи чи збільшуючи масштаб зображення, можна побачити як всю схему, і окремий її фрагмент.
Різні прийоми використовуються для того, щоб зменшити кількість перетинів ліній на схемі. Так, у системі Prokit для цих цілей допускається дублювання зображення об'єкта та розміщення цього дубля поруч із тим об'єктом, з яким його треба зв'язати. Для того щоб показати, що це не новий об'єкт, використовується будь-яке умовне позначення, наприклад, у відповідних блоках відкреслюється куточок.
При ручному проектуванні зобразити всю ER-модель у вигляді єдиної схеми зазвичай неможливо. У цьому випадку можна порекомендувати наступний прийом: зобразити та описати кожен об'єкт самостійно, присвоїти кожному об'єкту короткий код. Використовуючи ці кодові позначення для кожного об'єкта вказати його зв'язки з іншими об'єктами.
5. Деякі можливості, що є в одних системах або методиках, відсутні в інших. У цих випадках можливі різні варіанти: а) для зображення ситуації використовуються можливості, що надаються моделлю, але це вимагає застосування певних прийомів, часто кілька штучних, для їхнього подання; б) ситуація просто не відображається у моделі.
Наприклад, у багатьох системах інфологічного моделювання передбачається, що властивості об'єкта можуть бути лише одиничними. У цьому випадку кожну множину слід представляти як самостійний об'єкт і зображати зв'язок між цим нововведеним об'єктом і вихідним об'єктом.
У IDEF властивості об'єкта може бути лише поодинокі і завжди певні (не умовні). Якщо властивість може бути відсутнім у будь-яких об'єктів, треба виділяти окремі сутності, наприклад, ШТАТНИЙ СЛУЖАЮЧИЙ з атрибутом ОКЛАД і ПОЧАСНИК, що не має такого атрибуту. Це призведе до виділення великої кількості об'єктів і зв'язків в ІЛМ, до зниження наочності моделі. Наприклад, окремі екземпляри об'єкта ОСОБИСТІСТЬ можуть мати або не мати вчене звання, вчений ступінь, рік закінчення вузу та багатьох інших ознак. За кожною з цих ознак доведеться виділяти підкласи.
Деякі методики не запроваджують агрегований об'єкт як самостійну категорію. У цьому випадку агрегований об'єкт зображується як простий, при цьому користувач повинен визначити його ідентифікатор і властивості. Якщо модель допускає зображення лише двійкових зв'язків, то проектувальник повинен перетворити n-арний зв'язок у сукупність бінарних.
Крім зазначених складнощів при визначенні ідентифікатора агрегованої сутності, можуть виникнути і проблеми при переході від ІЛМ до даталогічної моделі.
Варіант, коли ситуація не може бути відображена в ІЛМ, може бути проілюстровано наступним: якщо методика побудови моделі не передбачає фіксацію класу членства у зв'язку, то ця інформація буде просто втрачена.
У деяких CASE-системах є ситуація, коли якась конструкція допускається в системі як проміжна. Наприклад, IDEF і CASE ORACLE відношення М: М допускається як неспецифічне ставлення. Його наявність дозволяється на ранніх стадіях розробки проекту, а надалі воно має бути замінене на специфічне ставлення у вигляді запровадження третьої сутності. Це є недоліком системи, оскільки, по-перше, не всі СУБД вимагають такого перетворення (деякі системи підтримують відношення М:М у явному вигляді), і, по-друге, якщо таке перетворення буде потрібно, його система автоматизації проектування могла б виконати автоматично на етапі даталогічного проектування. Навіть якщо виконується «ручне» проектування, то зазначене перетворення має виконуватися проектувальником на стадії даталогічного проектування, а чи не під час опису предметної області. Крім того, при аналізованому перетворенні на стадії інфологічного проектування в IDEF вводиться нова категорія сутностей - сутності перетину або асоціативні сутності. Введення нових сутностей спричиняє введення в ІЛМ та додаткових зв'язків. Все це разом узяте ускладнює і без того нелегке завдання інфологічного проектування.
У предметній області можуть бути сутності, ідентифікатори яких залежать від ідентифікатора якогось іншого об'єкта. Наприклад, якщо ділянки на підприємстві нумеруються в межах цеху, то ідентифікатор ділянки буде складовим, що включає код цеху і код ділянки. В інфологічній моделі можна обмежитись зазначенням цього складового ідентифікатора. Деякі методики побудови ER-моделей (наприклад, методологія IDEFIX, Prokit) передбачають запровадження особливих видів сутностей та особливих видів відносин для відображення подібних ситуацій. Так, у IDEF сутність, для ідентифікації якої треба розглядати її ставлення до інших сутностей; називається залежною від ідентифікатора сутністю, і її зображення використовується блок із закругленими кутами. А для зображення незалежної від ідентифікації сутності використовується прямокутник. Для зв'язку об'єктів, одне із яких необхідний повної ідентифікації іншого, вводиться поняття ідентифікуючого отношения. Він також вводиться своє умовне позначення. В IDEF для ідентифікуючого відношення використовується суцільна лінія, а для пунктирна, що не ідентифікує.
6. Як зазначалося вище під час розгляду принципів інфологічного моделювання, поняття «об'єкт», «властивість», «ставлення» є відносними. Так, у запропонованій нами базовій інфологічній моделі виділяються різні види об'єктів: прості, складові, агреговані, узагальнені. У деяких системах, наприклад IDEF, такої класифікації об'єктів немає, і натомість використовуються різновиди відносин.
І той, й інший підхід має право існування. Принципової різниці, що тягне за собою якісь суттєві наслідки, у підходах, що порівнюються, немає.
