ПРОЕКТИ-ЗАВДАННЯ (ПРОЕКТ_НОМЕР, ПРОЕКТ_ЗАВДАННЯ).

 

Обидва ці відношення знаходяться в 4НФ.

Розглянемо ще один приклад. Нехай задано відношення

 

R (СТУДЕНТ, ТОВАРИСТВО, СУСПІЛЬНА_РОБОТА, РІК).

 

Атрибут ТОВАРИСТВО визначає назву товариств, членом яких є студент; атрибути СУСПІЛЬНА_РОБОТА І РІК - найменування суспільних доручень, виконуваних студентом, і рік їх призначення. Передбачається, що те саме суспільне навантаження не може бути призначена двічі протягом одного року тому ж самому студенту, але заміна одного навантаження на інше протягом року допускаються. У табл.4.16 приведений фрагмент відношення.

 

Таблиця 4.16. - Приклад відношення з нетривіальними залежностями

Виділимо нетривіальні багатозначні залежності:

 

СТУДЕНТ ->-> ТОВАРИСТВО;

СТУДЕНТ ->-> (СУСПІЛЬНА_РОБОТА, РІК).

 

Вважаємо, що атрибут ТОВАРИСТВО не залежить від того, яку суспільну роботу веде студент. Атрибути СУСПІЛЬНА_РОБОТА і РІК взаємозалежні.

Наявність подібних нетривіальних багатозначних залежностей у схемі одного відношення і незалежність їхніх правих частин в остаточному підсумку приводять до комбінації значень правих частин, що ілюструється в табл.4.16. Відомості про те, що студент Іванов є старостою групи у 1999 р. повторюються двічі в силу того, що він є членом двох товариств (ВТВР, ДТСААФ). Для студента Петрова в зв'язку зі зміною суспільної роботи (1999 - 2000 р.) доводиться вводити додаткові кортежі, у яких буде повторюватися інформація про членство студента в товариствах ВТВР і ДТСААФ.

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

 

Таблиця 4.17 - Приклад відношення в четвертій нормальній формі

 

Таблиця 4.18 - Приклад відношення четвертій нормальній формі

 

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

Розглянемо відношення

 

СПІВРОБІТНИКИ - ВІДДІЛИ - ПРОЕКТИ (СПІВРОБ_НОМЕР, ВІДДІЛУ_НОМЕР, ПРОЕКТУ_НОМЕР).

 

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

Відношення R (X, Y, ..., Z) задовольняє залежності з'єднання * (X, Y, ..., Z) у тому і тільки в тому випадку, коли R відновлюється без втрат шляхом з'єднання своїх проекцій на X, Y, ..., Z.

Відношення R знаходиться в п'ятій нормальній формі у тому і тільки в тому випадку, коли будь-яка залежність з'єднання в R випливає з існування деякого можливого ключа в R.

Введемо наступні імена складових атрибутів:

З = {СПІВРОБ_НОМЕР, ВІДДІЛУ_НОМЕР};

СП = {СПІВРОБ_НОМЕР, ПРОЕКТУ_НОМЕР};

ВП = {ВІДДІЛУ_НОМЕР, ПРОЕКТУ_НОМЕР}.

Припустимо, що у відношенні СПІВРОБІТНИКИ - ВІДДІЛИ - ПРОЕКТИ існує залежність з'єднання: * (З, СП, ОП).

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

 

СПІВРОБІТНИКИ - ВІДДІЛИ (СПІВРОБ_НОМЕР, ВІДДІЛУ_НОМЕР),

СПІВРОБІТНИКИ - ПРОЕКТИ (СПІВРОБ_НОМЕР, ПРОЕКТУ_НОМЕР),

ВІДДІЛИ - ПРОЕКТИ (ВІДДІЛУ_НОМЕР, ПРОЕКТУ_НОМЕР).

П'ята нормальна форма - це остання нормальна форма, яку можна одержати шляхом декомпозиції.

 

На закінчення приведемо послідовність етапів нормалізації:

1. Перехід від структурної моделі даних до плоских двовимірних відношень (таблиць).

2. Усунення всіх неповних залежностей атрибутів, які не є основними, від усіх ймовірних ключів.

3. Усунення всіх транзитивних залежностей атрибутів, які не є основними, від усіх ймовірних ключів.

4. Усунення всіх нетривіальних багатозначних залежностей атрибутів, які не є основними, від усіх ймовірних ключів.

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

Контрольні запитання.

1. Для чого виконується нормалізація відношень?

2. Які залежності між атрибутами називають транзитивними та функціонально повними?

3. Приведіть приклади відношень в різних нормальних формах.

4. Приведіть послідовність етапів нормалізації.

 

 

 

9. АДМІНІСТРУВАННЯ БАЗ ДАНИХ

Загальні задачі адміністрування БД

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

Адміністратор - це спеціаліст, який володіє інформацією про інформаційні потреби кінцевих користувачів, працює в тісному контакті з користувачами і відповідає за визначення, завантаження, захист та ефективність експлуатації баз даних.

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

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

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

 

 

Риc.1.4 - Схема взаємодії колективу адміністраторів

 

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

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

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

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

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

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

9.1. Завдання адміністрування даних.

Адміністрування даних - Керування інформаційними ресурсами, включаючи планування бази даних, розробку й впровадження стандартів, визначення обмежень і процедур, а також концептуальне й логічне проектування баз даних.

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

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

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

 

Нижче перераховані основні завдання адміністрування даних:

1. Вибір підходящих інструментів розробки.

2. Допомога в розробці корпоративних стратегій побудови інформаційної системи, розвитку інформаційних технологій і бізнес - стратегій.

3. Попередня оцінка осуществимости й планування процесу створення бази даних.

4. Розробка корпоративної моделі даних.

5. Визначення вимог організації до використовуваних даних.

6. Визначення стандартів збору даних і вибір формату їхнього подання.

7. Оцінка обсягів даних й імовірності їхнього росту,

8. Визначення способів й інтенсивності використання даних.

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

10. Концептуальне й логічне проектування бази даних.

11. Взаємодія з АБД і розроблювачами додатків з метою забезпечення відповідності створюваних додатків всім існуючим вимогам.

12. Навчання користувачів - вивчення існуючих стандартів обробки даних й юридичної відповідальності за їхнє некоректне застосування.

13. Постійна модернізація використовуваних інформаційних систем і технологій у міру розвитку бізнесів-процесів.

14.Забезпечення повноти всієї необхідної документації, включаючи корпоративну модель, стандарти, обмеження, процедури, використання словника даних, а також елементи керування роботою кінцевих користувачів.

15. Підтримка словника дані організації.

16. Взаємодія з кінцевими користувачами для визначення нових вимог і дозволу проблем, пов'язаних з доступом до даних і недостатньою продуктивністю їхньої обробки.

 

9.2. Користувачі банків даних

Як будь-який програмно-організаційно-технічний комплекс, банк даних

існує в часі й у просторі. Він має визначені стадії свого

розвитку:

1. Проектування.

2. Реалізація.

3. Експлуатація.

4. Модернізація і розвиток.

5. Повна реорганізація.

На кожнім етапі свого існування з банком даних зв'язані різні категорії

користувачів.

Визначимо основні категорії користувачів і їхня роль у функціонуванні банку

даних:

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

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

планує роботу сервісного відділу комп'ютерної фірми, має у своєму

розпорядженні програму, що допомагає йому планувати і розподіляти поточні

замовлення, контролювати хід їхнього виконання, замовляти на складі необхідні

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

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

- Розроблювачі й адміністратори додатків. Це група користувачів, що функціонує під час проектування, створення і реорганізації банку даних. Адміністратори додатків координують роботу розроблювачів при розробці конкретного додатка або групи додатків, об'єднаних у функціональну підсистему. Розроблювачі конкретних додатків працюють з тією частиною інформації з бази даних, що потрібно для конкретного додатка.

Не в кожнім банку даних можуть бути виділені всі типи користувачів. При розробці СУБД адміністратор банку даних, адміністратор додатку і розроблювач часто існували в одній особі. Однак при побудові сучасних складних

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

Найбільш складні обов'язки покладені на групу адміністратора БД.

Розглянемо їхній більш докладно. У складі групи адміністратора БД повинні бути:

- системні аналітики;

- проектувальники структур даних і зовнішнього стосовно банку даних інформаційного забезпечення;

- проектувальники технологічних процесів обробки даних;

- системні і прикладні програмісти:

- оператори і фахівці з технічного обслуговування.

Якщо мова йде про комерційний банк даних, то важливу роль тут грають

фахівці з маркетингові.

 

9.3. Основні функції групи адміністратора БД

1. Аналіз предметної області: опис предметної області, виявлення обмежень цілісності, визначення статусу (приступності, таємності) інформації, визначення потреб користувачів, визначення відповідності "дані - користувач", визначення об'ємно-тимчасових характеристик обробки даних.

2. Проектування структури БД: визначення складу і структури файлів БД і зв'язків між ними, вибір методів упорядкування даних і методів доступу до інформації, опис БД мовою опису даних (МОД).

3. Завдання обмежень цілісності при описі структури БД і процедур обробки БД:

- завдання декларативних обмежень цілісності, властивих предметної області;

- визначення динамічних обмежень цілісності, властивих предметної області в процесі зміни інформації, що зберігається в БД;

- визначення обмежень цілісності, викликаних структурою БД;

- розробка процедур забезпечення цілісності БД при введенні і коректуванні даних;

- визначення обмежень цілісності при рівнобіжній роботі користувачів у багато - користувацькому режимі.

4. Первісне завантаження і ведення БД:

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

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

- відповідно до розробленої технології первісного завантаження може знадобитися проектування системи первісного введення даних.

5. Захист даних:

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

- розробка принципів захисту конкретних даних і об'єктів проектування;

- розробка спеціалізованих методів кодування інформації при її циркуляції в локальній і глобальної інформаційних мережах;

- розробка засобів фіксації доступу до даних і спроб порушення системи зашиті;

- тестування системи захисту;

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

6. Забезпечення відновлення БД:

- розробка організаційних засобів архивирования і принципів відновлення БД;

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

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

8. Аналіз ефективності функціонування БД:

- аналіз показників функціонування БД;

- планування реструктуризації (зміна структури) БД і реорганізації БнД.

9. Робота з кінцевими користувачами:

- збір інформації про зміну предметної області;

- збір інформації про оцінку роботи БД;

- навчання користувачів, консультування користувачів;

- розробка необхідної методичної і навчальної документації по роботі кінцевих користувачів.

10. Підготовка і підтримка системних засобів:

- аналіз існуючих на ринку програмних засобів і аналіз можливості і необхідності їхнього використання в рамках БД;

- розробка необхідних організаційних і програмно-технічних заходів щодо розвитку БД;

- перевірка працездатності закуповуваних програмних засобів перед підключенням їх до БД;

- курирування підключення нових програмних засобів до БД.

11. Організаційно-методична робота з проектування БД:

- вибір або створення методики проектування БД;

- визначення цілей і напрямку розвитку системи в цілому;

- планування етапів розвитку БД;

- розробка загальних словників-довідників проекту БД і концептуальної моделі;

- стикування зовнішніх моделей розроблювальних додатків;

- курирование підключення нового додатка до діючої БД;

- забезпечення можливості комплексного налагодження безлічі додатків,

взаємодіючих з однієї БД.

 

Контрольні запитання.

1. В чому полягає відмінність функцій прикладного програміста і аналітика?

Мовні засоби банку даних

Язикові засоби СУБД, необхідні для опису даних, організації спілкування й виконання процедур пошуку й різних перетворень даних. Класифікація язикових засобів Бнд, показана на мал. 2.2, розроблена американським комітетом CODASYL по проектуванню й створенню БД.

 

 

Рис.2.2. Схема класифікації мовних засобів БнД

 

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

Мова опису даних (DDL - Data Defіnіtіon Language), призначена для опису даних на різних рівнях абстракції: зовнішньому, логічному й внутрішньому.

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

У відомих й широко використовуваних на практиці СУБД родини dBASE застосовується єдина мова опису даних. Вона призначена для подання даних на логічному й фізичному рівнях. Ця мова має свій синтаксис: наприклад, ім'я файлу не повинне перевищувати восьми символів, а ім'я поля – десяти. При цьому кожне ім'я може починатися з букви, поля календарної дати позначаються символом D (DATA), символьні поля - С (CHARACTER), числові - N (NUMERІ), логічні - L (LOGІCAL), приміток - М (MEMO).

Опис всіх імен, типів і розмірів полів зберігається в пам'яті разом з даними; ці структури якщо буде потреба, можна переглянути й виправити.

Якщо логічний і фізичний рівні відділені, то до складу СУБД може входити мова опису збереження даних.

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

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

Мова маніпулювання даними (DML - Data Manіpulatіon Language) використається для обробки даних, їхніх перетворень і написання програм. DML може бути базовою або автономною.

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

значно простіше для оволодіння, чим мова програмування.

Автономна мова DML - це власна мова СУБД, що дає можливість виконувати різні операції з даними. Системи із власною мовою називають закритими.

У сучасних СУБД для спрощення процедур пошуку даних у БД передбачена мова запитів. Найпоширенішими мовами запитів є SQL й QBE.

Мова запитів SQL (Structured Query Language - структурована мова запитів)був створений фірмою ІBM у рамках роботи над проектом побудови системи керування реляційними базами даних на початку 70-х років. Американський національний інститут стандартів (ANSІ) поклав цю мову в основу стандарту мов реляційних баз даних, прийнятого Міжнародною організацією стандартів (ІSO). Ядром існуючого стандарту SQL-86, які часто називають SQL-2 або SQL-92, є функції, реалізовані практично у всіх відомих комерційних реалізаціях мови, а повний стандарт уміщає такі вдосконалення, які деякі розроблювачі будуть повинні ще реалізувати.

Крім стандарту SQL-86 існує комерційний стандарт мови SQL, розроблений консорціумом виробників баз даних SQL Access Group. Ця група створила такий варіант мови, що використається більшістю систем і дає можливість їм "розуміти" одна іншу.

Був розроблений стандартний інтерфейс мови CLІ (Common Language Іnterface)

для всіх основних варіантів мови SQL. Цей інтерфейс, формалізований фірмою Mіcrosoft, одержав назву ODBC (Open DataBase Connectіvіty – відкритий доступ до даних). ODBC - це інтерфейс доступу до даних, які зберігаються під керуванням різних СУБД. ODBC має цілий набір драйверів, за допомогою яких одна СУБД може працювати з даними інших систем. Архітектура ODBC зображена на рис 2.3.

 

 

Рис. 2.3. Архітектура ODBC

 

Мова запитів QBE (Query By Example)- це реалізація запитів за зразком

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

надану системою таблицю QBE і визначити в ній критерії пошуку й вибору даних.

 

Розроблені мови маніпулювання даними, що дозволяють реалізувати всі операції реляційної алгебри і практично будь-які їх сполучення. Серед них найбільше поширені SQL (Structured Query Language - структуризована мова запитів) і QBE (Query-By-Example - запити за зразком) .

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

 

Моделі, засновані на мовах розмітки документів, зв'язані, насамперед , зі стандартною загальною мовою розмітки - SGML (Standard Generalіzed Markup

Language), що був затверджений ІSO як стандарт ще в 80-х роках. Ця мова призначена для створення інших мов розмітки, він визначає припустимий набір тегів (посилань), їхні атрибути і внутрішню структуру документа. Контроль за правильністю використання тегів здійснюється за допомогою спеціального набору правил, називаних DTD-описами (Documents Type Definitions), які використовуються програмою клієнта при розборі документа. Для кожного класу документів визначається свій набір правил, що описують граматику відповідної мови розмітки. За допомогою SGML можна описувати структуровані дані, організовувати інформацію, що утримується в документах, представляти цю інформацію в деякому стандартизованому форматі. Але через деяку свою складність SGML використовувався в основному для опису синтаксису інших мов (найбільш відомим з яких є HTML), і деякі додатки працювали з SGML-документами прямо.

Набагато більш проста і зручний, чим SGML, є мова HTML (от HyperText Markup Language — «язык разметки гипертекста») дозволяє визначати оформлення елементів документа і має якийсь обмежений набір інструкцій - тегів, за допомогою яких здійснюється процес розмітки. Інструкції HTML у першу чергу призначені для керування процесом виводу вмісту документа на екрані програми-клієнта і визначають цим самим спосіб представлення документа, але не його структуру. HTML является компьютерным языком программирования, предназначенным для разработки web-страниц (документов HTML).

Як елемент гіпертекстової бази даних, описуваної HTML, використовується текстовий файл,що може легко передаватися по мережі з використанням протоколу HTTP. Ця особливість, а також те, що HTML є відкритим стандартом, і величезна кількість користувачів має можливість застосовувати можливості цієї мови для оформлення своїх документів, безумовно, уплинули на ріст популярності HTML і зробили його сьогодні головним механізмом представлення інформації в Іnternet.

Однак HTML сьогодні вже не задовольняє повною мірою вимогам, пропонованим сучасними розроблювачами до мов подібного роду. І йому на зміну була запропонована нова мова гіпертекстової розмітки, могутня, гнучка і, одночасно з цим, зручна мова XML(Extensіble Markup Language).

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