1
Поле А1
Поле А2
...
Поле Ак
...
Поле S1
Поле S2
...
Поле Sd
1
2
Поле А1
Поле А2
...
Поле Ак
...
Поле S1
Поле S2
...
Поле Sd
2
...
...
...
...
...
...
...
...
...
...
...
N
Поле А1
Поле А2
...
Поле Ак
...
Поле S1
Поле S2
...
Поле Sd
p
Файл_1
Файл_М
Рис. 1 Файлова організація баз даних (файли, записи, поля)
Користувачами БД є чотири основні категорії споживачів її інформації та/або постачальників інформації для неї: (1) кінцеві користувачі, (2) програмісти і системні аналітики, (3) персонал підтримки БД в актуальному стані і (4) адміністратор БД. Добре спроектовані системи управління БД (СУБД), використовують розвинені графічні інтерфейси і підтримують системи звітів, що відповідають специфіці користувачів зазначених чотирьох категорій. У цьому випадку команда з підтримки БД і кінцеві користувачі можуть легко освоювати і використовувати СУБД для забезпечення своїх потреб без якої-небудь спеціальної підготовки, тобто специфіка функціонування даних систем прихована від користувача. Більш того, добре спроектовані СУБД надають досвідченому користувачеві засоби для створення власних БД-додатків, не вимагаючи від нього спеціальної програмістської підготовки. Кінцевим користувачам для забезпечення доступу до інформації БД надається графічний інтерфейс, як правило, у вигляді системи вікон з функціональними меню, що дозволяють легко отримувати необхідну інформацію на екран і/або принтер у вигляді зручно оформлених звітів.
Програмісти і системні аналітики використовують СУБД зовсім в іншій якості, забезпечуючи розробку нових БД-додатків, підтримуючи і модифікуючи (при необхідності) вже існуючі. Для даної групи користувачів СУБД потрібні кошти, що забезпечують зазначені функції (створення, відкладання, редагування і т.д.). Користувачі третій категорії мають потребу в інтерфейсі, як правило, графічному для забезпечення завдань підтримки БД в актуальному стані. Ці користувачі полягають у штатах підрозділів функціональних та/або обробки інформації, що забезпечують прикладну область, і відповідають за актуальний стан відповідної їй БД (контроль поточного стану, видалення застарілої інформації, додавання нової і т.д.). Програмісти виконують свого роду посередницькі функції між БД та кінцевими користувачами. І якщо на перших етапах розвитку БД-технології вони складали досить численну групу користувачів, то в процесі розвитку СУБД і, перш за все, масового використання ПК ця категорія сходить нанівець. Особливу і відповідальну роль виконує адміністратор, відповідає як за актуальність що знаходиться в БД інформації, так і за коректність функціонування та використання БД та СУБД.
У разі великих БД може бути досить багато кінцевих користувачів, ряд програмістів і кілька адміністраторів БД; у випадку невеликих БД (що особливо характерно для ПК) всі ці функції можуть забезпечуватися однією людиною. Важливі функції виконує адміністратор БД, що відповідає за вироблення вимог до БД, її проектування, реалізацію, ефективне використання та супровід. Необхідність у такому фахівця випливає з принципу незалежності даних, а також диктується важливістю БД у діяльності організацій і більше великих об'єднань - постачальників і споживачів інформації БД. Адміністратор БД взаємодіє з користувачами у визначенні вимог до бази в процесі вироблення вимог до системи в цілому, користується мов опису даних для визначення БД в процесі проектування системи, взаємодіє з програмістами, які створюють ПС використовує доступ до БД, відповідає за завантаження БД інформацією в процесі реалізації системи, контролює працездатність БД, використовуючи відповідні програмні й апаратні засоби, і визначає, коли варто реорганізовувати дані в базі або розпочати роботи зі створення нової, більш розширеної БД. У цілому функції адміністратора БД зводяться до підтримання цілісності БД, необхідного рівня захисту її даних та ефективності. Серед його найбільш важливих обов'язків - узгодження конфліктуючих вимог, яку потрібно досить часто, бо БД обслуговує, як правило, цілий ряд різних прикладних процесів.
Як вже зазначалося, БД являє собою сукупність логічно взаємопов'язаних файлів даних певної організації; для визначення й звернення до такої файлової сукупності використовують засоби системи управління БД (СУБД). СУБД являє собою сукупність лінгвістичних і програмних засобів, призначених для створення, ведення і сумісного використання БД багатьма користувачами. Тоді як під системою БД розуміється СУБД з наповненою відповідною інформацією БД, керованої її засобами. Це означає, по-перше, що сукупність файлів БД визначається за допомогою схеми, що не залежить від програм, які до неї звертаються, і, по-друге, що вона реалізована на основі ВП прямого доступу. Використання СУБД забезпечує краще керування даними, більш досконалу організацію файлів і більш просте звернення до них в порівнянні зі звичайними способами зберігання інформації. Внаслідок більш досконалих механізмів доступу БД, як правило, мають більш складну організацію, ніж звичайні файли, поєднуючи дані, раніше зберігаються у багатьох окремих файлах. Розмір і складність не є визначальними характеристиками БД - наявність СУБД для ПК і навіть у середовищі ряду пакетів (наприклад, електронних таблиць, інтегрованих та ін) приводить до створення великої кількості відносно простих і невеликих БД, гідністю яких (за наявності відповідних СУБД) є простота визначення і доступу до даних. Під банком даних (БНД) розуміється система лінгвістичних, програмних, апаратних та організаційних засобів, заснована на БД-технології і призначена для централізованого накопичення і колективного використання даних в тій чи іншій прикладної області. Тоді як система обробки інформації (СОІ) реалізує автоматизований збір, обробку та зберігання інформації, включаючи відповідні лінгвістичні, програмні, апаратні, організаційні засоби і обслуговуючий їх персонал.
Під цілісністю БД розуміється актуальний стан її даних, що відображають стан деякої реальної прикладної області і підкоряються правилам несуперечності. Під мовою БД розуміється один або сукупність мов, що забезпечують опис даних, маніпулювання з даними. Конкретний мова БД завжди асоціюється з конкретною СУБД. СУБД являє собою засоби обробки мовою бази даних, що дозволяють обробляти звертання до БД, що надходять від прикладних програм і/або кінцевих користувачів, і підтримувати цілісність БД. Таким чином, СУБД має властивості, характерні як для компіляторів, так і для ОС, однак у порівнянні з першими забезпечується більш високий рівень абстрагування, що виявляється дуже корисним як для програмістів, так і для кінцевих користувачів.
1.2. Ієрархічна і мережева даталогіческіе моделі СУБД
Кожна БНД містить і обробляє інформацію з конкретної прикладної області, представляє інтерес для певних програм. Опис предметної області без акценту на її подальші БНД-реалізації визначає інфологіческую модель предметної області (рис. 2). Інфологіческая модель є вихідною для побудови даталогіческой моделі БД і служить проміжною моделлю для фахівців предметної області (для якої створюється БНД) і адміністратора БД в процесі проектування і розробки конкретної БНД.
Під даталогіческой розуміється модель, що відображає логічні взаємозв'язки між елементами даних безвідносно їх змісту та фізичної організації. При цьому даталогіческая модель розробляється з урахуванням конкретної реалізації СУБД, також з урахуванням специфіки конкретної предметної області на основі її інфологіческой моделі. Для конкретної реалізації даталогіческой моделі проектується фізична модель (мал. 2), oтображающая перша на конкретні програмні й апаратні засоби (ОС, зовнішня пам'ять, робота з даними на фізичному рівні і т . д.). Наповнення конкретним інформацією фізична модель і складає власне БД. Система, що забезпечує Відповідне спільне функціонування зазначених компонентів і становить суть конкретної СУБД.
Сучасні СУБД допускають цілий ряд класифікацій в залежності від рівня їх розгляду (в цілому або за сукупністю їх функціональних характеристик): по інтерфейсу з користувачем в залежності від підтри?? іваемих моделей, за призначенням і режиму функціонування, за способом обробки інформації і т.д. Ми коротко зупинимося на моделях даталогіческого рівня, який береться за основу більшості сучасних класифікацій СУБД.
Зазвичай розрізняють три класи СУБД, що забезпечують роботу ієрархічних, мережних і реляційних моделей. Однак відмінності між цими класами поступово стираються, причому, мабуть, будуть з'являтися інші класи, що викликається насамперед інтенсивними роботами в області баз знань (БЗ) і об'єктно-орієнтованої інфотехнологіей, про яку йтиметься нижче. Тому традиційною класифікацією користуються все рідше, але ми поки будемо дотримуватися саме її, як найбільш усталену. Кожна із зазначених моделей має характеристики, що роблять її найбільш зручною для певних програм. Одне з основних відмінностей цих моделей полягає в тому, що для ієрархічних та мережевих СУБД їх структура часто не може бути змінена після введення даних, тоді як для реляційних СУБД структура може змінюватися в будь-який час. З іншого боку, для великих БД, структура яких тривалий час залишається незмінною, і постійно працюють з ними програм з інтенсивними потоками запитів на БД-обслуговування саме ієрархічні і мережні СУБД можуть виявитися найбільш ефективними рішеннями, бо вони можуть забезпечувати більш швидкий доступ до інформації БД , ніж реляційні СУБД.
Глава 2
Мережеві структури
Якщо у відносинах між даними породжений елемент має більше одного вихідного елементу, то це відношення вже не можна описати як деревоподібну або ієрархічну структуру. Його описують у вигляді мережевої структури. Будь-яка мережева структура може бути приведена до простішого увазі введенням надмірності. "БД постійно загрожує небезпека стати громіздкими, застиглими і занадто складними системами. Нові додатки породжують нові види запитів користувачів до бази, що збільшує набір логічних зв'язків між її елементами. У результаті багато систем БД виявляються дуже складними в побудові й експлуатації. Якщо розробник не придумають ясні і прості схеми організації, ці системи будуть подібні до павутині "[К. Дейт.].
Мережева модель більш симетрична, ніж ієрархічна модель. Однак процедури (оновлення) значно складніша проблема полягає в наступному: завжди є дві стратегії для визначення місця одного примірника запису, перша починається з "власника" та переглянути його ланцюжка для вибору ланки, а друга починається з "підлеглого ланки" та переглянути його ланцюжка для вибору "власника". Як користувач може вирішити, яку стратегію прийняти? Вибір і тут має велике значення. Як в ієрархічних, так і мережевих СУБД при описі даних звичайно вказуються характеристики записів кожного типу, які сприяють більш ефективному розміщенню даних у зовнішній пам'яті і більш швидкому доступу до них. До таких характеристик відносяться: розміри полів запису (мінімальні, середні, максимальні), склад ключа, допустимий набір символів, інтервали значень і т.д.
Ієрархічні і мережні бази даних часто називають базами даних з навігацією. Ця назва відображає технологію доступу до даних, що використовується при написанні обробних програм на мові маніпулювання даними. При цьому, очевидно, що доступ до даних по коліях, що не передбачені при створенні бази даних, може зажадати нерозумно великого часу. Підвищуючи ефективність доступу до даних і скорочуючи таким чином час відповіді на запит, принцип навігації разом з цим підвищує і ступінь залежності програм і даних. Оброблювальні програми виявляються жорстко прив'язаними для поточного стану структури бази даних і повинні бути переписані при її зміни. Операції модифікації і видалення даних потребує переустановки покажчиків, а маніпулювання даними залишається запісеоріентірованним. Крім того, принцип навігації не дозволяє істотно підвищувати рівень мови маніпулювання даними, щоб зробити його доступним користувачеві-непрограммісту, або навіть програмісту-непрофесіоналові. Для пошуку запису-мети в ієрархічній або мережевий структурі програміст повинен спочатку опеределіть шлях доступу, а потім переглянути всі записи, що лежать на цьому шляху, - крок за кроком.
Наскільки заплутаною є схеми подання ієрархічних і мережевих баз даних, настільки і трудомістким є проектування конкретних прикладних систем на їх основі. Як показує, досвід тривалі терміни розробки прикладних систем нерідко призводять до того, що вони постійно перебувають у стадії розробки та доопрацювання.
Зазначені та деякі інші проблеми, з якими зіткнулися розробники і користувачі ієрархічних і мережевих систем послужили стимулом до створення реляційної моделі даних і реляційних СУБД.
2.1. Файлова модель
Коротко розглянемо файлову модель, неправомірно що відносяться досить часто до СУБД. Файлова модель являє собою набір файлів даних певної структури, але зв'язок між даними цих файлів відсутній. Природно, програмні засоби роботи з таким чином організованої Інфобази можуть встановлювати зв'язок між даними її файлів, але на концептуальному рівні файли моделі є незалежними. Системи, що забезпечують роботу з файловими Інфобази, називають системами керування файлами (СУФ) і вони виявляються досить ефективними у багатьох додатках. СУФ використовуються на всіх класах ЕОМ, але особливо вони поширені для обробки інформації на ПК. При цьому в багатьох джерелах вони фігурують у якості СУБД. Файлові системи легко освоюються, достатньо прості й ефективні у використанні і, як правило, для роботи з ними використовуються прості мови запитів або і зовсім обмежуються набором програм-утиліт. Такі системи зазвичай підтримують роботу з невеликим числом файлів, що містять обмежена кількість записів з невеликою кількістю полів.
Ієрархічні моделі СУБД мають деревоподібну структуру, коли кожному вузлу структури відповідає один сегмент, представляє собою пойменований лінійний кортеж полів даних. Кожному сегменту ( крім S1-кореневого) відповідає один вхідний і кілька вихідних сегментів (рис. 3а). Кожен сегмент структури лежить на єдиному ієрархічному шляху, що починається від кореневого сегменту.
Для опису такої логічної організації даних ЯОД досить передбачати для кожного сегмента даних тільки ідентифікацію вхідного для нього сегмента. Так як в ієрархічній моделі кожному вхідному сегменту даних відповідає N вихідних, то такі моделі дуже зручні для представлення відносин типу 1: N в предметної області. Слід зазначити, що в даний час не розробляються СКБД, що підтримують на концептуальному рівні тільки ієрархічні моделі. Як правило, використовують ієрархічний підхід системи допускають зв'язування деревовидних структур між собою та/або встановлення зв'язків усередині них. Це призводить до мережевих даталогіческім моделями СУБД. До основних недоліків ієрархічних моделей варто віднести: неефективність реалізації відносин типу N: N, повільний доступ до сегментів даних нижніх рівнів ієрархії, чітка орієнтація на певні типи запитів та ін У зв'язку з цими недоліками раніше створені ієрархічні СУБД піддаються істотним модифікацій, що дозволяє підтримувати більш складні типи структур і, в першу чергу, мережеві та їх модифікації. Мережева даталогіческая модель СУБД багато в чому подібна до ієрархічної: якщо в ієрархічній моделі (рис. 3а) для кожного сегменту запису допускається тільки один вхідний сегмент при N вихідних, то в мережевій моделі для сегментів допускається кілька вхідних сегментів поряд з можливістю наявності сегментів без входів з точки зору ієрархічної структури. На рис. 3б представлений простий приклад мережевої структури, отриманої на основі модифікації ієрархічної структури (рис. 3а). Графічне зображення структури зв'язків сегментів такого типу моделей являє собою мережу. Сегменти даних в мережевих БД можуть мати множинні зв'язку з сегментами старшого рівня. При цьому напрямок і характер зв'язку в мережевих БД не є настільки очевидними, як у випадку ієрархічних БД. Тому імена і напрямок зв'язків повинні ідентифікуватися при описі БД засобами ЯОД.
Таким чином, під мережевий СУБД розуміється система, що підтримує мережеву організацію: будь-який запис, що називається записом старшого рівня, може містити дані, які відносяться до набору інших записів, які називаються записами підлеглого рівня. Можливо звернення до всіх записів у наборі, починаючи із запису старшого рівня. Звернення до набору записів реалізується за вказівниками. У рамках мережевих СУБД легко реалізуються і ієрархічні даталогіческіе моделі. Мережеві СУБД підтримують складні співвідношення між типами даних, що робить їх придатними у багатьох різних додатках. Проте користувачі таких СУБД обмежені зв'язками, визначеними для них розробниками БД-додатків. Більш того, подібно ієрархічним мережеві СУБД припускають розробку БД додатків досвідченими програмістами і системними аналітиками.
Серед недоліків мережевих СУБД слід особливо виділити проблему забезпечення збереження інформації в БД, вирішення якої приділяється підвищена увага при проектуванні мережевих БД.
Глава 3
Реляційні структури
Реляційний підхід став широко відомий завдяки першому робіт Е. Кодда, які з'явилися близько 1970р. Протягом довгого часу Реляційний підхід розглядався як зручний формальний апарат аналізу баз даних, що не має практичних перспектив, оскільки його реалізація вимагала занадто великих машинних ресурсів. Тільки з появою персональних ЕОМ реляційні та близькі до них системи несподівано стали поширюватися, практично не залишивши місця іншим моделям. Один із самих природних способів подання даних для користувачів - це двовимірна таблиця. Вона звична для користувача, зрозуміла і доступні для огляду, легко запам'ятовується. Оскільки будь-яка мережева структура може бути розкладена в сукупність деревовидних структур, то і будь-яке подання даних може бути зведене до двовимірним плоским файлів. Зв'язок між даними можуть бути представлені у формі двовимірних таблиць.
Таблиця має такі властивості:
Кожен елемент таблиці представляє собою один елемент даних. Повторювані групи відсутні.
Всі стовпці в таблиці однорідні. Це означає, що елементи стовпця мають однакову природу.
стовпцях присвоєні унікальні імена.
У таблиці немає двох однакових рядків.
Порядок розташування рядків і стовпців в таблиці байдужий. Таблиця такого роду називається відношенням. База даних, побудована за допомогою відносин, називається реляційної базою даних.
Чим же принципово відрізняються реляційні моделі від мережевих та ієрархічних? Коротко на це можна відповісти наступним чином: ієрархічні і мережні моделі даних - мають зв'язок по структурі, а реляційні - мають зв'язок по значенню. Проектування баз даних традиційно вважалося дуже важким завданням. Реляційна технологія значно спрощує цю задачу в трьох різних напрямках:
Поділ логічного та фізичного рівнів системи вона спрощує процес відображення "рівня реального світу", до структури, яку система може прямо підтримувати. Оскільки реляційна структура сама по собі концептуально проста, вона дозволяє реалізовувати невеликі та/або прості (і тому легкі для створення) бази даних, такі як персональні, сама можливість реалізації яких ніколи б навіть не розглядалася в старих більш складних системах.
Теорія і дисципліна нормалізації може допомогти, показуючи, що трапляється, якщо відносини не структуровані природним чином.
Реляційна модель даних особливо зручна для використання в базах даних розподіленої архітектури - вона дозволяє отримувати доступ до будь-яких інформаційних елементів, що зберігаються у вузлах мережі ЕОМ. Необхідно звернути особливу увагу на високорівнева аспект реляційного підходу, який полягає в множинної обробці записів. Завдяки цьому значно зростає потенціал реляційного підходу, який не може бути досягнутий при обробці по одному запису, і насамперед це стосується оптимізації. У системи управління базами даних з'являється можливість впливати на ефективність реалізації. В даний час на ринку програмно-математичного забезпечення для ПЕОМ представлено більше сотні різних СУБД. Вони сильно розрізняються за вартістю, за ефективністю роботи, з функціональної потужності, за складністю вивчення і використання.
Найбільш широке поширення одержали СУБД, що використовують реляційну модель даних, теоретичною основою якої є логіка предикатів першого порядку та теорія відносин. Однією з найважливіших характеристик як з точки зору розробника інформаційно-управляючих систем, так і їх користувачів є швидкодія СУБД, через що практично всі фірми світу-виробники СУБД працюють над проблемою збільшення реактивності. Більшість відомих комерційних СУБД страждають істотним недоліком: при роботі з великих і надвеликих базами даних різко знижується час реакції системи при виконанні процедур пошуку інформації. Крім того, що з'являються в періодичних виданнях результати тестування комерційних СУБД не завжди дозволяють зробити висновок про ефективність того чи іншого програмного продукту, оскільки майже завжди оцінюваним за часом результатом пошуку є перша знайдена запис, а час відповіді на складні многоключевие запити не оцінюється, в той час як час пошуку всіх записів, що задовольняють деякому критерію, лінійно залежить від кількості записів в базі, від кількості записів-цілей, від розмірів записи, і, отже, для великих баз вимірюється значним інтервалом часу.
Таким чином проведений аналіз систем управління базами даних, орієнтованих на різні моделі даних, дозволяє зробити висновок: в розподіленої інтегрованої інформаційної системи можливе використання СУБД реляційного типу.
3.1. Реляційні даталогіческіе моделі СУБД
СУБД реляційного типу є найбільш поширеним на всіх класах ЕОМ, а на ПК займають домінуюче положення. Дана модель дозволяє визначати: (1) операції із запам'ятовування та пошуку даних; (2) обмеження, пов'язані із забезпеченням цілісності даних. Для збільшення ефективності роботи в багатьох СУБД реляційного типу прийняті обмеження, відповідні суворої реляційної моделі.
Багато реляційні СКБД представляють файли БД для користувача в табличному форматі - з записами як рядків та їх полями як стовпців. У табличному вигляді інформація сприймається значно легше. Однак у БД на фізичному рівні дані зберігаються, як правило, у файлах, що містять послідовності записів. Основною перевагою реляційних СУБД є можливість зв'язування на основі певних співвідношень файлів БД. Зі структурної точки зору реляційні моделі є більш простими і однорідними, ніж ієрархічні і мережні. У реляційної моделі кожному об'єкту предметної області відповідає одне або більше відносин. При необхідності визначити зв'язок між об'єктами явно, вона виражається у вигляді відносини, в якому в якості атрибутів присутні ідентифікатори взаємопов'язаних об'єктів. У реляційної моделі об'єкти предметної області і зв'язки між ними представляються однаковими інформаційними конструкціями, істотно спрощує саму модель.
СУБД вважається реляційної при виконанні наступних двох умов, запропонованих ще Е. Коддом: (1) підтримує реляційну структуру даних і (2) реалізує принаймні операції селекції, проекції і з'єднання відносин. У подальшому був створений цілий ряд реляційних СУБД, в тій чи іншій мірі відповідають цим визначенням. Багато СУБД являють собою істотні розширення реляційної моделі, інші є змішаними, підтримуючи кілька даталогіческіх моделей.
Суть реляційної СУБД можна пояснити на такому простому прикладі (рис. 4).
Файл авторів публікацій БД
№ п/п
Автор
Адреса
Телефон
Кількість публ.
...
...
...
...
6
Купцов
Москва
635-6078
140
7
Бухтяк
Томськ
637-2050
140
8
терпуг
Томськ
538-584
250
Файл публікацій РБД
№ п/п
Назв. Публікації
Тип публ.
Дата
Обсяг у п. л.
6
Основи ...
Стаття
2.95
2.5
7
Проблема ...
Книга
3.97
35
8
Теорія ...
Стаття
6.96
3.8
...
...
...
...
Рис. 4 Простий приклад, який ілюструє принцип реляційної моделі
В деякій реляційної БД (РБД) є два файли авторів і публікацій, кожен з яких містить певну кількість записів/складаються з фіксованого числа полів (відповідно 4 і 5), що представляють дані по відповідних елементів предметної області (рис. 4). Можна сказати, що визначені дві відносини (фaйла), що мають загальний елемент - значення поля № п/п. Операції реляціанной алгебри можуть об'єднувати два типи записів по цьому загальному елементу. Наприклад, в результаті з'єднання запис Бухтяк може трапиться в наступному вигляді:
Бухтяк <Томськ> <637-2050> <40> <Основи ...>< стаття> <2.95> <2.5 >....
тобто до відомостей про автора додаються відомості про всі його публікаціях, що є в РБД. Зв'язок між записами допускається по декількох полях, дозволяючи утворювати досить складні операції. Поля даних, що зв'язують разом два записи, можуть бути унікальними для даної пари, але можуть дублюватися і в багатьох інших записах. Вони можуть повторюватися неодноразово, пов'язуючи між собою запису. Аналогічним чином можна проілюструвати виконання в реляційної моделі операцій проекції та селекції.
Реляційна СУБД повинна чітко відслідковувати взаємозв'язку записів у БД, щоб уникнути втрати або перекручування інформації. З цією метою СУБД постійно перераховує кількість зв'язків для кожного запису БД в прямому і зворотному напрямках, що вимагає істотних витрат часу для великих БД. Простота і стрункість реляційної алгебри роблять її дуже привабливою для організації реляційних БД, що ми і бачимо, перш за все, для класу ПК. Проте насправді реальні дані предметної області не укладаються в зазначеної моделі (наприклад, відносини можуть містити повторювані записи і т.д.). Тому поряд з суто реляційними існують і інші даталогіческіе моделі СУБД та їх різні модифікації і поєднання, забезпечуючи широке коло розв'язуваних на їх основі інформаційних, комерційних, управлінських, фінансових, обчислювальних та інших типів завдань. З найбільш відомих прикладів реляційних СУБД можна відзначити такі, як: dBase, DB/2, ORACLE, Paradox та ряд інших.
Масовий розвиток класу ПК зробило дуже істотний вплив на розвиток інфотехнологіі і БД-технології зокрема, привносячи елементи останньої в масову інфотехнологію. Перш за все, цьому сприяв розвиток потужної індустрії зі створення різноманітних СУБД для ПК. Якщо створення СУБД для ЕОМ загального призначення і (значною мірою) міні-ЕОМ займало тривалий проміжок часу і число таких комерційних СУБД було невелике - практично весь їх перелік був на слуху у фахівців з комп'ютерної інфотехнологіі, то
