Конспект лекцій зміст модуль №1 «Основні поняття систем баз даних. Реляційна модель даних» 2



Сторінка1/7
Дата конвертації12.11.2016
Розмір0.69 Mb.
  1   2   3   4   5   6   7



ЗМІСТ


Модуль №1 «Основні поняття систем баз даних. Реляційна модель даних» 2

1.1 Концепція баз даних і знань. Поняття інформація і дані. База даних як модель предметної області. Основні компоненти системи баз даних. СКБД, її функції. Три рівня архітектури системи баз даних (архітектура ANSI/SPARC): внутрішній, концептуальний, зовнішній 2

1.2 Поняття інформація і дані. База даних як модель предметної області. Поле, кортеж, домен. Поняття ключа. Моделі даних 10

1.3 Підхід Кодда. Основні властивості та види відношень. Правила цілісності для реляційної моделі. Реляційна алгебра і реляційне числення 12

1.4 Нормалізація відношень. Нормальні форми. Типи функціональних залежностей. Проектування реляційної бази даних з використанням нормалізації 15

1.5 Семантичне моделювання. Модель об’єкт/відношення (модель Чена), ER-діаграми. 20

Модуль №2 «Інтегроване середовище систем управління базами даних» 21

2.1 Компоненти MS SQL Server. Адміністрування. Фізична і логічна архітектура бази даних та її об’єкти. 21

2.2 Transact-SQL  мова програмування в середовищі MS SQL Server. 25

2.3 Створення бази даних і управління базою даних. Розробка додатка користувача 27


Модуль №1 «Основні поняття систем баз даних. Реляційна модель даних»

1.1 Концепція баз даних і знань. Поняття інформація і дані. База даних як модель предметної області. Основні компоненти системи баз даних. СКБД, її функції. Три рівня архітектури системи баз даних (архітектура ANSI/SPARC): внутрішній, концептуальний, зовнішній

Серед основних напрямків розвитку інформаційних технологій необхідно відмітити наступні тенденції розробки прикладних програм широкого призначення: об’єктно-орієнтований підхід, створення візуальних засобів розробки, підтримка різноманітних систем керування базами даних – DataBase Management Systems (DBMS), використання автоматизованих засобів для проектування даних – Computer-Aided System Engineering (CASE), підтримка програмного забезпечення класу оперативного аналізу даних – On-Line Analytical Processing (OLAP) для систем прийняття рішень.

Розвиток і запровадження в практику об’єктно-орієнтованого підходу в цілому (об’єктно-орієнтоване програмування і проектування програмних систем, об’єктно-орієнтовані технології організації інтерфейсів користувача, виникнення розподілених об’єктних систем і т.п.) зумовило виникнення об’єктно-орієнтованих систем керування базами даних (ОО СКБД).

Програмний продукт, в тому числі і клієнтська прикладна програма, створюється вже на етапі розробки. Помилки при проектуванні даних приводять як мінімум до написання коду більшого об’єму, а як максимум до неможливості виконати запит. Вартість її виправлення дуже висока. Тому важливо, щоб ця частина роботи над проектом була виконана максимально якісно. Саме важливість цього етапу зумовила стрімкий ріст популярності такої категорії програмного забезпечення, як автоматизовані засоби проектування даних – CASE-засоби.

Оперативний аналіз даних OLAP – інформаційна технологія, яка забезпечує аналітикам, управляючим, керівникам можливість вивчати великі об’єми взаємозв’язаних даних за допомогою швидкого інтерактивного їх відображення на різних рівнях деталізації з різних точок зору у відповідності з уявленнями кінцевого користувача про сферу підприємницької діяльності. Засоби OLAP становлять невід’ємну частину сучасних корпоративних систем підтримки прийняття рішень. Цей напрямок індустрії створення програмного забезпечення є одним з тих, який найбільш динамічно розвивається. Більшість провідних виробників програмного забезпечення, включаючи Arbor Software, IBM, Informix, Oracle, Microsoft, Sybase, пропонують OLAP-системи в даному секторі ринку.

Загальна характеристика стану ринку СКБД.

Популярні в наш час реляційні СУБД – Oracle, MS SQL Server, DB2, MySQL та ін. базуються на архітектурі, яка відраховує свою історію ще c 1970-х років. Головне завдання баз даних тоді полягало в тому, щоб підтримати розпочатий в 1960-х роках масовий перехід від паперового обліку господарської діяльності до комп'ютерного. Величезна кількість інформації з паперових документів переносилося в БД облікових систем, які повинні були надійно зберігати всі вхідні відомості і, при необхідності, швидко знаходити їх. Такі вимоги зумовили архітектурні особливості реляційних СУБД, що залишилися до теперішнього часу практично незмінними: нормалізація таблиць, індексування записів і журналювання операцій і т.д.

Однак у 1990-х, з розвитком інтернет, з одного боку, і поширенням аналітичних інформаційних систем і сховищ даних, з іншого, що застосовувалися для управлінського аналізу накопичених в облікових системах відомостей, стало зрозуміло, що характер навантаження в цих видах систем радикально змінюється. Якщо транзакційним додаткам властиві дуже часті дрібні операції додавання або зміни однієї або декількох записів (insert/update), то в разі високонавантажених сайтів і аналітичних систем, картина прямо протилежна – найбільше навантаження створюється порівняно рідкими, але великими вибірками (select) сотень тисяч і мільйонів записів, а в аналітичних системах часто з угрупуваннями і розрахунком підсумкових значень (так званих агрегатів).

Дослідні прототипи реляційних СУБД System R і INGRES були створені в 1970-і рр. Тому обидві системи конструювалися в розрахунку на додатки оперативної обробки транзакцій (on-line transaction processing, OLTP), і в 1980-і рр. їх комерційні двійники (DB2 і IINGES відповідно) отримали визнання в цій галузі. Інші постачальники (наприклад, Sybase, Oracle та Informix) слідували тій же базовый моделі СУБД, в якій реляційні таблиці зберігаються по рядках, для індексації використовуються B-дерева, використовується оптимізатор і підтримуються властивості транзакцій ACID.

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

Середина 2000-х років ознаменувалася бурхливим зростанням NoSQL СУБД. Синонімом NoSQL стала нереляційність, величезні обсяги даних, лінійна масштабованість, кластери, відмовостійкість. Ця назва скоріше характеризує напрямок розвитку інформаційних технологій в сторону від реляційних баз даних.

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

NoSQL СУБД використовують ієрархічний підхід при проектуванні бази даних. Основоположник теорії проектування баз даних К. Дж. Дейт вважає, що NoSQL моделі – це спроба повернутися до ієрархічних моделей 70-80гг. минулого сторіччя. Найпопулярніші неряляційні моделі даних – ключ/значення, документно-орієнтована, колоночно-орієнтована.

Хмарні бази даних – це бази даних, які запускаються на платформах хмарних обчислень, таких як Amazon EC2, GoGrid і Rackspace. Існують дві поширені моделі розгортання: користувачі можуть придбати безпосередньо послугу доступу до баз даних, які обслуговує постачальник хмарного сервісу (база даних як сервіс), або ж запустити бази даних у хмарі незалежно, використовуючи образ віртуальної машини. Серед хмарних баз даних присутні як реляційні, так і такі що використовують моделі даних NoSQL.

За даними аналітичної компанії Gartner Inc. (Табл. 1) за обсягами продажів в 2011р. лідирують компанії-гіганти Oracle, IBM, Microsoft: Oracle (48.8%), IBM (20.2%), Microsoft (17.0%). Відповідно, продаж СУБД цих виробників Microsoft SQL Server, Oracle Database і IBM DB2 займає 90% ринку. Примітно, що вперше четвірку лідерів замикає компанія SAP AG з СУБД Sybase (4.6%). Компанія Gartner помістила SAP/Sybase в квадрант лідерів у звіті "Magic Quadrant for Data Warehouse (DW) Database Management System (DBMS)" ("Магічний квадрант по системах управління базами даних для сховищ даних") за 2013 рік.

Табл. 1


Сучасний ринок систем управління базами даних можна розділити на дві великі групи. Перша група – це так звані настільні, а друга група – серверні СКБД [1],[2].

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

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

Недоліки подібних СКБД не очевидні і стають помітні, як правило, при рості обсягів даних, які зберігаються, і збільшенні кількості користувачів. Звичайно недоліки виявляються в зниженні продуктивності й у виникненні збоїв при роботі після деякого часу використання клієнтських прикладних програм. Причини подібних проблем криються, в основному, в принципі роботи таких СКБД і заснованих на них інформаційних системах (ІС). Вони полягають в опрацюванні даних усередині клієнтської прикладної програми.

Інша проблема настільних СКБД полягає в можливості порушення посилань цілісності даних тому, що єдиним механізмом, що контролює її, є програма користувача. Тому всі клієнтські програми повинні містити відповідний код, і доступ до файлів бази даних (БД) із будь-яких інших програм повинний бути заборонений. На сьогоднішній день відомо більш двох десятків форматів даних настільних СКБД. Найбільш популярними, виходячи з числа проданих копій, є Paradox, FoxPro, Access, “полегшена” версія Microsoft SQL Server.

СКБД архітектури клієнт-сервер реалізовані для декількох платформ; мають зручні адміністративні утиліти; дозволяють здійснювати резервне копіювання даних; підтримують кілька сценаріїв реплікацій; підтримують OLAP і створення сховищ даних; підтримують виконання розподілених запитів і транзакцій; дозволяють використовувати різні засоби проектування даних для створення своїх об'єктів; підтримують засоби розробки і генератори звітів як власного виробництва, так і інших виробників; підтримують як мінімум публікацію даних в Internet. На сьогоднішній день відомо більш двох десятків серверних СКБД.

Можливості найбільш популярних серверних СКБД відбивають сучасні тенденції розвитку ІС, такі як використання багатопроцесорних систем і розподіленої обробки даних, створення розподілених систем, у тому числі з використанням технологій Internet, застосування засобів швидкої розробки прикладних програм, створення систем підтримки прийняття рішень з використанням аналітичної обробки даних, а також вимоги до надійності ІС.

Загальна характеристика баз знань та експертних систем.

Для науково-технічного прогресу характерна зростаюча необхідність вирішення неформалізуємих або погано формалізуємих проблем, алгоритмічне рішення яких або не існує, або не може бути реалізоване в силу їх неповноти, невизначеності, неточності, творчого підходу. Прикладами можуть бути задачі ідентифікації, інтерпретації, розпізнавання, класифікації, прогнозування, діагностики, проектування, контролю та попередження виникнення нештатних ситуацій, тестування, навчання. Вирішення цих проблем потребує “інтелектуалізації” комп’ютера, реалізації технології обробки даних із застосуванням ідей штучного інтелекту. Термін “штучний інтелект” трактується двояко, а саме:


  • штучна система, що імітує вирішення людиною складних задач в процесі її життєдіяльності;

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

При вивченні інтелектуальних систем традиційно присутня інформація, яку називають знаннями. Інтелектуальну систему можна сприймати як деякий комп’ютерний аналог спеціаліста вузького профілю, який буде здатний вирішувати проблеми в який-небудь предметній області на тому ж рівні компетентності, на якому працюють спеціалісти в даній області, експерти. В 80-ті роки завдяки досягненням в галузі штучного інтелекту з’явилося багато систем, що базувались на використанні знань. Найбільш розповсюдженим видом інтелектуальних систем є експертні системи (ЕС). ЕС – це система, яка забезпечує створення та використання за допомогою обчислювальної машини баз знань експертів, тобто спеціалістів в конкретній предметній галузі. Основні компоненти ЕС показані на рис. 2.24.

Для експертної системи, за аналогією з відомим виразом Вірта: “дані+алгоритми=програми”, справедливий наступний вираз: “знання+висновок=експертна система”. Таким чином, база знань і модуль логічного висновку утворюють ядро експертної системи. База знань може трактуватись як сукупність основних відомостей, які відносяться до певної області знань, тобто деяким чином представлена інформація про конкретну предметну область; факти, закономірності, правила, евристичні припущення.

Знання – вид інформації (подібно до програм та даних), яка зберігається в базах знань і відображає знання людини – спеціаліста (експерта) в певній предметній галузі . Знання можуть бути представлені в формі даних. Зокрема, в вигляді тексту на деякій формальній мові, в вигляді мережі, яка задає зв’язки різного роду між елементами знань. Отже, знання є деяка більш висока ступінь організації даних, що допускає спеціальну інтерпретацію. Від мови програмування потребується забезпечити такі засоби представлення даних, щоб інтерпретатор міг розглядати дану сукупність даних як знання [12].

Рис. 2.24. Структура експертної системи.
Знання відображає безліч всіх поточних ситуацій в об’єктах даного типу та способи переходу від одного опису об’єкта до іншого. Для знань характерні внутрішня інтерпретуємість, структуруємість, зв’язність та активність. Образне формулювання знань: “знання=факти+переконання+правила”. Найбільш часто в системах штучного інтелекту знання представлені у вигляді:


  • семантичних мереж;

  • фреймів;

  • правил продукції;

  • формальних логічних моделей.

Системи керування базами даних. Технологія файл-сервер і клієнт-сервер

Розпізнають централізовані та розподілені системи БД. Централізована БД зберігається в пам'яті однієї обчислювальної системи, тобто розміщена на одному комп’ютері. Розподілена БД складається з декількох частин, розміщених на різних машинах обчислювальної мережі.

Системи централізованих БД поділяються в залежності від архітектури. Системи централізованих БД, в яких СКБД і прикладна програма розміщені на одному комп’ютері і мережна підтримка не потрібна, є застарілою. Розглянемо архітектури файл-сервер і клієнт-сервер. Цими термінами визначають перш за все архітектуру або логічне розподілення функцій. Клієнт – це прикладна програма, яку також називають прикладною програмою переднього плану (frontend), а сервер – це прикладна програма заднього плану (backend).

В архітектурі файл-сервер БД розміщується на файл-сервері (або на декількох серверах). В якості останнього може використовуватись більш потужна машина із усіх, об’єднаних в мережу. Функції файл-сервера полягають в основному в збереженні БД та забезпеченні доступу до них користувачів, які працюють на різних комп’ютерах. Файли БД у відповідності з запитами користувачів передаються на робочі станції, де в основному і виконується обробка. Передані дані оброблюються СКБД, яка знаходиться на комп’ютерах користувачів. Після того як користувачі виконають необхідні зміни, вони копіюють файли знову на файл-сервер, де інші користувачі, в свою чергу, можуть знову їх використовувати. Явним недоліком подібного підходу є висока ймовірність втрати змін, виконаних одними користувачами, при записуванні змінених файлів на центральний сервер.

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

Рис. 2.1 Архітектура клієнт-сервер.
Архітектура клієнт-сервер, для якої призначені серверні СКБД, є деякою мірою поверненням до колишньої "мейнфреймової" моделі, заснованої на централізації збереження й обробки даних на одному виділеному комп'ютері, де функціонує спеціальна прикладна програма або сервіс, що називається сервером БД. Сервер БД відповідає за роботу з файлами БД, підтримку цілісності посилань, резервне копіювання, забезпечення авторизованого доступу до даних, протоколювання операцій і, звичайно, за виконання запитів користувача на вибір і модифікацію даних і метаданих (визначення інших об’єктів системи). Клієнтські прикладні програми, що є джерелами цих запитів, функціонують на персональних комп'ютерах у мережі. Можна відзначити, що при використанні серверних СКБД виконання запитів виробляється самим сервером, тому клієнтські прикладні програми одержують від сервера тільки результати самого запиту і не вимагають передачі всього індексу чи всієї таблиці, що істотно знижує мережний трафік при обробці запитів.

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

Сучасні серверні СКБД мають такі сервіси: реалізація для декількох платформ; зручні утиліти адміністрування; резервне копіювання даних; обслуговування реплікацій (копіювання даних в декілька інших БД); паралельна обробка даних в багатопроцесорних системах; підтримка OLAP і створення сховищ даних; виконання розподілених запитів і транзакцій; автоматизовані засоби проектування даних; підтримка Web-технологій.

У процесі роботи СКБД виникає необхідність захисту БД від випадкових та навмисних ситуацій, коли існує імовірність втрати даних. Одним із засобів вирішення цієї проблеми є механізм транзакцій. Транзакція (Transaction) – це логічна послідовність операцій над даними (читання, віддалення, вставки, модифікації), неподільна з точки зору впливу на БД, яка або виконується вся разом, або вся разом скасовується. Завершення (Commit) транзакції означає, що всі операції, що входять до складу транзакції, успішно завершені, і результат їхньої роботи збережений у базі даних. Відкат (Rollback) транзакції означає, що усі уже виконані операції, що входять до складу транзакції, скасовуються і всі об'єкти БД, порушені цими операціями, повернуті у вихідний стан. Для реалізації можливості відкату транзакцій деякі СКБД підтримують запис у log-файли, що дозволяють відновити вихідні дані при відкоті. Транзакція може складатися з декількох вкладених транзакцій. Деякі СКБД підтримують двофазне завершення транзакцій – процес, що дозволяє здійснювати транзакції над декількома БД, що відносяться до одній і тієї ж СКБД. Для підтримки розподілених транзакцій (тобто транзакцій над БД, керованих різними СКБД), існують спеціальні засоби, що звуться моніторами транзакцій.

Крім зазначених переваг сучасні серверні СКБД володіють можливістю оптимізації запитів, яка виконується спеціальним компонентом СКБД  оптимізатором запитів. В оброблювачі запитів СКБД MS SQL Server [5] реалізовано нові методи пошуку, які підвищують швидкість обробки комплексних запитів. SQL Server використовує техніку перетину та з'єднання індексів для таблиць з декількома індексами, нові методи пошуку, які підвищують швидкість обробки комплексних запитів. SQL Server підтримує паралельне виконання запитів, підтримку розподілених транзакцій, що дозволяє сполучати в один запиті віддалені сервери. Не дивлячись на це, не можна вважати, що знайдено адекватне вирішення задачі глобальної оптимізації в розподіленій СКБД.

Розподілені бази даних

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

Розподілена система БД (рис. 2.2) означає, що окрема прикладна програма може “прозоро” обробляти дані, розподілені між множиною різних БД, керування якими здійснюють різні СКБД, які працюють на з’єднаних комунікаційними мережами машинах різних типів з різними операційними системами. Поняття “прозоро” означає, що прикладна програма виконує обробку даних з логічної точки зору так, якби управління даними повністю здійснювалося однією СКБД, яка працює на одній машині. Тобто клієнт може отримувати доступ до будь-якої кількості серверів одночасно (за один запит можливо отримати дані з двох і більше серверів). В цьому випадку сервери розглядаються клієнтом як єдиний сервер (з логічної точки зору) і користувач може не знати, на який машині знаходиться та або інша частина даних. Фундаментальний принцип розподіленої системи БД можна сформулювати так: для користувача розподілена система повинна виглядати так, як нерозподілена .

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

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

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

Традиційно виділяють однорідні і неоднорідні розподілені БД. В однорідних розподілених БД кожна локальна БД керується однією й тією ж СКБД. На відміну від цього, в неоднорідній системі локальні БД можуть відноситись до різних моделей даних, тому мережна інтеграція неоднорідних БД – це актуальна, але складна проблема. Багато рішень відомі на теоретичному рівні, але поки що не вдається подолати головну проблему – недостатню ефективність інтегрованих систем. Вирішенні цієї проблеми в значній мірі сприяє стандартизація мови SQL та загальне слідування виробників СКБД принципам відкритих систем.


Рис. 2.2 Розподілена система БД.


Основною ідеєю відкритих систем є cпрощення сполучення обчислювальних систем за рахунок стандартизації апаратної та програмної частини. Головною причиною розвитку концепції відкритих систем є перехід до використання локальних обчислювальних мереж та проблеми спряження апаратно-програмних засобів, які викликали цей перехід. В зв’язку з розвитком технології глобальних комунікацій відкриті системи набувають ще більше значення та масштабність.

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

Розглянемо класифікацію прикладних програм, які використовують БД. Почнемо їхній розгляд з прикладних програм, що працюють в архітектурі клієнт-сервер. ІС, створені в такій архітектурі, являють собою сервер БД, який маніпулює даними, і клієнтську прикладну програму, що звертається до нього і використовує для цього або клієнтські API, або один з універсальних механізмів доступу до даних. Звичайно при використанні такої архітектури прикладних програм на сервер БД покладається також контроль дотримання бізнесів-правил, реалізованих у виді збережених процедур, тригерів, серверних обмежень і інших об'єктів БД. Для створення клієнтських прикладних програм у цьому випадку найчастіше застосовуються засоби розробки, що володіють розвинутими візуальними інструментами, такі як Microsoft Visual Basic, Borland Delphi, Sybase PowerBuilder, Borland C++Builder. В теперешній час найбільш популярним середовищем розробки є Visual Studio. Visual Studio надає засоби проектування, розробки, налагодження та розгортання веб-додатків, XML веб-служб і традиційних клієнтських додатків, а також інших типів проектів на мовах програмування Visual Basic, Visual C#, Visual C++, Visual F#. F # – це мова програмування, що забезпечує підтримку функціонального програмування, а також об'єктно-орієнтованого та імперативного (процедурного) програмування.

Слід зазначити, однак, що вибір архітектур сучасних прикладних програм не вичерпується "класичною" архітектурою клієнт-сервер, яка припускає, що прикладна програма складається із сервера БД і клієнтських прикладних програм, взаємодіючих з цим сервером. Існують так звані розподілені прикладні програми. Розподілені (або багатоланкові) прикладні програми звичайно складаються з презентаційних сервісів, сервісів бізнес-логіки, реалізованих у вигляді бізнес-об'єктів і сервісів даних (звичайно складаються із сервера БД і механізмів доступу до даних). Сервіси бізнес-логіки призначені для одержання введених користувачем даних від презентаційних сервісів, взаємодії із сервісами даних для виконання бізнес-операцій (наприклад, обробки або замовлень розрахунку бухгалтерського балансу) і повернення результатів цих операцій презентаційним сервісам. Деякі з бізнес-об'єктів можуть звертатися до сервісів даних, використовуючи ті або інші механізми доступу до даних. Оскільки кінцевий користувач не взаємодіє безпосередньо з бізнес-об'єктами, останні звичайно не мають інтерфейсу користувача у звичному розумінні. Фізично бізнес-об'єкти можуть бути реалізовані у виді сервісів операційної системи, консольних прикладних програм або Windows-прикладних програм, а також у вигляді бібліотек, які завантажуються в адресний простір спеціально призначеної для цієї мети серверної прикладної програми (Web-сервера, сервера прикладних програм і т. ін.). Для створення бізнес-об'єктів застосовуються як засоби розробки з розвинутими візуальними інструментами, так і засоби розробки, орієнтовані на “ручне” створення коду. Відзначимо, що новітні версії майже усіх найбільш популярних засобів розробки Windows-прикладних програм (Microsoft Visual Basic, Visual FoxPro і Visual C++, Borland Delphi і C++Builder, Sybase PowerBuilder) підтримують створення різних типів бізнес-об'єктів (Web-прикладних програм, ASP-об'єктів, COM-серверів і ін.), за винятком, мабуть, Microsoft Access – цей продукт розрахований скоріше на кваліфікованих користувачів, ніж на розроблювачів розподілених систем. Нерідко для цієї мети використовуються і засоби створення Java-прикладних програм (такі як Borland JBuilder).

Дані, які використовуються для опису предметної області, можна представити у вигляді трьохрівневої схеми (так звана модель ANSI/SPARC) (рис. 2.4).


Рис. 2.4 Архітектура ANSI/SPARC.
Розрізняють концептуальний, внутрішній і зовнішній рівні даних БД, яким відповідають моделі аналогічного призначення. Концептуальний рівень відповідає логічному уявленню даних предметної області в узагальненому виді. Це – ядро проектування БД. Концептуальна модель складається з логічно структурованих різних типів даних. Внутрішній рівень відображає організацію даних у середовищі збереження і відповідає фізичному уявленню даних. Внутрішня модель складається з окремих записів, фізично збережених у зовнішніх носіях. Зовнішній рівень підтримує подання даних, які необхідні конкретним користувачем. За допомогою зовнішніх моделей підтримується доступ до різних прикладних програм.

Зовнішня схема даних є сукупністю вимог до даних з боку деякої конкретної функції, виконуваної користувачем. Концептуальна схема є повною сукупністю усіх вимог до даних, отриманої з уявлень користувача про реальний світ. Внутрішня схема – це сама БД. Звідси випливають основні етапи, на які розбивається процес проектування БД для ІС.


  1   2   3   4   5   6   7


База даних захищена авторським правом ©lecture.in.ua 2016
звернутися до адміністрації

    Головна сторінка