Бази даних і СУБД

Размещено на http://www.allbest.ru/

Київський національний університет імені Тараса Шевченка

Факультет кібернетики

РЕФЕРАТ

Основи систем баз даних

на тему: “Бази даних і СУБД”

Виконала:

Студентка 5-го курсу

Групи ДО

Яковлєва Оксана

Київ-2004

План

1. Концепція баз даних

2. Архітектура СУБД.

3. Інформаційна модель даних “Сутність-зв'язок”

4. Реляційна структура даних

5. Про нормалізацію, функціональні і багатозначні залежності

6. Мова структурованих запитів SQL

7. Запит мовою SQL

Список літератури

1. Концепція баз даних

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

· підтримка логічно погодженого набору файлів

· забезпечення мови маніпулювання даними

· відновлення інформації після різного роду збоїв

· реально рівнобіжна робота декількох користувачів.

Рис. 1. Зв'язок програм і даних при використанні СУБД

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

2. Архітектура СУБД

база інформаційний модель запит

СУБД повинна надавати доступ до даних будь-яких користувачів, включаючи і тих, котрі практично не мають і (або) не хочуть мати представлення про:

· фізичне розміщення в пам'яті даних і їхніх описів;

· механізми пошуку запитуваних даних;

· проблеми, що виникають при одночасному запиті тих самих даних багатьма користувачами (прикладними програмами);

· способи забезпечення захисту даних від некоректних відновлень і (або) несанкціонованого доступу;

· підтримку баз даних в актуальному стані і безлічі інших функцій СУБД.

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

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

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

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

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

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

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

3. Інформаційна модель даних "Сутність-зв'язок"

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

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

Атрибут - пойменована характеристика сутності. Його найменування повинне бути унікальним для конкретного типу сутності, але може бути однаковим для різного типу сутностей (наприклад, КОЛІР може бути визначений для багатьох сутностей: СОБАКА, АВТОМОБІЛЬ, ДИМ і т.д.). Атрибути використовуються для визначення того, яка інформація повинна бути зібрана про сутність.

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

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

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

4. Реляційна структура даних

Наприкінці 60-х років з'явилися роботи, у яких обговорювалися можливості застосування різних табличних даталогічних моделей даних, тобто можливості використання звичних і природних способів представлення даних. Найбільш значною з них була стаття співробітника фірми ІBM д-ра Е.Кодда (Codd E.F., A Relatіonal Model of Data for Large Shared Data Banks. CACM 13:6 , June 1970), де, імовірно, уперше був застосований термін "реляційна модель даних".

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

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

Доменом називається безліч атомарних значень того самого типу. Зміст доменов полягає в наступному. Якщо значення двох атрибутів беруться з того самого домена, то, імовірно, мають сенс порівняння, що використовують ці два атрибути (наприклад, для організації транзитного рейса можна дати запит "Видати рейси, у яких час вильоту з Москви в Сочі більше часу прибуття з Архангельська в Москву"). Якщо ж значення двох атрибутів беруться з різних доменов, то їхнє порівняння, імовірно, позбавлено змісту: чи варто порівнювати номер рейса з вартістю квитка? Заголовок складається з такого фіксованої множини атрибутів A1, A2, ..., An, що існує взаємно однозначна відповідність між цими атрибутами Aі і визначальними їх доменами Dі (і=1,2,...,n).

Тіло складається з мінливої в часі множини кортежів, де кожен кортеж складається у свою чергу з множини пар атрибут-значення (Aі:Vі), (і=1,2,...,n), по одній такій парі для кожного атрибута Aі в заголовку. Для будь-якої заданої пари атрибут-значення (Aі:Vі) Vі є значенням з єдиного домена Dі, що зв'язаний з атрибутом Aі. Ступінь відношення - це число його атрибутів. Відношення ступеня один називають унарным, ступеня два - бінарним, ступеня три - тернарним, ..., а ступеня n - n-арним.

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

Оскільки відношення - це множина, а множини за визначенням не містять співпадаючих елементів, то ніякі два кортежі відношення не можуть бути дублікатами один одного в будь-який випадново-заданий момент часу. Нехай R - відношення з атрибутами A1, A2, ..., An. Кажуть, що множина атрибутів K=(Aі, Aj, ..., Ak) відношення R є можливим ключем R тоді і тільки тоді, коли задовольняються двы незалежних від часу умови:

Унікальність: у довільний заданий момент часу ніякі два різних кортежі R не мають того самого значення для Aі, Aj, ..., Ak.

Мінімальність: жоден з атрибутів Aі, Aj, ..., Ak не може бути виключений з K без порушення унікальності.

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

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

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

5. Про нормалізацію, функціональні і багатозначні залежності

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

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

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

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

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

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

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

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

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

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

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

6. Мова структурованих запитів SQL. Призначення і принцип роботи SQL

SQL (часто вимовляється як "сиквэл", скорочена назва від Structured Query Language) символізує собою Структурована Мова Запитів. SQL є інструментом, призначеним для обробки і читання даних, що містяться в комп'ютерній базі даних. Це мова яка дає можливість ефективно створювати реляційні бази даних і працювати з ними.

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

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

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

Рис. 3. Застосування SQL для доступу до бази даних

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

От основні моменти, що характеризують зручність застосування SQL:

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

· Читання даних. SQL дає користувачу чи додатку можливість читати з бази даних дані, що містяться в ній, і користатися ними.

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

· Керування доступом. За допомогою SQL можна обмежити можливості користувача по читанню і зміні даних і захистити їх від несанкціонованого доступу.

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

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

Таким чином, SQL є досить могутньою мовою для взаємодії із СУБД.

7. Запит мовою SQL

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

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

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

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

Мова допускає три типи синтаксичних конструкцій, що починаються з ключового слова SELECT: специфікація курсору (cursor specіfіcatіon), оператор вибірки (select statement) і підзапит (subquery). Основою усіх їх є синтаксична конструкція "табличне вираження (table expressіon)". Семантика табличного вираження полягає в тому, що на основі послідовного застосування розділів from, where, group by і havіng із заданих у розділі from таблиць будується деяка нова результуюча таблиця, порядок проходження рядків якої не визначений і серед рядків якої можуть знаходитися дублікати (тобто в загальному випадку таблиця-результат табличного вираження є мультимножиною рядків). Насправді саме структура табличного вираження найбільшим чином характеризує структуру запитів мови SQL/89.

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

· COUNT робить номера рядків чи не-NULL значення полів які вибрав запит.

· SUM робить арифметичну суму всіх обраних значень даного поля.

· AVG робить усереднення всіх обраних значень даного поля.

· MAX робить найбільше з всіх обраних значень даного поля.

· MІN робить найменше з всіх обраних значень даного поля.

Список літератури

1. Дж.Ульман, "Основи систем баз даних", М.:Фінанси і статистика,1983р.

2. Дейт К., "Введення в системи баз даних", М.: Hаука, 1980 р.

3. А.H.Hаумов, А.М.Вендров і ін., "Системи керування базами даних і знань", М.:Фінанси і статистика, 1991р.

4. С.М.Диго "Проектирование и использования баз данных". Москва: Финансы и статистика 1995.

Размещено на Allbest.ru