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

[ виправити ] текст може містити помилки, будь ласка перевіряйте перш ніж використовувати.

скачати

План

1. Бази даних: визначення

2. Основні моделі даних

3. Зв'язування таблиць

4. Нормалізація відносин

5. Мови запитів SQL і QBE

1. Бази даних: визначення

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

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

У процесі розвитку засобів обробки даних були виявлені такі характерні риси "ідеальних" інформаційних систем обробки інформації.

Обробка постійних (перманентних) даних.

Централізована обробка даних на основі стандартів.

Інтеграція даних.

Незалежність (самодостатність) даних від програм обробки.

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

Ефективність обробки даних.

Мова керування даними.

Найбільш повно задовольняють поданням про "ідеальної" інформаційній системі обробки даних саме системи з базами даних.

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

Розглянемо докладно дане визначення і його елементи:

а) предметна область - фрагмент реального світу, що підлягає автоматизації.

Предметна область містить тільки ті сутності, їх взаємозв'язку і процеси зміни сутностей і взаємозв'язків, які необхідні для коректної роботи розглядається (розробляється) автоматизованої системи.

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

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

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

в) структуровані дані - дані, елементи яких упорядковані у відповідності з деякими угодами. До кожного елементу структурованих даних можна звернутися непосредованно, використовуючи інформацію про структуру. Наприклад, якщо дані зберігаються в таблиці, то ім'я п'ятого учня ми можемо отримати з осередку, що знаходиться на перетині стовпця "Ім'я" та п'ятого рядка таблиці, якщо дані структуровані за допомогою таблиці. Крім визначення правила розташування елементів даних в загальному сховищі даних структурування часто має на увазі визначення типу даних - тобто способу їх подання та обсягу необхідної для їх зберігання пам'яті.

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

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

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

2. Основні моделі даних

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

ієрархічна,

мережева,

реляційна.

Крім того, в останні роки з'явилися і стали більш активно впроваджуватися на практиці такі моделі даних:

постреляціонная,

багатовимірна,

об'єктно-орієнтована.

Розробляються також всілякі системи, засновані на інших

моделях даних, розширюють відомі моделі. У їх числі можна назвати

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

У деяких СУБД підтримується одночасно кілька моделей

даних.

Розглянемо реляційну і об'єктно-орієнтовану модель даних.

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

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

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

Атрибути представляють собою властивості, що характеризують суть.

У структурі таблиці кожному атрибуту відповідає заголовок деякого стовпця таблиці.

Кожному екземпляру сутності відповідає рядок таблиці - кортеж.

Домен представляє собою безліч всіх можливих значень певного атрибуту відносини.

Схема відношення (заголовок відносини) являє собою список імен атрибутів. Безліч кортежів відносини часто називають вмістом (тілом) відносини.

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

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

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

Ключі використовують для досягнення наступних цілей:

1) виключення дублювання значень в ключових атрибутах;

2) впорядкування кортежів. Можливо впорядкування за зростанням або за спаданням всіх ключових атрибутів, а також змішане упорядкування - за одними - зростання, за іншими - спадання;

3) прискорення роботи з кортежами відносини;

4) організації зв'язування таблиць.

Нехай у відношенні R1 є не ключовий атрибут А, значення якого є значеннями ключового атрибуту У іншого ставлення R2. Тоді кажуть, що атрибут А відносини R1 є зовнішній ключ.

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

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

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

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

З. Всі рядки однієї таблиці повинні мати одну структуру, що відповідає іменам і типах стовпців.

4. Порядок розміщення рядків в таблиці може бути довільним.

3. Зв'язування таблиць

При проектуванні реальних БД інформацію зазвичай розміщують у кількох таблицях. При цьому зазвичай дані в таблицях логічно пов'язані.

У реляційних СУБД для завдання таких зв'язків виконують операцію їх зв'язування.

Зв'язування таблиць дозволяє:

а) засобами СУБД автоматично виконувати контроль цілісності вводяться в базу даних;

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

Зв'язування виконується по полях зв'язку, які можуть бути звичайними або ключовими.

Використовуються такі основні типи зв'язків:

а) один до багатьох (1: M);

б) багато до одного (M:

1):

в) один до одного (1:

1);

г) багато до багатьох (M: M).

З перерахованих видів зв'язку найбільш широко використовується зв'язку виду 1: М. Зв'язок виду 1: 1 можна вважати окремим випадком зв'язку 1: М, коли одного запису головної таблиці відповідає один запис допоміжної таблиці. Зв'язок М: 1 по суті, є "дзеркальним відображенням" зв'язку 1: М. залишився вид зв'язку М: М характеризується як слабкий вид зв'язку або навіть як відсутність зв'язку. Тому надалі розглядається зв'язок виду 1: М.

При утворенні зв'язку виду 1: М один запис головної таблиці (головна, батьківська запис) виявляється пов'язаної з декількома записами додаткової (додаткові, підлеглі запису).

Контроль цілісності зв'язків зазвичай означає аналіз вмісту двох таблиць на дотримання наступних правил:

кожного запису основної таблиці відповідає нуль або більше записів додаткової таблиці;

кожна запис додаткової таблиці має рівно одну батьківську запис основної таблиці.

Контроль цілісності здійснюється при виконанні таких основних операцій над даними двох таблиць:

введення нових записів,

модифікацію записів,

видалення записів.

При введенні даних нових записів виникає питання визначення такої послідовності введення записів у таблиці, щоб не допустити порушення

цілісності.

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

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

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

Структура об'єктно-орієнтованої БД графічно бути подана в вигляді дерева, вузлами якого є об'єкти. Властивості об'єктів описуються деяким стандартним типом (наприклад, строковим - string) або типом, конструюються користувачем (визначається як class).

Приклад логічної структури об'єктно-орієнтованої БД бібліотечної справи наведено на рис.1.

Рис.1. Логічна структура БД бібліотечної справи

Тут об'єкт типу БІБЛІОТЕКА є батьківським для об'єктів-екземплярів класів АБОНЕНТ, КАТАЛОГ та ВИДАЧА. Різні об'єкти типу КНИГА можуть мати одного або різних батьків. Об'єкти типу КНИГА, які мають одного і того ж батька, повинні відрізнятися принаймні інвентарним номером (унікальний для кожного екземпляра книги), але мають однакові значення властивостей isbn, УДК, назва та автор.

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

Розглянемо коротко поняття інкапсуляції, успадкування та поліморфізму стосовно об'єктно-орієнтованої моделі БД.

Інкапсуляція обмежує область видимості імені властивості межами того об'єкта, в якому воно визначене. Так, якщо в об'єкт типу КАТАЛОГ додати властивість, що задає телефон автора книги і має назву телефон, то ми отримаємо однойменні властивості у об'єктів АБОНЕНТ і КАТАЛОГ. Сенс такої властивості буде визначатися тим об'єктом, до якого воно инкапсулирован.

Успадкування, навпаки, поширює область видимості властивості на всіх нащадків об'єкта. Так, всім об'єктам типу КНИГА, що є нащадками об'єкта типу КАТАЛОГ, можна приписати властивості об'єкта - батька: isbn, ІДК, назва та автор. Якщо необхідно розширити дію механізму успадкування на об'єкти, які не є безпосередніми родичами (наприклад, між двома нащадками одного з батьків), то в їх спільний предка визначається абстрактне властивість типу abs. Так, визначення абстрактних властивостей квиток і номер в об'єкті БІБЛІОТЕКА призводить до спадкоємства цих властивостей усіма дочірніми об'єктами АБОНЕНТ, КНИГА і ВИДАЧА. Не випадково тому значення властивості квиток класів АБОНЕНТ і ВИДАЧА, показаних на малюнку, будуть однаковими - 00015.

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

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

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

Рис 2. Фрагмент БД з об'єктом-метою

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

Недоліками об'єктно-орієнтованої моделі є висока поняттєва складність, незручність обробки даних і низька швидкість виконання запитів.

4. Нормалізація відносин

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

Вибір схеми БД визначає виникнення в процесі її експлуатації тих чи інших аномалій оновлення.

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

Аномалії модифікації - виникнення неузгодженості записів у

таблиці при зміні даних в одному записі.

Для відносини "Студент" (ПІБ, Група, Староста), де у стовпці "Група" зберігається повна назва групи, а стовпець "Староста" містить ПІБ старости групи, зміна значення "Староста" (наприклад, для усунення помилки) може призвести до існування більше одного старости однієї і тієї ж групи.

Аномалії видалення - видалення зайвої інформації при видаленні запису.

Для відносини "Студент" (ПІБ, Група, Староста), видалення студента може призвести до видалення з БД і ПІБ старости групи (в тому випадку, якщо для даної групи запис - єдина).

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

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

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

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

Зазначені аномалії пов'язані з надмірністю (дублюванням) даних в БД.

Визначити дублювання даних у БД, а значить і передбачити можливість виникнення аномалій оновлення можна на етапі проектування структури бази даних.

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

Якщо дано два атрибута X і Y деякого відносини, то кажуть, що Y функціонально залежить від X, якщо в будь-який момент часу кожному значенню X відповідає рівно одне значення Y. Функціональна залежність позначається X ◊ Y.

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

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

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

Розглянемо предметну область - розподіл навчального навантаження по

викладачам однієї кафедри. Припустимо, що у кожної групи кожен

предмет веде тільки один викладач. Крім особистих даних викладача необхідно зберігати дані по групі (Найменування, Староста) і для пари (Викладач, Група) необхідно зберігати список предметів, які даний викладач викладає у цій групі.

В якості вихідної таблиці візьмемо:

А

У

З

Особисті дані викладача:

ПІБ, Посада, Оклад

Дані групи: Назва, Староста

Предмети

В якості первинного ключа таблиці візьмемо стовпці "Особисті дані Викладача" і "Дані групи", оскільки існує тільки одна ФЗ: AB ◊ C.

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

Виконаємо перетворення для таблиці прикладу:

1. Стовпець особистих даних перетворимо в чотири стовпці:

"Викладач" (ПІБ), "Табельний №", "Посада", "Оклад". Тепер ключ - "Табельний №" і "Дані групи".

2. Стовпець "Дані групи" перетворимо у два стовпці: "Група" (Найменування), "Староста". Тепер ключ - "Табельний №" і "Група".

3. Стовпець "Предмети" перетворимо в стовпець "Предмет". Як альтернатива, можна створити нову таблицю "Предмети", яка буде містити первинний ключ вихідного відносини ("Табельний №", "Група") і стовпець "Предмет".

У результаті отримано ставлення А В С D E F

Викладач Посада Оклад Група Староста Предмет

Виявлені функціональні залежності:

А ◊ В, С; У ◊ С; D ◊ Е; DF ◊ А.

Первинний ключ: DF, так як від DF залежать інші атрибути.

Друга нормальна форма дозволяє усунути надмірність даних, пов'язаної зі зберіганням інформації різного типу в одному відношенні.

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

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

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

Для атрибутів, функціонально повно залежать від ключа, кожна зміна зачіпає лише один рядок - рядок із змінним значенням. Приведення ставлення до 2НФ дозволяє виключити даний тип аномалій оновлення.

Приклад:

Ставлення

А В С D E F

Викладач Посада Оклад Група Староста Предмет

знаходиться в 1НФ.

При цьому відношення допускає такі аномалії поновлення:

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

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

в) аномалія модифікації - при зміні старости в групі слід оновити всі записи з таким же значенням "Групи".

Перетворимо ставлення з прикладу з 1НФ під 2НФ:

Залежно D ◊ E атрибут E функціонально залежить від частини ключа DF.

Таким чином формуємо:

а) нове відношення без часткової залежності:

ПК: DF, ФЗ: А ◊ B, C; B ◊ C; DF ◊ A.

б) нове відношення для колишньої часткової залежності

DE

Керівництво Групи (Група, Староста)

ПК: D, ФЗ: D ◊ E.

Тепер в обох відносинах відсутні часткові залежності від ключа.

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

Важливим моментом є можливість відновлення вихідної схеми природним з'єднанням отриманих відносин (за атрибуту "Група")

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

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

Приклад:

Ставлення

ABCDF

(Викладач, Посада, Оклад, Група, Предмет)

ПК: DF, ФЗ: DF ◊ А ◊ B ◊ C.

знаходиться в другій нормальній формі.

При цьому вона допускає такі аномалії поновлення:

а) аномалія модифікації - при зміні значення посади викладача, необхідно буде виконати зміна значення посади

для всіх рядків з даними викладачем і зміна значення окладу відповідно з новою посадою;

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

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

Перетворимо дане відношення з прикладу з 2НФ в 3НФ:

ABCDF

(Викладач, Посада, Оклад, Група, Предмет)

ПК: DF, ФЗ: DF ◊ А ◊ У ◊ C.

I. Cпроеціруем відношення на атрибути A, B, C

ABC

(Викладач, Посада, Оклад)

ПК: A, ФЗ: А ◊ B ◊ C.

II. Зауважимо, що отримане ставлення знову містить транзитивною залежність, знову декомпозіруем його на два відношення:

BC

Зарплата (Посада, Оклад)

ПК: B, ФЗ: B ◊ C.

AB

Обов'язок (Викладач, Посада,)

ПК: A, ФЗ: A ◊ B.

б) спроектуємо відношення на атрибути, крім B, C

ADF

План (Викладач, Група, Предмет)

ПК: DF, ФЗ: DF ◊ A.

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

5. Мови запитів SQL і QBE

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

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

Для підготовки запитів за допомогою різних СУБД найчастіше використовуються два основні мови опису запитів:

QBE (Query By Example) - мова запитів за зразком;

SQL (Structured Query Language) - структурований мова запитів.

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

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

Стандарт SQL визначається ANSI (American National Standard Institute - Американським Національним Інститутом Стандартів.

Є два SQL: Інтерактивний (Interactive) і Вбудований (Embedded). Здебільшого, обидві форми працюють однаково, але використовуються різному.

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

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

І в інтерактивній, і у вбудованій формах SQL, є численні частини, або підрозділи. Вони є складовими частинами SQ L в ANSI. Це не різні мови, а розділи команд SQL, згрупованих за їх функцій

DDL (Data Definition Language - Мова Визначення Даних) - так званий Мова Опис Схеми в ANSI, складається з команд, які створюють об'єкти (таблиці, індекси, перегляди, і так далі) в базі даних.

DML (Data Manipulation Language - Мова Маніпулювання Даними) - це набір команд, які визначають, які значення представлені в таблицях в будь-який момент часу.

DC L (Data Control Language - Мова Управління Даними) складається з коштів, які визначають, чи дозволити користувачу виконувати певні дії чи ні.

Теоретичною основою мови QBE є реляційне числення з

змінними-доменами (проте в мові присутні і елементи обчислення кортежів).

Мова QBE дозволяє ставити складні запити до БД шляхом заповнення пропонованої СУБД запитної форми (іноді також використовують термін QBЕ - запит за формою).

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

У кожній із сучасних реляційних СУБД є свій варіант мови QBE.

Мовою QBE можна задавати однотаблічние та багато табличні (вибирають або обробні дані з декількох пов'язаних таблиць) запити.

За допомогою запитів на мові QBE можна виконувати такі основні операції:

вибірку даних;

обчислення над даними;

вставку нових записів;

видалення записів;

модифікацію (зміна) даних.

Результатом виконання запиту є нова таблиця, звана відповідь (перші дві операції), або оновлена ​​вихідна таблиця (інші операції). У реальних додатках баз даних QBE використовується в основному для вибірки даних.

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

Запитна форма звичайно має вигляд таблиці, ім'я та назви полів якої збігаються з ім'ям і назвами полів відповідної вихідної

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

У сучасних СУБД, наприклад, в Access і Visual FoxPro, багато дій з підготовки запитів за допомогою мови QBE виконуються візуально за допомогою миші. Зокрема, візуальне зв'язування таблиць при підготовці запиту виконується не елементами прикладів, а просто "протягуванням" мишею поля однієї таблиці до поля інший.

За можливостями маніпулювання даними при описі запитів зазначені мови практично еквівалентні. Більш того, на практиці запит, складений на QBE, зазвичай транслюється в SQL - запит і лише потім виконується.

Головна відмінність між даними мовами полягає у способі формування запитів: мова QBE передбачає ручне або візуальне формування запиту, в той час як використання SQL означає програмування запиту.

Додати в блог або на сайт

Цей текст може містити помилки.

Програмування, комп'ютери, інформатика і кібернетика | Реферат
67кб. | скачати


Схожі роботи:
Розвиток теорії і практики менеджменту
Просопографіческіе бази даних Росії на прикладі баз даних Comandarm і Duma1
Створення бази даних критичних властивостей речовин в редакторі баз даних MS Access
Становлення радіотехнічної теорії від теорії до практики На прикладі технічних наслідків з відкриття
Організація баз даних
Організація баз даних
Паралельні машини баз даних
Особливості проектування баз даних
Проектування баз даних MS Access
© Усі права захищені
написати до нас