У розвитку технології баз даних виділяють 4 етапи.
Перший етап пов'язаний з розвитком баз даних на великих машинах типу IBM 360/370, ЄС ЕОМ.
Історія розвитку систем управління базою даних (СКБД) налічує більше 30 років. У 1968 р була введена в експлуатацію перша промислова СУБД фірми IBM. У 1975 р з'явився перший стандарт асоціації по мовам систем обробки даних Conference of Data System Languages \u200b\u200b(CODASYL), який визначив ряд фундаментальних понять в теорії баз систем даних. У 1981 р Е.Ф. Кодд отримав премію Тюрінга за розробку реляційної моделі і реляційної алгебри.
Бази даних зберігалися у зовнішній пам'яті центральної ЕОМ, користувачами цих баз були завдання, що запускаються в основному в пакетному режимі. Інтерактивний режим доступу забезпечувався за допомогою консольних терміналів, не володіли власними обчислювальними ресурсами. Ці системи відносять до систем розподіленого доступу.
Другий етап пов'язаний з появою і розвитком персональних комп'ютерів. На цьому етапі переважають настільні СУБД зокрема: Dbase, FoxPro, Clipper, Paradox.
Третій етап. Почався процес інтеграції. Цей етап пов'язаний з розвитком комп'ютерних мереж, Тому гостро постає завдання узгодженості даних зберігаються і обробляються в різних місцях і логічно один з одним не пов'язаних. Успішне вирішення цих завдань призводить до появи розподілених баз даних.
Особливості цього етапу:
Підтримка структурної та мовної цілісності;
Можливість роботи на комп'ютерах з різною архітектурою;
Підтримка розрахованого на багато користувачів режиму і можливість децентралізованого зберігання даних.
До цього етапу відносяться СУБД Access`97, Oracle 7.3 (8.4), MS SQL 6.5 (7.0) System 10 (11).
Четвертий етап визначає перспективи розвитку СУБД. Цей етап характеризується появою нової технології доступу до даних - інтранет. У цій технології не використовується спеціалізоване клієнтське програмне забезпечення. Для роботи з віддаленою базою даних можна застосувати Internet Explorer та ін.
Історія виникнення і розвитку баз даних
В історії обчислювальної техніки можна простежити розвиток двох основних областей її використання:
перша область - застосування обчислювальної техніки для виконання чисельних розрахунків, складних алгоритмів обробки за допомогою алгоритмічних мов, Але всі вони мають справу з простими структурами даних, обсяг яких невеликий.
друга область- це використання засобів обчислювальної техніки в автоматичних або автоматизованих інформаційних системах. Інформаційна система являє собою програмно-апаратний комплекс, що забезпечує виконання таких функцій:
Надійне зберігання інформації в пам'яті комп'ютера;
Виконання специфічних для цього додатка перетворень інформації і обчислень;
Надання користувачам зручного і легко освоюється інтерфейсу.
Важливим кроком у розвитку саме інформаційних систем з'явився перехід до використання централізованих систем управління файлами.
файл - це іменована область зовнішньої пам'яті, в яку можна записувати і з якої можна зчитувати дані.
Правила іменування файлів, спосіб доступу до даних, що зберігаються в файлі, і структура цих даних залежать від конкретної системи управління файлами і, можливо, від типу файлу. Система управління файлами бере на себе розподіл зовнішньої пам'яті, відображення імен файлів у відповідні адреси в зовнішній пам'яті і забезпечення доступу до даних. Користувач ряд стандартних операцій:
створити файл (необхідного типу і розміру);
записати в файл на місце поточного запису нову, додати нову запис в кінець файлу.
Структура запису файлу була відома тільки програмою, яка з ним працювала. кожна програма, Що працює з файлом, повинна була мати у себе всередині структуру даних, відповідну структурі цього файлу. Тому при зміні структури файлу потрібно змінювати структуру програми, а це вимагало нової компіляції. Тобто це означає залежність програм від даних. Інформаційні системи використовуються багатьма користувачами одночасно. При зміні структури файлів необхідно змінювати програми всіх користувачів. А веде додаткові витрати на розробку.
Це було першим істотним недоліком файлових систем, який з'явився поштовхом до створення нових систем зберігання і управління інформацією.
Так як файли є загальним сховищем даних, то система управління файлами повинна забезпечити авторизацію доступу до файлів. Для кожного існуючого файлу вказуються дії, які дозволені або заборонені даному користувачеві. Кожному зареєстрованому користувачу відповідає пара цілочисельних ідентифікаторів: ідентифікатор групи, До якої відноситься цей користувач, І його власний ідентифікатор в группе.Для кожного файлу повинен зберігатися повний
ідентифікатор користувача, який створив цей файл, І фіксуватися, які дії йому доступи і доступні для інших користувачів групи.
адміністрування режимом доступу до файлу в основному виконується його творцем-власником. для безлічі файлів, що відображають інформаційну модель однією предметної області, Такий децентралізований принцип управління доступом викликав додаткові труднощі. відсутність централізованих методівуправління доступом до інформації послужило ще однією причиною розробки СУБД.
Одночасна робота декількох користувачів у багатокористувацьких ОС, пов'язана з модифікацією даних у файлі, або взагалі не реалізовувалася, або дуже сповільнена.
Всі ці недоліки послужили розвитку нового підходу до управління інформацією. Цей підхід був реалізований в СУБД(системах управління даними).
Історія розвитку СУБД налічує понад 30 років. У 1968 році була введена в експлуатацію перша промислова СУБД система IMS фірми IBM. У 1975 році з'явився перший стандарт асоціації по мовам систем обробки даних - Conference of Data SystemLanguages \u200b\u200b(CODASYL), який визначив ряд фундаментальних понять в теорії систем баз даних, які і досі є основними для мережевий моделі даних. У подальший розвиток теорії баз даних великий внесок був зроблений американським математиком Е. Ф. Коддом, який є творцем реляційної моделі даних. У 1981 році Е. Ф. Кодд отримав за створення реляційної моделі і реляційної алгебрипрестижну премію Тьюринга Американської асоціації з обчислювальної техніки.
Розвиток обчислювальної техніки вплинуло також і на розвиток технології баз даних. Можна виділити чотири етапи в розвитку даного напрямку в обробці даних.
Перший етап розвитку СУБД пов'язаний з організацією баз даних на великих машинах типу IBM 360/370, ЄС-ЕОМ і міні-ЕОМ типу PDP11 (фірми Digital Equipment Corporation - DEC), різних моделях HP (фірми Hewlett Packard).
Бази даних зберігалися у зовнішній пам'яті центральної ЕОМ, користувачами цих баз даних були завдання, що запускаються в основному в пакетному режимі. інтерактивний режим доступу забезпечувався за допомогою консольних терміналів, які не володіли власними обчислювальними ресурсами (процесором, зовнішньою пам'яттю) І служили тільки пристроями введення-виведення для центральної ЕОМ. Програми доступу до БД писалися на різних мовах і запускалися як звичайні числові програми.
Особливості цього етапу розвитку виражаються в наступному:
Всі СУБД базуються на потужних мультипрограмних операційних системах ( MVS, SVM, RTE, OSRV, RSX, UNIX), тому в основному підтримується робота з централізованою базою даних в режимі розподіленого доступу.
Функції управління розподілом ресурсів в основному здійснюються операційною системою (ОС).
підтримуються мови низького рівня маніпулювання даними, орієнтовані на навігаційні методи доступу до даних.
Значна роль відводиться адмініструванню даних.
Проводяться серйозні роботи по обґрунтуванню і формалізації реляційної моделі даних, і була створена перша система (System R), що реалізує ідеологію реляційної моделі даних.
Проводяться теоретичні роботи по оптимізації запитів і управління розподіленим доступом до централізованої БД, було введено поняття транзакції.
Результати наукових досліджень відкрито обговорюються у пресі, йде потужний потік загальнодоступних публікацій, що стосуються всіх аспектів теорії і практики баз даних, і результати теоретичних досліджень активно впроваджуються в комерційні СУБД.
З'являються перші мови високого рівня для роботи з реляційною моделлю даних. Однак відсутні стандарти для цих перших мов.
2 етап - це етап розвитку персональних комп'ютерів.
Особливості цього етапу наступні:
Всі СУБД були розраховані на створення БД в основному з монопольним доступом.
Більшість СУБД мали розвинений і зручний користувальницький інтерфейс. У більшості існував інтерактивний режим роботи з БД як в рамках опису БД, так і в рамках проектування запитів. Крім того, більшість СУБД пропонували розвинений і зручний інструментарій для розробки готових додатків без програмування (на основі готових шаблонів форм, конструкторів запитів).
У всіх СУБД підтримувався тільки зовнішній рівень представлення реляційної моделі, тобто тільки зовнішній табличний вигляд структур даних.
При наявності високорівневих мов маніпулювання даними типу реляційної алгебри і SQL в настільних СУБД підтримувалися низькорівневі мови маніпулювання даними на рівні окремих рядків таблиць.
У настільних СУБД були відсутні засоби підтримки посилальної і структурної цілісності бази даних. Ці функції повинні були виконувати додатки.
Наявність монопольного режиму роботи фактично призвело до виродження функцій адміністрування БД і в зв'язку з цим - до відсутності інструментальних засобів адміністрування БД.
порівняно скромні вимоги до апаратного забезпечення з боку настільних СУБД.
Представники цього сімейства - дуже широко використовувалися до недавнього часу СУБД Dbase (DbaseIII +, DbaseIV), FoxPro, Clipper, Paradox.
3 етап - розподілені бази даних(Перехід від персоналізації до інтеграції)
Особливості цього етапу:
Практично всі сучасні СУБД забезпечують підтримку повної реляційної моделі, а саме:
Про структурної цілісності - допустимими є тільки дані, представлені у вигляді відносин реляційної моделі;
Про мовну цілісності, тобто мов маніпулювання даними високого рівня (в основному SQL);
Про посилальної цілісності, контролю за дотриманням посилальної цілісності протягом всього часу функціонування системи, і гарантій неможливості з боку СУБД порушити ці обмеження.
Більшість сучасних СУБД розраховані на набір інструментів, написаний архітектуру, тобто вони можуть працювати на комп'ютерах з різною архітектурою і під різними операційними системами.
Необхідність підтримки багатокористувацької роботи з базою даних і можливість децентралізованого зберігання даних зажадали розвитку засобів адміністрування БД з реалізацією загальної концепції засобів захисту даних.
Створення теоретичних праць з оптимізації реалізацій розподілених БД і роботі з розподіленими транзакціями і запитами з впровадженням отриманих результатів в комерційні СУБД.
Для того щоб не втратити клієнтів, які раніше працювали на настільних СУБД, практично всі сучасні СУБД мають засоби підключення клієнтських додатків, розроблених з використанням настільних СУБД, і кошти експорту даних з форматів настільних СУБД другого етапу розвитку.
Розробка стандартів мов опису і маніпулювання даними SQL89, SQL92, SQL99 і технологій по обміну даними між різними СУБД.
Розробка концепції об'єктно-орієнтованих БД - ООБД. Представниками СУБД, що належать до другого етапу, можна вважати MS Access 97 і всі сучасні сервери баз даних Oracle7.3, Oracle 8.4 MS SQL6.5, MS SQL7.0, System 10, System 11, Informix, DB2, SQL Base і інші сучасні сервери баз даних, яких зараз налічується кілька десятків.
4 етап характеризується появою нової технології доступу до даних - інтранет.
Основна відмінність цього підходу від технології клієнт-сервер полягає в тому, що відпадає необхідність використання спеціалізованого клієнтського програмного забезпечення. Для роботи з віддаленою базою даних використовується стандартний браузер.
При цьому вбудований в завантажуються користувачем HTML-сторінки код, написаний зазвичай на мові Java, Java-script, Perl і інших, відстежує всі дії користувача і транслює їх в низькорівневі SQL-запити до бази даних, виконуючи, таким чином, ту роботу, якої в технології клієнт-сервер займається клієнтська програма. Складні завдання реалізовані в архітектурі " клієнт-сервер"З розробкою спеціального клієнтського програмного забезпечення.
Перший етап - бази даних на великих ЕОМ. Перший етап розвитку СУБД пов'язаний з організацією баз даних на великих машинах типу IBM 360/370, ЄС-ЕОМ і міні-ЕОМ типу PDP11 (фірми Digital Equipment Corporation - DEC), різних моделях HP (фірми Hewlett Packard). Бази даних зберігалися у зовнішній пам'яті центральної ЕОМ, користувачами цих баз даних були завдання, що запускаються в основному в пакетному режимі. Інтерактивний режим доступу забезпечувався за допомогою консольних терміналів, які не володіли власними обчислювальними ресурсами (процесором, зовнішньою пам'яттю) і служили тільки пристроями введення-виведення для центральної ЕОМ.
Другий етап - епоха персональних комп'ютерів. З'являється безліч програм, призначених для роботи непідготовлених користувачів. Ці програми прості у використанні і інтуїтивно зрозумілі: це, перш за все, різні редактори текстів, електронні таблиці та інші. Кожен користувач може автоматизувати багато аспектів діяльності. І, звичайно, це позначилося і на роботі з базами даних. З'явилися програми, які називалися системами управління базами даних і дозволяли зберігати значні обсяги інформації, вони мали зручний інтерфейс для заповнення даних, вбудовані засоби для генерації різних звітів. Ці програми дозволяли автоматизувати багато облікові функції, які раніше велися вручну. Комп'ютери стали інструментом для ведення документації та власних облікових функцій. Це все зіграло як позитивну, так і негативну роль в області розвитку баз даних.
Третій етап - розподілені бази даних. Добре відомо, що історія розвивається по спіралі, тому після процесу "персоналізації" почався зворотний процес - інтеграція. Множиться кількість локальних мереж, все більше інформації передасться між комп'ютерами, гостро постає завдання узгодженості даних, що зберігаються і обробляються в різних місцях, але логічно один з одним пов'язаних, виникають завдання, пов'язані з паралельною обробкою транзакцій - послідовностей операцій над БД, що переводять її з одного несуперечливого стану в інше несуперечливе стан. Успішне вирішення цих завдань призводить до появи розподілених баз даних, що зберігають всі переваги настільних СУБД і в той же час дозволяють організувати паралельну обробку інформації і підтримку цілісності БД.
Четвертий етап - перспективи розвитку систем управління базами даних. Цей етап характеризується появою нової технології доступу до данним- інтранет. Основна відмінність цього підходу від технології клієнт-сервер полягає в тому, що відпадає необхідність використання спеціалізованого клієнтського програмного забезпечення. Для роботи з віддаленою базою даних використовується стандартний броузер Internet, наприклад Microsoft InternetExplorer, і для кінцевого користувача процес звернення до даних відбувається аналогічно використання Internet. При цьому вбудований в завантажуються користувачем HTML-сторінки код, написаний зазвичай на мовах Java, Java-script, Perl і інших, відстежує всі дії користувача і транслює їх в низькорівневі SQL-запити до бази даних, виконуючи, таким чином, ту роботу, якої в технології клієнт-сервер займається клієнтська програма.
Основи використання БД
Отже, почнемо з самого початку. Що ж таке база даних? База даних - організована відповідно до певних правил і підтримувана в пам'яті комп'ютера сукупність даних, що характеризує актуальний стан деякої предметної області і використовувана для задоволення інформаційних потреб користувачів (Інформація з Вікіпедії)
Таким чином, до БД відносяться:
Інтерфейс для управління БД, званий СУБД - Система управління базами даних
Власне дані, що зберігаються в певній формі
Існують різні типи баз даних. Основна ознака класифікації - принцип зберігання даних.
реляційні
Об'єктно-орієнтовані
об'єктні
Об'єктно-реляційні
ієрархічні
файли і файлові системи
Важливим кроком у розвитку саме інформаційних систем з'явився перехід до використання централізованих систем управління файлами. З точки зору прикладної програми, файл - це іменована область зовнішньої пам'яті, в яку можна записувати і з якої можна зчитувати дані. Правила іменування файлів, спосіб доступу "до даних, що зберігаються в файлі, і структура цих даних залежать від конкретної системи управління файлами і, можливо, від типу файлу. Система управління файлами бере на себе розподіл зовнішньої пам'яті, відображення імен файлів у відповідні адреси в зовнішній пам'яті і забезпечення доступу до даних.
Конкретні моделі файлів, використовувані в системі управління файлами, ми розглянемо далі, коли перейдемо до фізичних способів організації баз даних, а на цьому етапі нам досить знати, що користувачі бачать файл як лінійну послідовність записів і можуть виконати над ним ряд стандартних операцій:
створити файл (необхідного типу і розміру);
записати в файл на місце поточного запису нову, додати новий запис в кінець файлу.
У різних файлових системах ці операції могли дещо відрізнятися, але загальний зміст їх був саме таким. Головне, що слід зазначити, це те, що структура записи файлу була відома тільки програмою, яка з ним працювала, система управління файлами не знала її. І тому для того, щоб витягти деяку інформацію з файлу, необхідно було точно знати структуру запису файлу з точністю до біта. Кожна програма, що працює з файлом, повинна була мати у себе всередині структуру даних, відповідну структурі цього файлу. Тому при зміні структури файлу потрібно змінювати структуру програми, а це вимагало нової компіляції, тобто процесу перекладу програми в виконувані машинні коди. Така ситуації характеризувалася як залежність програм від даних. Для інформаційних систем характерним є наявність великої кількості різних користувачів (програм), кожен з яких має свої специфічні алгоритми обробки інформації, що зберігається в одних і тих же файлах. Зміна структури файлу, яке було необхідно для однієї програми, вимагала виправлення і перекомпіляції і додаткового налагодження решти всіх програм, що працюють з цим же файлом. Це було першим істотним недоліком файлових систем, який з'явився поштовхом до створення нових систем зберігання і управління інформацією.
Далі, оскільки файлові системи є загальним сховищем файлів, що належать, взагалі кажучи, різним користувачам, системи управління файлами повинні забезпечувати авторизацію доступу до файлів. У загальному вигляді підхід полягає в тому, що по відношенню до кожного зареєстрованого користувача даної обчислювальної системи для кожного існуючого файлу вказуються дії, які дозволені або заборонені даному користувачеві. У більшості сучасних систем управління файлами застосовується підхід до захисту файлів, вперше реалізований в ОС UNIX. У цій ОС кожному зареєстрованому користувачу відповідає пара цілочисельних ідентифікаторів; ідентифікатор групи, до якої відноситься цей користувач, і його власний ідентифікатор в групі. При кожному файлі зберігається повний ідентифікатор користувача, який створив цей файл, і фіксується, які дії з файлом може виробляти його творець, які дії з файлом доступні для інших користувачів тієї ж групи і що можуть робити з файлом користувачі інших груп. Адміністрування режимом доступу до файлу в основному виконується його творцем-власником. Для безлічі файлів, що відображають інформаційну модель однієї предметної області, такий децентралізований принцип управління доступом викликав додаткові труднощі. І відсутність централізованих методів управління доступом до інформації послужило ще однією причиною розробки СУБД.
Наступною причиною стала необхідність забезпечення ефективної паралельної роботи багатьох користувачів з одними і тими ж файлами. У загальному випадку системи управління файлами забезпечували режим багато користувачів доступу. Якщо операційна система підтримує багатокористувацький режим, цілком реальна ситуація, коли два або більше користувача одночасно намагаються працювати з одним і тим же файлом. Якщо всі користувачі збираються тільки читати файл, нічого страшного не станеться. Але якщо хоча б один з них буде змінювати файл, для коректної роботи цих користувачів потрібно взаємна синхронізація їх дій по відношенню до файлу
У системах управління файлами зазвичай застосовувався наступний підхід. В операції відкриття файлу (першої та обов'язкової операції, з якої повинен починатися сеанс роботи з файлом) серед інших параметрів вказувався режим роботи (читання або зміна). Якщо до моменту виконання цієї операції деяким призначеним для користувача процесом PR1 файл був вже відкритий іншим процесом PR2 в режимі зміни, то в залежності від особливостей системи процесу PR1 або повідомлялося про неможливість відкриття файлу, або він блокувався до тих пір, поки в процесі PR2 не виконувалася операція закриття файлу.
При подібному способі організації одночасна робота декількох користувачів, пов'язана з модифікацією даних у файлі, або взагалі не реалізовувалася, або була дуже сповільнена.
Ці недоліки послужили тим поштовхом, який змусив розробників інформаційних систем запропонувати новий підхід до управління інформацією. Цей підхід був реалізований в рамках нових програмних систем, названих згодом Системами Управління Базами Даних (СУБД), а самі сховища інформації, які працювали під управлінням даних систем, називалися базами або банками даних (БД і БНД).
3 питання.Розподілені бази даних (РБД)- сукупність логічно взаємопов'язаних баз даних, розподілених у комп'ютерній мережі.
Основні принципи
РБД складається з набору вузлів, пов'язаних комунікаційною мережею, в якій:
кожен вузол - це повноцінна СУБД сама по собі;
вузли взаємодіють між собою таким чином, що користувач будь-якого з них може отримати доступ до будь-яких даних в мережі так, як ніби вони знаходяться на його власному вузлі.
Кожен вузол сам по собі є системою бази даних. Будь-який користувач може виконати операції над даними на своєму локальному вузлі точно так же, як якщо б цей вузол зовсім не входив в розподілену систему. Розподілену систему баз даних можна розглядати як партнерство між окремими локальними СУБД на окремих локальних вузлах.
Фундаментальний принцип створення розподілених баз даних ( «правило 0»): Для користувача розподілена система повинна виглядати так само, як нерозподілений система.
Фундаментальний принцип має наслідком певні додаткові правила або цілі. Таких цілей всього дванадцять:
Локальна незалежність. Вузли в розподіленої системі повинні бути незалежні, або автономні. Локальна незалежність означає, що всі операції на вузлі контролюються цим вузлом.
Відсутність опори на центральний вузол. Локальна незалежність передбачає, що всі вузли в розподіленої системі повинні розглядатися як рівні. Тому не повинно бути ніяких звернень до «центральному» або «головному» вузлу з метою отримання певного централізованого сервісу.
Безперервне функціонування. Розподілені системи повинні надавати більш високу ступінь надійності і доступності.
Незалежність від розташування. Користувачі не повинні знати, де саме дані зберігаються фізично і повинні надходити так, як якщо б всі дані зберігалися на їх власному локальному вузлі.
Незалежність від фрагментації. Система підтримує незалежність від фрагментації, якщо дана змінна-відношення може бути розділена на частини чи фрагменти при організації її фізичного зберігання. У цьому випадку дані можуть зберігатися в тому місці, де вони найчастіше використовуються, що дозволяє досягти локалізації більшості операцій і зменшення мережевого трафіку.
Незалежність від реплікації. Система підтримує реплікацію даних, якщо ця збережена змінна-відношення - або в загальному випадку даний фрагмент даної інформації, що зберігається змінної-відносини - може бути представлена \u200b\u200bкількома окремими копіями або репліками, які зберігаються на декількох окремих вузлах.
Обробка розподілених запитів. Суть в тому, що для запиту може знадобитися звернення до декільком вузлам. У такій системі може бути багато можливих способів пересилання даних, що дозволяють виконати розглянутий запит.
Управління розподіленими транзакціями. Існує 2 головні аспекти управління транзакціями: управління відновленням і управління паралельною обробки. Що стосується управління відновленням, то щоб забезпечити атомарность транзакції в розподіленої середовищі, система повинна гарантувати, що всі безліч відносяться до даної транзакції агентів (агент - процес, який виконується для даної транзакції на окремому вузлі) або зафіксувало свої результати, або виконало відкат. Що стосується управління паралельною, то воно в більшості розподілених систем базується на механізмі блокування, точно так, як і в нерозподілених системах.
Апаратна незалежність. Бажано мати можливість запускати одну і ту ж СУБД на різних апаратних платформах і, більш того, домогтися, щоб різні машини брали участь в роботі розподіленої системи як рівноправні партнери.
Незалежність від операційної системи. Можливість функціонування СУБД під різними операційними системами.
Незалежність від мережі. Можливість підтримувати багато принципово різних вузлів, що відрізняються обладнанням і операційними системами, а також ряд типів різних комунікаційних мереж.
Незалежність від типу СУБД. Необхідно, щоб екземпляри СУБД на різних вузлах все разом підтримували один і той же інтерфейс, і зовсім необов'язково, щоб це були копії однієї і тієї ж версії СУБД.
Типи розподілених баз даних
Розподілені бази даних
Мультібази даних з глобальної схемою. Система мультібаз даних - це розподілена система, яка служить зовнішнім інтерфейсом для доступу до безлічі локальних СУБД або структурується, як глобальний рівень над локальними СУБД.
Федеративної бази даних. На відміну від мультібаз не мають глобальної схемою, до якої звертаються всі програми. Замість цього підтримується локальна схема імпорту-експорту даних. На кожному вузлі підтримується часткова глобальна схема, що описує інформацію тих віддалених джерел, дані з яких необхідні для функціонування.
Мультібази з спільною мовою доступу - розподілені середовища управління з технологією «клієнт-сервер»
4 питання.Проектування баз даних- це складний процес вирішення цілої низки завдань, які пов'язані зі створенням баз даних.
Основні завдання проектування СУБД
Забезпечення можливості для коректного отримання даних по всім запитам;
Забезпечення зберігання в базі даних всієї необхідної інформації; Скоротити надмірність і дублювання даних;
Забезпечити цілісність всіх даних в БД і виключити їх втрати;
Головні етапи в проектуванні БД;
Інфологіческое (Концептуальне) проектування - це грамотна побудова формалізованої моделі всієї предметної області. Подібна модель створюється з використанням стандартних мовних засобів, найчастіше графічних, наприклад ER-діаграм. Така модель створюється без будь-якої орієнтації на конкретну СУБД.
Головні елементи даної моделі:
Опис усіх об'єктів предметної області і всіх зв'язків між ними;
Опис всіх інформаційних потреб користувачів, наприклад, опис найосновніших запитів до бази даних і т.д .;
складання повного опису документообігу. Опис всіх документів, які використовуються в якості вихідних даних для бази даних;
Опис основних алгоритмічних залежностей, що виникають між даними;
Детальний опис обмежень цілісності. Сюди входять вимоги до всіх допустимих значень даних і до їх зв'язків;
Види проектування:
Логічне або Даталогіческое проектування - полягає у відображенні інфологічної моделі на будь-яку модель даних, Яка використовується в конкретній СУБД. Для реляційних СУБД характерна даталогіческая модель, а саме: набір всіх таблиць із зазначенням основних або ключових полів і всіх зв'язків між цими таблицями. Даталогіческое проектування будь инфологической моделі, яка побудована у вигляді ER-діаграм, представляє побудова таблиць з яких-небудь певним формалізованим правилам.
Фізичне проектування СУБД - це процес реалізації будь-якої даталогіческой моделі, використовуючи засоби конкретної СУБД, а також вибір різних рішень, Які пов'язані з фізичним середовищем зберігання всіх даних.
5 питання.Реляційна модель даних (РМД)- логічна модель даних, прикладна теорія побудови баз даних, яка є додатком до завдань обробки даних таких розділів математики як теорії множин і логіка першого порядку.
На реляційної моделі даних будуються реляційні бази даних.
Реляційна модель даних включає наступні компоненти:
Структурний аспект (складова) - дані в базі даних є набором відносин.
Аспект (складова) цілісності - відносини (таблиці) відповідають певним умовам цілісності. РМД підтримує декларативні обмеження цілісності рівня домену (типу даних), рівня відносини і рівня бази даних.
Аспект (складова) обробки (маніпулювання) - РМД підтримує оператори маніпулювання відносинами (реляційна алгебра, реляційне числення).
Крім того, до складу реляційної моделі даних включають теорію нормалізації.
Термін «реляційний» означає, що теорія заснована на математичному понятті відношення (relation). Як неформального синонім терміну «відношення» часто зустрічається слово таблиця. Необхідно пам'ятати, що «таблиця» є поняття Нечитка і неформальне і часто означає не «відношення» як абстрактне поняття, а візуальне уявлення відносини на папері або екрані. Некоректне і Нечитка використання терміна «таблиця» замість терміна «ставлення» нерідко призводить до нерозуміння. найбільш часта помилка складається в міркуваннях про те, що РМД має справу з «плоскими», або «двовимірними» таблицями, тоді як такими можуть бути тільки візуальні уявлення таблиць. Відносини ж є абстракціями, і не можуть бути ні «плоскими», ні «неплоскими».
Для кращого розуміння РМД слід зазначити три важливих обставини:
модель є логічною, тобто відносини є логічними (абстрактними), а не фізичними (збереженими) структурами;
для реляційних баз даних вірний інформаційний принцип: все інформаційне наповнення бази даних представлено одним і тільки одним способом, а саме - явним завданням значень атрибутів в кортежі відносин; зокрема, немає ніяких покажчиків (адрес), що зв'язують одне значення з іншим;
наявність реляційної алгебри дозволяє реалізувати декларативне програмування і декларативне опис обмежень цілісності, на додаток до навігаційного (процедурного) програмування і процедурної перевірці умов.
Принципи реляційної моделі були сформульовані в 1969-1970 роках Е. Ф. Коддом (E. F. Codd). Ідеї \u200b\u200bКодда були вперше публічно викладені в статті «A Relational Model of Data for Large Shared Data Banks», що стала класичною.
Суворе виклад теорії реляційних баз даних (реляційної моделі даних) в сучасному розумінні можна знайти в книзі К. Дж. Дейта. «C. J. Date. An Introduction to Database Systems »(« Дейт, К. Дж. Введення в системи баз даних »).
Найбільш відомими альтернативами реляційної моделі є ієрархічна модель, і мережева модель. Деякі системи, що використовують ці старі архітектури, використовуються досі. Крім того, можна згадати про об'єктно-орієнтованої моделі, на якій будуються так звані об'єктно-орієнтовані СУБД, хоча однозначного і загальноприйнятого визначення такої моделі немає.
6 питання.Оператор вибораSELECT.
Команда select (вибір) використовується для отримання даних з таблиці. Цю команду можна використовувати для вибору даних як по рядках, так по стовпцях з однієї або декількох таблиць.
Запит це звернення до бази даних з метою отримання результуючих даних. Цей процес також називається знаходженням даних. Усе SQL запити виражаються через оператор вибору (select). Цей оператор можна використовувати як для вибору записів (рядків) з однієї або декількох таблиць, так і для побудови проекцій (projections), тобто вибору даних по деякій підмножині атрибутів (стовпців) з однієї або декількох таблиць.
SELECT- ключове слово, Яке повідомляє СУБД, що ця команда - запит. Всі запити починаються цим словом з доследующего прогалиною, За ним може слідувати спосіб вибірки - з видаленням дублікатів (DISTINCT) або без видалення (ALL, мається на увазі за замовчуванням). Потім слідує список перерахованих через кому стовпців, які вибираються запитом з таблиць, або символ "*" (зірочка) для вибору всього рядка. Будь-які стовпці, не перераховані тут, не будуть включені в результуюче відношення, відповідне виконання команди. Це, звичайно, не означає, що вони будуть видалені або їх інформація буде стерта з таблиць, тому що запит не вплине на інформацію в, таблицях - він тільки показує дані.
7 питання. математичні функції
В арсеналі кожної СУБД обов'язково є набір вбудованих функцій для обробки стандартних типів даних. У MySQLдля вбудованих функцій між ім'ям і відкриває дужкою не повинно бути пробілів, інакше буде повідомлення про відсутність подібної функції в БД. У деяких СУБД, какOracle, якщо функція не має аргументів, то дужки можна опустити.
abs (x) - абсолютне значення;
ceil (x) - найменше ціле, яке менше аргументу;
exp (x) - експонента;
floor (x) - найбільше ціле, яке більше аргументу;
ln (x) - натуральний логарифм;
power (x, y) - зводить x в ступінь y;
round (x [, y]) - округлення x до y розрядів праворуч від десяткового дробу. За замовчуванням y дорівнює 0;
sign (x) - повертає -1 для від'ємних значень x і 1 для позитивних;
sqrt (x) - квадратний корінь;
trunc (x [, y]) - усікає x до у десяткових розрядів. Якщо у дорівнює 0 (значення за замовчуванням), то х усікається до цілого числа. Якщо у менше 0, від відкидаються цифри коду точки.
Тригонометричні функції працюють з радіанами:
acos (x) - арккосинус;
asin (x) - арксинус;
atan (x) - арктангенс;
cos (x) - косинус;
sin (x) - синус;
tan (x) - тангенс.
ceil (fraction) - округлює дробове число до найближчого більшого цілого числа.
floor (fraction) - округлює дробове число до найближчого меншого цілого числа.
number_format ( "number", "decimals", "decimal point", "thousands_sep") - повертає форматований версію зазначеного числа ( "number").
pow (number, exponent) - повертає результат піднесення заданого чіслаnumberв степеньexponent.
rand (min, max) - породжує випадкове число з заданого діапазону.
round (fraction) - округлює дробове число до найближчого цілого числа.
sqrt (number) - повертає квадратний корінь заданого чіслаnumber.
8 питання.Переваги і недостаткіMySQL.
недоліки MySQL
MySQLдействітельно дуже швидкий сервер, але для досягнення цього розроблювачам довелося пожертвувати деякими вимогами до реляційних СУБД.
Немає підтримки зовнішніх (foreign) ключів.
Переваги MySQL:
найкраща швидкість обробки даних на обсязі до 500000 записів;
безкоштовні відкриті ліцензії;
простота використання;
підтримка більшістю хостингових компаній;
можливість використання на різних платформах (Unix, Windows, ін.);
9 питання.Декомпозиція плоскою таблиці.
Сенс декомпозиції полягає в наступному. Плоска таблиця (велика таблиця, в якій зібрані воєдино всі дані для вирішення завдання з високим ступенем повторюваності даних) перетвориться в сукупність взаємопов'язаних окремих таблиць.
визначається кількість сутностей (об'єктів), що описуються плоскої таблицею.
поля плоскої таблиці розділяються між таблицями (об'єктними відносинами), відповідними об'єктами (сутностей);
визначається поле (набір полів), які використовуються в якості ключа для зв'язку між окремими таблицями. Іноді для цієї мети можуть використовуватися спеціальні таблиці (зв'язкові відносини).
жодне з полів у всіх відносинах не повинно містити груп значень. Н
якщо в деяких полях дані повторюються занадто часто, можна створити додаткові таблиці (відносини), які відіграють роль довідників.
Вищевикладена послідовність дій - це кроки нормалізації - методу організації реляційної бази даних з метою скорочення надмірності.
10 Питання.Команди створення баз даних, таблиць і індексів
create database if not exists - Створення бази даних
create table if not exists tovar (ID int unsigned not null auto_increment primary key,
tovar_name char (100) not ,
tovar_mark char (100) not ,
Cena int not ,
data_buy date default curdate (),
family char (100) not null); створення таблиці
створення індексу в стовпці au_idтабліциauthors
create index au_id_ind
Історія розвитку баз даних є історією розвитку систем управління даними у зовнішній пам'яті ЕОМ. На перших електронно-обчислювальних машинах існувало 2 види зовнішніх пристроїв - магнітні стрічки та магнітні барабани. Магнітні стрічки мали досить великий ємністю, але основним їх недоліком було те, що для читання інформації, що знаходиться в середині або кінці стрічки необхідно було прочитати весь попередній ділянку. Магнітні барабани давали можливість довільного доступу до пам'яті, але обсяг інформації, що зберігається на них інформації був обмежений. В той момент говорити про якусь систему управління даними у зовнішній пам'яті не доводилося. Кожна прикладна програма, якою потрібно було зберігати дані в зовнішній пам'яті, сама визначала розташування даних на магнітній стрічці або барабані. Функції інформаційного обміну між оперативною і зовнішньою пам'яттю, іменування і структуризацію даних так само виконувала прикладна програма.
Історія баз даних починається з появою магнітних дисків і налічує понад 30 років. У 1968 р була введена в експлуатацію перша промислова СУБД - система IMS фірми IBM; в 1975 р з'явився перший стандарт СУБД, створена Японською асоціацією по мовам систем обробки даних - CODASYL (Conference of Data System Language). Цей стандарт визначив ряд фундаментальних понять в теорії систем БД, які до сих пір є основоположними для мережевої моделі даних. У 1981 році Е.Ф. Кодд створив реляційну модель даних і застосував до неї операції реляційної алгебри. В історії баз даних можна виділити наступні етапи:
1. Файли і файлові системи.
2. Бази даних на великих ЕОМ. Перші СУБД.
3. Епоха персональних комп'ютерів. Настільні СУБД.
4. Розподілені бази даних.
Важливим кроком у розвитку інформаційних систем стало створення централізованих систем управління файлами (СУФ) - систем, що дозволяють створювати, редагувати, копіювати, переміщати файли. В даний час такі системи входять до складу будь-якої операційної системи. Система управління файлами виконує наступні функції:
· Розподіл зовнішньої пам'яті,
· Відображення імен файлів у відповідні адреси в зовнішній пам'яті,
· Забезпечення доступу до даних.
При цьому СУФ не знає конкретної структури файлу, організація роботи з записами файлу лягає на ту прикладну програму, Яка працює з файлом. Крім того, в СУФ реалізований децентралізований доступ до файлів - всі дії, які конкретний користувач має право проводити з конкретним файлом, закодовані і зберігаються разом з файлом. У СУФ так само було неможливо одночасно працювати з одним файлом декільком користувачам.
Перші бази даних на великих ЕОМ (типу IBM 360/370, ЄС ЕОМ, різних моделях Hewlett Packard) з'явилися в 70-х роках минулого століття. БД зберігалися у зовнішній пам'яті центральної ЕОМ. Користувачами БД були завдання, що запускаються, в основному, в пакетному режимі. Інтерактивний режим доступу забезпечувався за допомогою консольних терміналів, які не володіли власними обчислювальними ресурсами (процесором, оперативною і зовнішньою пам'яттю) і служили тільки пристроями введення-виведення для центральної ЕОМ. Програми доступу до БД писалися на звичайних мовах програмування і запускалися, як звичайні числові програми. СУБД цього періоду працювали з централізованою базою даних в режимі розподіленого доступу, при цьому функції управління розподілом ресурсів виконувалися операційною системою. Крім того, СУБД підтримували мови маніпулювання даними, адміністрування даних. Саме в цей час проводяться серйозні роботи по обґрунтуванню і формалізації реляційної моделі даних.
З появою персональних комп'ютерів змінилися умови використання обчислювальної техніки в організаціях та фірмах: Так як техніка стала доступна, комп'ютери перетворилися в зручний інструмент для ведення документації та облікових функцій фірм. У цей час з'являються так звані настільні СУБД, що дозволяють, з одного боку, зберігати в упорядкованому вигляді великі обсяги інформації, і, з іншого боку, мають зручний інтерфейс для заповнення даних і генерації різних звітів.
Основні відмінні риси цього етапу розвитку БД наступні:
1. Стандартизація високорівневих мов маніпулювання даними - розробка і впровадження стандарту SQL92 в усі СУБД.
2. Всі СУБД були розраховані на створення баз даних з монопольним доступом.
3. Більшість СУБД мали розвинений і зручний призначений для користувача інтерфейс, але при цьому в них були відсутні засоби підтримки посилальної і структурної цілісності даних і засоби адміністрування баз даних.
4. Скромні вимоги до апаратного забезпечення з боку настільних СУБД.
На відміну від настільних СУБД розподілені СУБД орієнтовані на обробку даних, що зберігаються в різних місцях, але логічно пов'язаних один з одним. Вони дозволяють організувати паралельну обробку інформації і підтримку цілісності даних. Особливостями цього етапу розвитку баз даних є наступні:
1. Розподілені СУБД підтримують структурну, мовну і кількість посилань цілісність баз даних.
2. Більшість СУБД можуть працювати на комп'ютерах з різною архітектурою і під різними операційними системами.
3. Всі сучасні розподілені СУБД мають засоби підключення клієнтських додатків, розроблених з використанням настільних СУБД і засоби експорту даних з форматів настільних СУБД третього етапу розвитку.
4. На цьому етапі розроблений ряд стандартів мов опису і маніпулювання даними (SQL89, SQL92, SQL99) і технологій обміну даними між різними СУБД (протокол ODBC).
5. На цьому ж етапі розпочаті роботи, пов'язані з концепцією об'єктно-орієнтованих баз даних. Представниками цього етапу можна вважати MS Access 2000, сучасні сервери баз даних Oracle 7.3, Oracle 8.4, MS SQL 6.5, SQL 7.0, Informix, DB2 та ін.
ПОЯВА СУБД Історія розвитку СУБД налічує більше 30 років. У 1968 році була введена в експлуатацію перша промислова СУБД система IMS фірми IBM. У 1975 році з'явився перший стандарт асоціації по мовам систем обробки даних - Conference of Data System Languages \u200b\u200b(CODASYL), який визначив ряд фундаментальних понять в теорії систем баз даних, які і досі є основними для мережевої моделі даних. У подальший розвиток теорії баз даних великий внесок був зроблений американським математиком Е. Ф. Коддом, який є творцем реляційної моделі даних. У 1981 році Е. Ф. Кодд отримав за створення реляційної моделі і реляційної алгебри престижну премію Тьюринга Американської асоціації з обчислювальної техніки.
ПЕРШИЙ ЕТАП - БАЗИ ДАНИХ НА ВЕЛИКИХ ЕОМ Перший етап розвитку СУБД пов'язаний з організацією баз даних на великих машинах типу IBM 360/370, ЄС-ЕОМ і міні-ЕОМ типу PDP 11 (фірми Digital Equipment Corporation - DEC), різних моделях HP (фірми Hewlett Packard). Бази даних зберігалися у зовнішній пам'яті центральної ЕОМ, користувачами цих баз даних були завдання, що запускаються в основному в пакетному режимі. Інтерактивний режим доступу забезпечувався за допомогою консольних терміналів, які не володіли власними обчислювальними ресурсами (процесором, зовнішньою пам'яттю) і служили тільки пристроями введення-виведення для центральної ЕОМ.
ОСОБЛИВОСТІ ПЕРШОГО ЕТАПУ Всі СУБД базуються на потужних мультипрограмних операційних системах (MVS, SVM, RTE, OSRV, RSX, UNIX), тому в основному підтримується робота з централізованою базою даних в режимі розподіленого доступу. Функції управління розподілом ресурсів в основному здійснюються операційною системою (ОС). Підтримуються мови низького рівня маніпулювання даними, орієнтовані на навігаційні методи доступу до даних. Значна роль відводиться адмініструванню даних.
Проводяться серйозні роботи по обґрунтуванню і формалізації реляційної моделі даних, і була створена перша система (System R), що реалізує ідеологію реляційної моделі даних. Проводяться теоретичні роботи по оптимізації запитів і управлінню розподіленим доступом до централізованої БД, було введено поняття транзакції. Результати наукових досліджень відкрито обговорюються у пресі, йде потужний потік загальнодоступних публікацій, що стосуються всіх аспектів теорії і практики баз даних, і результати теоретичних досліджень активно впроваджуються в комерційні СУБД.
ДРУГИЙ ЕТАП - ЕПОХА персональних комп'ютерів ОСОБЛИВОСТІ ДРУГОГО ЕТАПУ Всі СУБД були розраховані на створення БД в основному з монопольним доступом. І це зрозуміло. Комп'ютер персональний, він не був приєднаний до мережі, і база даних на ньому створювалася для роботи одного користувача. У рідкісних випадках передбачалася послідовна робота декількох користувачів, наприклад, спочатку оператор, який вводив бухгалтерські документи, а потім головбух, який визначав проводки, відповідні первинним документам. Більшість СУБД мали розвинений і зручний призначений для користувача інтерфейс, В більшості існував інтерактивний режим роботи з БД, як в рамках опису БД, так і в рамках проектування запитів. Крім того, більшість СУБД пропонували розвинений і зручний інструментарії для розробки готових додатків без програмування. Інструментальне середовище складалася з готових елементів програми у вигляді шаблонів екранних форм, звітів, етикеток (Labels), графічних конструкторів запитів, які досить просто могли бути зібрані в єдиний комплекс. У всіх настільних СУБД підтримувався тільки зовнішній рівень представлення реляційної моделі, тобто тільки зовнішній табличний вигляд структур даних.
При наявності високорівневих мов маніпулювання даними типу реляційної алгебри і SQL в настільних СУБД підтримувалися низькорівневі мови маніпулювання даними на рівні окремих рядків таблиць. У настільних СУБД були відсутні засоби підтримки посилальної і структурної цілісності бази даних. Ці функції повинні були виконувати додатки, проте убогість засобів розробки додатків іноді не дозволяла це зробити, і в цьому випадку ці функції повинні були виконуватися користувачем, вимагаючи від нього додаткового контролю при введенні і зміні інформації, що зберігається в БД. Наявність монопольного режиму роботи фактично призвело до виродження функцій адміністрування БД і в зв'язку з цим - до відсутності інструментальних засобів адміністрування БД. І, нарешті, остання і зараз дуже позитивна особливість - це порівняно скромні вимоги до апаратного забезпечення з боку настільних СУБД. Цілком працездатні застосування, розроблені, наприклад, на Clipper, працювали на PC 286.
Третій етап - РОЗПОДІЛЕНІ БАЗИ ДАНИХ Добре відомо, що історія розвивається по спіралі, тому після процесу "персоналізації" почався зворотний процес - інтеграція. Множиться кількість локальних мереж, все більше інформації передасться між комп'ютерами, гостро постає завдання узгодженості даних, що зберігаються і обробляються в різних місцях, але логічно один з одним пов'язаних, виникають завдання, пов'язані з паралельною обробкою транзакцій - послідовностей операцій над БД, що переводять її з одного несуперечливого стану в інше несуперечливе стан. Успішне вирішення цих завдань призводить до появи розподілених баз даних, що зберігають всі переваги настільних СУБД і в той же час дозволяють організувати паралельну обробку інформації і підтримку цілісності БД.
ОСОБЛИВОСТІ ТРЕТЬОГО ЕТАПУ Практично всі сучасні СУБД забезпечують підтримку повної реляційної моделі, а саме: структурної цілісності - допустимими є тільки дані, представлені у вигляді відносин реляційної моделі; мовної цілісності, тобто мов маніпулювання даними високого рівня (в основному SQL); посилальної цілісності - контролю за дотриманням посилальної цілісності протягом всього часу функціонування системи, і гарантій неможливості з боку СУБД порушити ці обмеження. Більшість сучасних СУБД розраховані на набір інструментів, написаний архітектуру, тобто вони можуть працювати на комп'ютерах з різною архітектурою і під різними операційними системами, при цьому для користувачів доступ до даних, керованим СУБД, на різних платформах практично невиразний.
Необхідність підтримки багатокористувацької роботи з базою даних і можливість децентралізованого храпения даних зажадали розвитку засобів адміністрування БД з реалізацією загальної концепції засобів захисту даних. Потреба в нових реалізаціях викликала створення серйозних теоретичних праць з оптимізації реалізації розподілених БД і роботі з розподіленими транзакціями і запитами з впровадженням отриманих результатів в комерційні СУБД. Для того щоб не втратити клієнтів, які раніше працювали на настільних СУБД, практично всі сучасні СУБД мають засоби підключення клієнтських додатків, розроблених з використанням настільних СУБД, і кошти експорту даних з форматів настільних
СУБД ТРЕТЬОГО ЕТАПУ РОЗВИТКУ До цього етапу можна віднести розробку ряду стандартів в рамках мов опису і маніпулювання даними (SQL 89, SQL 92, SQL 99) і технологій по обміну даними між різними СУБД, до яких можна віднести і протокол ODBC (Open Data. Base Connectivity), запропонований фірмою Microsoft. Так само до цього етапу можна віднести початок робіт, пов'язаних з концепцією об'єктно БД - ООБД. Представниками СУБД, що належать до другого етапу, можна вважати MS Access 97 і всі сучасні сервери баз даних Огас1 е 7. 3, 0 гас1 е 8. 4, MS SQL 6. 5, MS SQL 7. 0, System 11, Informix, DB 2, SQL Base і інші сучасні сервери баз даних, яких зараз налічується кілька десятків.
ЧЕТВЕРТИЙ ЕТАП - ПЕРСПЕКТИВИ РОЗВИТКУ СИСТЕМ управління базами даних Цей етап характеризується появою нової технології доступу до данним- інтранет. Основна відмінність цього підходу від технології клієнт-сервер полягає в тому, що відпадає необхідність використання спеціалізованого клієнтського програмного забезпечення. Для роботи з віддаленою базою даних використовується стандартний броузер Internet, наприклад Microsoft Internet. Explorer, і для кінцевого користувача процес звернення до даних відбувається аналогічно використанню Internet. При цьому вбудований в завантажуються користувачем HTML-сторінки код, написаний зазвичай на мовах Java, Java-script, Perl і інших, відстежує всі дії користувача і транслює їх в низькорівневі SQL-запити до бази даних, виконуючи, таким чином, ту роботу, якої в технології кліентсервер займається клієнтська програма.
Зручність даного підходу призвело до того, що він став використовуватися не тільки для віддаленого доступу до баз даних, але і для користувачів локальної мережі підприємства. Прості завдання обробки даних, які пов'язані зі складними алгоритмами, які вимагають узгодженої зміни даних у багатьох взаємопов'язаних об'єктах, досить просто і ефективно можуть бути побудовані по даній архітектурі. В цьому випадку для підключення нового користувача до можливості використовувати це завдання не потрібна установка додаткового клієнтського програмного забезпечення. Однак алгоритмічно складні завдання рекомендується реалізовувати в архітектурі «клієнт-сервер» з розробкою спеціального клієнтського програмного забезпечення.
ВИСНОВОК У кожного з перерахованих вище підходів до роботи з даними є свої переваги і свої недоліки, які і визначають область застосування того чи іншого методу, і в даний час всі підходи широко використовуються.
