Класифікація інформаційних систем
За призначенням:
фактографічні(для збереження певних фактів)
документальні(для збереження документів).
За мовами:
За можливістю впровадження власних операторів:
передбачена можливість впровадження операторів підмови даних(DDL,DML) в програми мовами високого рівня - це системи з базовою мовою.
можливість впровадження операторів не передбачена – замкнуті системи.
За парадигмою:
процедурні (у запиті має бути вказано що треба і як це можна отримати)
декларативні (у запиті вказуємо лише бажаний результат)
Підмови:
DDL (data definition language) – описує сутність, атрибути та зв’язки між сутностями, а також дозволяє обмеження цілісності та запису. Результат компіляції операторів в реляційній моделі – набір таблиць.
DML (data manipulation language) – набір операторів для маніпулювання даними.
За локалізацією:
локальні системи(всі дані в одному місці)
розподілені системи
За даталогічною моделлю:
фактографічні
документальні
За архітектурою:
системи телеобробки (1 комп’ютер під’єднаний до кількох терміналів, вся обробка на цьому комп’ютері). Недолік – навантаження на центральний комп’ютер.
файлові сервери. Результат виконання запиту відсилаються на робочу станцію у вигляді файлу. На кожній робочій станції – часткова копія БД. Недолік – значний мережевий трафік та ускладнене керування паралельною роботою, цілісністю.
клієнт-серверна
Функції сервера: приймає та обробляє запити до БД з боку клієнтів, виконує запити і повертає результат, перевіряє права клієнта, забезпечує паралельний доступ.
Функції клієнта: керує інтерфейсом користувача, виконує прикладні програми, генерує запити до БД, формує отримані від сервера дані та відображає користувачу.
Базою даних (БД) називається сукупність відомостей про конкретні об'єкти реального світу в якій-небудь предметній області. Дані запам’ятовуються таким чином, щоб вони були незалежними від програм, що використовують ці дані, а також для пошуку даних у базі даних застосовується єдиний керований спосіб.
База даних – це інтегрована сукупність структурованих і взаємозв'язаних даних, організована за певними правилами, які передбачають загальні принципи опису, зберігання і обробки даних. Зазвичай база даних створюється для предметної області.
Предметна область – це частка реального миру, що підлягає вивченню з метою створення бази даних для автоматизації процесу керування.
Набори принципів, які визначають організацію логічної структури зберігання даних в базі, називаються моделями даних.
В основу формування будь-яких інформаційних баз покладено моделі організації даних для різних рівнів функціональних завдань.
Ядром будь-якої бази даних є модель даних. Модель даних – це безліч структур даних, обмежень цілісності й операцій маніпулювання даними. За допомогою моделі даних можуть бути представлені об'єкти предметної області й взаємозв'язку між ними.
Отже, модель даних — сукупність структур даних і операцій їхньої обробки.
СКБД (систему керування базами даних) ґрунтується на використанні ієрархічної, мережевій або реляційної моделі, на комбінації цих моделей або на деякій їхній підмножині.
Протягом багатьох років переважно використовувалися плоскі таблиці (плоскі БД) типу списків в Excel.
Розглянемо три основних типи моделей даних: ієрархічну, мережну й реляційну.
Ієрархічна модель даних. Ієрархічна структура - це сукупність елементів, зв'язаних між собою за певними правилами. Об'єкти, зв'язані ієрархічними відносинами, утворять орієнтований граф (перевернене дерево).
До основних понять ієрархічної структури відносяться: рівень, елемент (вузол), зв'язок. Вузол — це сукупність атрибутів даних, що описують деякий об'єкт. На схемі ієрархічного дерева вузли подаються вершинами графа. Кожний вузол на більше низькому рівні зв'язаний тільки з одним вузлом, що перебуває на більше високому рівні. Ієрархічне дерево має тільки одну вершину (корінь дерева), не підлеглу ніякій іншій вершині, що знаходиться на найвищому рівні. Залежні (підлеглі) вузли перебувають на другому, третьому й т.д. рівнях. Кількість дерев у базі даних визначається числом кореневих записів.
До кожного запису бази даних існує тільки один (ієрархічний) шлях від кореневого запису.
Мережна модель даних. У мережевій структурі при тих самих основних поняттях (рівень, вузол, зв'язок) кожний елемент може бути пов'язаний з будь-яким іншим елементом.
Реляційна модель даних. Поняття реляційний (англ. relation — відношення) пов'язане з розробками відомого американського фахівця в області систем баз даних Е. Кодда. Ці моделі характеризуються простотою структури даних, зручним для користувача табличним поданням і можливістю використання формального апарата алгебри відношень і реляційного обчислення для обробки даних.
Реляційна модель орієнтована на організацію даних у вигляді двовимірних таблиць. Кожна реляційна таблиця - це двовимірний масив і має наступні властивості:
кожний елемент таблиці - один елемент даних;
всі стовпці в таблиці однорідні, тобто всі елементи в стовпці мають однаковий тип (числовий, символьний і т.д.) і довжину;
кожний стовпець має унікальне ім'я;
однакові рядки в таблиці відсутні;
порядок проходження рядків і стовпців може бути довільним.
Відношення подані у вигляді таблиць, рядки яких відповідають кортежам (записам), а стовпці — атрибутам відносин, доменам, полям.
Поле, кожне значення якого однозначно визначає відповідний запис, називається простим ключем (ключовим полем). Якщо записи однозначно визначаються значеннями декількох полів, то така таблиця бази даних має складений ключ.
Щоб зв'язати дві реляційні таблиці, необхідно ключ першої таблиці увести до складу ключа другої таблиці (можливий збіг ключів); у протилежному випадку потрібно ввести в структуру першої таблиці зовнішній ключ — ключ другої таблиці.
Розрізняють концептуальний, внутрішній і зовнішній рівні подання даних баз даних, яким відповідають моделі аналогічного призначення,
Концептуальний рівень відповідає логічному аспекту подання даних предметної області в інтегрованому виді. Концептуальна модель складається з безлічі екземплярів різних типів даних, структурованих відповідно до вимог СКБД до логічної структури бази даних.
Внутрішній рівень відображає необхідну організацію даних у середовищі зберігання й відповідає фізичному аспекту подання даних. Внутрішня модель складається з окремих екземплярів записів, фізично збережених у зовнішніх носіях.
Зовнішній рівень підтримує приватні подання даних, необхідні конкретним користувачам. Зовнішня модель є підмножиною концептуальної моделі. Можливе перетинання зовнішніх моделей за даними. Логічна структура даних для окремого додатка (завдання) або користувача відповідає зовнішній моделі або підсхемі БД. За допомогою зовнішніх моделей підтримується санкціонований доступ до даних БД додатків (обмежені состав і структура даних концептуальної моделі БД доступних у додатку, а також задані допустимі режими обробки цих даних: введення, редагування, видалення, пошук).
Поява нових або зміна інформаційних потреб існуючих додатків вимагають визначення для них коректних зовнішніх моделей, при цьому на рівні концептуальної й внутрішньої моделі даних змін не відбувається. Зміни в концептуальній моделі, зумовлені появою нових видів даних або зміною їх структур, можуть торкатись не всіх додатків, тобто забезпечується певна незалежність програм від даних. Зміни в концептуальній моделі повинні відбиватися й у внутрішньої моделі, і при незмінній концептуальній моделі можлива самостійна модифікація внутрішньої моделі БД із метою поліпшення її характеристик (час доступу до даних, витрати пам'яті зовнішніх пристроїв і ін.). Таким чином, БД реалізує принцип відносної незалежності логічної й фізичної організації даних.
Проектування бази даних полягає в побудові комплексу взаємозалежних моделей даних.
Найважливішим етапом проектування бази даних є розробка інфологічної (інформаційно-логічної) моделі предметної області, не орієнтованої на СКБД. В інфологічній моделі засобами структур даних в інтегрованому вигляді відображає склад і структуру даних, а також інформаційні потреби додатків (завдань і запитів).
Інформаційно-логічна модель предметної області відображає предметну область у вигляді сукупності інформаційних об'єктів і їхніх структурних зв'язків.
Інфологічна модель предметної області будується першою. Попередня інфологічна модель будується ще на передпроектній стадії й потім уточнюється на наступних стадіях проектування баз даних. Потім на її основі будуються концептуальна (логічна), внутрішня (фізична) і зовнішня моделі.
Структури баз даних для керування даними
Організований набір взаємозалежних файлів даних називається базою даних. Складність роботи з множинними файлами в базі даних вимагає більш конкретного керування, реалізованого системою керування базою даних (СКБД). Хоча постійно створюються всі нові реалізації структур баз даних, існує лише три основних типи: ієрархічна (деревоподібна), мережна і реляційна (таблична) структури баз даних.
Ієрархічна структура даних. У багатьох випадках існує взаємозв'язок між даними, що має назву відношенням "один до багатьох". Це відношення означає, що кожен елемент даних має прямий зв'язок з деяким числом так званих "синів", і, звичайно кожен такий «син», у свою чергу, може мати зв'язок зі своїми «синами». Як випливає з назви, «сини» і «батьки» прямо зв'язані між собою, що робить доступ до даних простим і ефективним. Така система добре ілюструється ієрархічною системою класифікації рослин і тварин, називаною таксономією (ієрархічно побудована система шляхів і результатів від простого до складного в складній системі).
Якщо інформація про ключову ознаку недостатня, то не можна просуватися по дереву. У дійсності, природа ієрархічної системи вимагає явного визначення кожного відношення для того, щоб створити саму структуру і її правила розгалуження. Перевагою такої системи є те, що в ній дуже легко шукати, оскільки вона добре визначена і може відносно легко розширюватися додаванням нових галузей і формулюванням нових правил розгалуження. Для створення ієрархічної структури необхідне знання всіх можливих питань, що можуть задаватися, оскільки ці питання використовуються як основа для розробки правил розгалуження або ключів.
Мережеві структури. Можливості швидкого пошуку, виконуваного в ієрархічній структурі даних, визначаються структурою самого дерева. Атрибутивні і геометричні дані можуть зберігатися в різних місцях, що вимагає встановлення великого числа зв'язків між графічною й атрибутивною частинами БД. У такому випадку потенційне число розгалужень і зв'язаних з ними ключів ієрархічної структури може стати дуже великим. Мережеві БД використовують відношення "багатьох до багатьох", за яким один елемент може мати багато атрибутів, при цьому кожен атрибут зв'язаний явно з багатьма елементами. Для реалізації таких відношень разом з кожним елементом даних може бути зв'язана спеціальною змінною, яка направляє до всіх інших елементів даних, зв'язаних з ним. Замість того, щоб обмежуватися деревоподібною структурою зв'язків, кожен окремий елемент даних може бути прямо зв'язаний з будь-яким місцем бази даних, без уведення відносини "син-батько".
Мережеві структури звичайно розглядаються як удосконалення ієрархічних структур, оскільки вони менш тверді і можуть представляти відношення "багато - до багатьох". Тому вони допускають набагато велику гнучкість пошуку, ніж ієрархічні структури. Також на відміну від ієрархічних структур вони зменшують надмірність даних. Їхнім головним недоліком є те, що у великих БД кількість покажчиків може стати дуже великим, вимагаючи значної витрати пам'яті. Хоча зв'язки між елементами даних більш гнучкі, вони все-таки повинні бути явно визначені за допомогою покажчиків.
Реляційні бази даних. Недоліків великої кількості даних можна уникнути використовуючи ще одну структуру баз даних - реляційну. В ній дані зберігаються як упорядковані записи або рядки значень атрибутів. Атрибути об'єктів групуються в окремих рядках у вигляді так званих відношень, оскільки вони зберігають свої положення в кожному рядку і зв'язані один з одним. Кожний стовпчик містить значення одного атрибута для всього набору об'єктів.
Реляційні системи засновані на наборі математичних принципів, що називаються реляційною алгеброю або алгеброю відношень, що встановлює правила проектування і функціонування таких систем. Оскільки реляційна алгебра ґрунтується на теорії множин, кожна таблиця відносин функціонує як безліч, і перше правило говорить, що таблиця не може мати рядок, що цілком збігається з яким-небудь іншим рядком. Оскільки кожний з рядків унікальний, один або кілька стовпців можуть використовуватися для визначення критерію пошуку заданого значення з першого стовпчика. Такий критерій пошуку називається первинним ключем для пошуку значень в інших колонках бази даних.
Реляційні системи дозволяють збирати дані в досить прості таблиці, при цьому задачі організації даних також прості. За необхідності можна стикувати рядок з однієї таблиці з відповідними рядками з іншої таблиці, використовуючи сполучний механізм, що називається реляційним з'єднанням. Будь-яка кількість таблиць може бути "зв'язана". З'єднання відбувається по рівності значень стовпчика первинного ключа однієї таблиці з іншим стовпчиком другої таблиці. Стовпчик другої таблиці, з яким зв'язаний первинний ключ, називається зовнішнім ключем.
Реляційна модель даних є сукупністю простих двовимірних таблиць – відношень (англ. relation), тобто проста двовимірна таблиця визначається як відношення (безліч однотипних записів об'єднаних однією темою).
Від терміну relation (відношення) походить назва реляційна модель даних. У реляційних БД використовується декілька двовимірних таблиць, в яких рядки називаються записами, а стовпці полями, між записами яких встановлюються зв'язки. Цей спосіб організації даних дозволяє дані (записи) в одній таблиці пов'язувати з даними (записами) в інших таблицях через унікальні ідентифікатори (ключі) або ключові поля.
У медичних звітах, дослідженнях, лабораторних аналізах часто застосовуються і текстові бази даних. У таких програмах об'єднуються можливості бази даних і редактора тексту.
Основні поняття реляційних БД: нормалізація, зв'язки і ключі
До базових поняттями моделі БД відносяться: сутність, зв'язки між ними і їх атрибути (властивості).
Сутність – будь-який конкретний або абстрактний об'єкт в даній наочній області. Сутність – це базові типи інформації, які зберігаються в БД (у реляційній БД кожної сутності призначається таблиця). До сутності можуть відноситися: студенти, клієнти, підрозділи і т.п. Екземпляр сутності і тип сутності - це різні поняття. Поняття тип сутності відноситься до набору однорідних осіб, предметів або подій, промовців як ціле (наприклад, студент, пацієнт). Екземпляр сутності відноситься, наприклад, до конкретної особи в наборі. Типом сутності може бути студент, а екземпляром – Левицький, Мартинович і так далі.
Атрибут – це властивість сутності або типу зв’язку в наочній області. Його назва має бути унікальною для конкретного типу сутності. Наприклад, для сутності студент можуть бути використані наступні атрибути: прізвище, ім'я, по-батькові, дата і місце народження, паспортні дані і так далі. У реляційній БД атрибути зберігаються в полях таблиць.
Зв'язок – взаємозв'язок між сутністю в наочній області. Зв'язки - це з'єднання між елементами БД (у реляційній БД – це з'єднання між записами таблиць). Тип зв’язку – набір асоціацій між сутностями різних типів. Кожному типу зв’язку надається ім’я, яке має описувати призначення цього зв’язку.
Сутність – це дані, які класифікуються за типом, а зв'язки показують, як ці типи даних співвідносяться один з іншим. Якщо описати деяку предметну область в термінах сутність – зв'язок, то отримаємо модель сутність - зв'язок для цієї БД.
Для визначення вигляду є встановлений набір правил, що називаються нормальними формами. Перша нормальна форма затверджує, що таблиця повинна складатися з рядків і стовпчиків і, оскільки стовпчики будуть використовуватися як ключі пошуку, у кожній з них у кожному рядку повинне знаходитися тільки одне значення. Друга нормальна форма вимагає, щоб кожен стовпчик, що не є первинним ключем, цілком залежав від первинного ключа. Це спрощує таблиці і зменшує надлишок обмеженням, що кожен рядок даних може бути знайдений тільки через його первинний ключ. Третя нормальна форма, зв'язана з другою, вимагає, щоб стовпчики, що не є первинним ключем, "залежали" від первинного ключа, у той час, як первинний ключ не залежить від якого-небудь не первинного ключа. Правила нормальних форм були підсумовані Кентом. Принципи нормалізації:
У кожній таблиці БД не повинно бути полів, що повторюються;
У кожній таблиці має бути унікальний ідентифікатор (первинний ключ);
Кожному значенню первинного ключа повинна відповідати достатня інформація про тип сутності або про об'єкт таблиці (наприклад, інформація про успішність, про групу або студентів);
Зміна значень в полях таблиці не повинна впливати на інформацію в інших полях (окрім змін в полях ключа).
2. Види логічного зв'язку.
Зв'язок встановлюється між двома загальними полями (стовпцями) двох таблиць.
Існують зв'язки з відношенням «один-до-багато», «один-до-одного» і «багато-до-багатьох». Зв'язки, які можуть існувати між записами двох таблиць:
один – до - одного, кожному запису з однієї таблиці відповідає один запис в іншій таблиці ( зв’язок “один-до-одного” допускає зв’язок між двома об’єктами, представленими у вигляді таблиць, наприклад, “ПАЦІЄНТ” і “СТАН ОРГАНІЗМУ ПАЦІЄНТА” (кожному пацієнту відповідає конкретний стан організму);
один – до - багатьох, кожному запису з однієї таблиці відповідає декілька записів іншої таблиці (зв’язок “один-до-багатьох” допускає зв’язок з одним об’єктом кількох інших, наприклад, “ПАЦІЄНТ” і “ЛІКАР” (кожному лікарю відповідає кілька пацієнтів);
багато – до - одного, безлічі записів з одній таблиці відповідає один запис в іншій таблиці (зв’язок “багато-до-одного” допускає зв’язок кількох об’єктів з одним об’єктом, наприклад, “ЛІКАР” і “ПАЦІЄНТ” і (пацієнти можуть обслуговуватись в одного лікаря);
багато – до - багатьом, безлічі записів з однієї таблиці відповідає декілька записів в іншій таблиці (зв’язок “багато-до-багатьох” допускає зв’язок кількох об’єктів з кількома іншими, наприклад, “ПАЦІЄНТ” і “ЛІКУВАЛЬНИЙ ЗАКЛАД” (пацієнти можуть обслуговуватися в різних лікувальних закладах) ).
Тип відношення в створюваному зв'язку залежить від способу визначення зв'язуваних полів:
Відношення «один-до-багатьох» створюється у тому випадку, коли тільки одне з полів є полем первинного ключа або унікального індексу.
Відношення «один-до-одного» створюється у тому випадку, коли обидва зв'язувані поля є ключовими або мають унікальні індекси.
Відношення «багато-до-багатьох» фактично є двома стосунками «один-до-багатьох» з третьою таблицею, первинний ключ якої складається з полів зовнішнього ключа два інших таблиць
Ключ – це стовпець (може бути декілька стовпців), що додається до таблиці і дозволяє встановити зв'язок з записами в іншій таблиці. Існують ключі двох типів: первинні і вторинні (зовнішні).
Первинний ключ – це одне або декілька полів (стовпців), комбінація значень яких однозначно визначає кожний запис в таблиці. Первинний ключ не допускає значень Null і завжди повинен мати унікальний індекс. Первинний ключ використовується для пов'язання таблиці із зовнішніми ключами в інших таблицях
Зовнішній (вторинний) ключ - це одне або декілька полів (стовпців) в таблиці, що містять посилання на поле або поля первинного ключа в іншій таблиці. Зовнішній ключ визначає спосіб об'єднання таблиць.
З двох логічно зв'язаних таблиць одну називають таблицею первинного ключа або головною таблицею, а іншу - таблицею вторинного (зовнішнього) ключа або підпорядкованою таблицею. СКБД дозволяють зіставити споріднені записи з обох таблиць і спільно вивести їх у формі, звіті або запиті.
Існує три типи первинних ключів: ключові поля лічильника (лічильник), простий ключ і складний ключ.
Поле лічильника (Тип даних «Лічильник»). Тип даних поля в базі даних, в якому для кожного запису, що додається в таблицю, в полі автоматично заноситься унікальне числове значення.
Простий ключ. Якщо поле містить унікальні значення, такі як коди або інвентарні номери, то це поле можна визначити як первинний ключ. Як ключ можна визначити будь-яке поле, що містить дані, якщо це поле не містить значення, що повторюються, або значення Null.
Складний ключ. У випадках, коли неможливо гарантувати унікальність значень кожного поля, існує можливість створити ключ, що складається з декількох полів. Найчастіше така ситуація виникає для таблиці, використовуваної для скріплення двох таблиць багато, - до - багатьом.
В полі первинного ключа мають бути тільки унікальні значення в кожному рядку таблиці, тобто збіг не допускається, а в полі вторинного або зовнішнього ключа збіг значень в рядках таблиці допускається.
Якщо виникають труднощі з вибором відповідного типа первинного ключа, то як ключ доцільно вибрати поле лічильника.