Підтримка мов бази даних

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

У перших базах даних існувало 2 мови:

1. Мова определ ення схеми бази SDL.

2. мову маніпулювання даних DML.

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

На сьогоднішній день найбільш поширеним мовою є

Structured

Language

Ця мова і підтримує, і створює схему бази даних і дозволяє цими даними маніпулювати. Він містить нд е необхідні кошти для забезпечення цілісності бази даних. Ці обмеження цілісності містяться в спеціальних каталогах, що дозволяє на мовному рівні контролювати цілісне стан бази даних. спеціальні оператори мови SQL визначають так звані уявлення бази даних. Подання - ϶ᴛᴏ запити, які зберігаються в базі. Для користувача подання - ϶ᴛᴏ таблиця за допомогою, якої можна обмежити або розширити видимість бази даних для конкретного користувача даних. Мова SQL містить так спеціальні операнди, які забезпечують авторизацію доступу до об'єктів бази даних. Оскільки різні користувачі мають різні повноваження для роботи з даними, то ці повноваження описуються в спеціальних таблицях - каталогах, які підтримуються на мовному рівні.

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

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

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

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

Схема відносини - ϶ᴛᴏ пойменоване безліч пар елементів. А в

кортежі \u003d ім'я атрібута͵ значення, тобто кортеж це набір іменованих значень за даного типу.

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

Лекція 4

· Основні поняття реляційних баз даних

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

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

Мал. 2.1.

· Тип даних

Значення даних, що зберігаються в реляційній базі даних, Є типізований, т. Е. Відомий тип кожного значення, що зберігається. поняття типу даних в реляційної моделі даних повністю відповідає поняттю типу даних в мовах програмування. Нагадаємо, що традиційне (Нечитка) визначення типу даних складається з трьох основних компонентів: визначення безлічі значень даного типу; визначення набору операцій, які можна застосувати до значень типу; визначення способу зовнішнього представлення значень типу (литералов).

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

У прикладі на рис. 1 ми маємо справу з даними трьох типів: Рядки символів, цілі числа і «гроші».

· домен

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

Найбільш правильною інтуїтивною трактуванням поняття домену є його сприйняття як допустимого потенційного, обмеженого підмножини значень даного типу. наприклад, домен ІМЕНА в нашому прикладі визначено на базовому типі символьних рядків, але в число його значень можуть входити тільки ті рядки, які можуть представляти імена (зокрема, для можливості подання російських імен такі рядки не можуть починатися з м'якого або твердого знака і не можуть бути довшими, наприклад, 20 символів). якщо деякий атрибут відносини визначається на деякому домені (Як, наприклад, на рис. 1 атрибут СЛУ_ІМЯ визначається на домені ІМЕНА ), То в подальшому обмеження домену грає роль примуси, Який накладається на значення цього атрибута.

Слід зазначити також семантичне навантаження поняття домену: Дані вважаються порівнянними тільки в тому випадку, коли вони відносяться до одного домену. У нашому прикладі значення доменів НОМЕРИ ПРОПУСКІВ і НОМЕРА ВІДДІЛІВ відносяться до типу цілих чисел, але не є порівнянними (допускати їх порівняння було б безглуздо).

· елементи відносини

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

Отже, заголовком (або схемою) відносини r (Hr ) Називається кінцеве безліч впорядкованих пар виду , Де A називається іменем атрибута, аT позначає ім'я деякого базового типу або раніше визначеного домену. За визначенням потрібно, щоб всі імена атрибутів в заголовку відносини були різні. У прикладі на рис. 2.1 заголовком відносини СЛУЖБОВЦІ є безліч пар{<слу_номер, номера_пропусков>, <слу_имя, имена>, <слу_зарп, размеры_выплат>, <слу_отд_номер, номера_отделов>} .

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

кортежем tr , відповідним заголовку Hr , Називається безліч впорядкованих триплетів виду , По одному такому триплети для кожного атрибута вHr . Третій елемент -v - триплетів повинен бути допустимим значенням типу даних або домену T . заголовку відносини СЛУЖБОВЦІ відповідають, наприклад, такі кортежі: {<слу_номер, номера_пропусков, 2934>, <слу_имя, имена, Иванов>, <слу_зарп, размеры_выплат, 22.000>, <слу_отд_номер, номера_отделов, 310>} , {<слу_номер, номера_пропусков, 2940>, <слу_имя, имена, Кузнецов>, <слу_зарп, размеры_выплат, 35.000>, <слу_отд_номер, номера_отделов, 320>} .

тілом Br відносини r називається довільне безліч кортежів tr . Одне з можливих тел відносини СЛУЖБОВЦІ показано на рис. 2.1. Зауважимо, що в загальному випадку, як це демонструють, зокрема, рис. 2.1 і приклад попереднього абзацу, можуть існувати такі кортежі tr , Які відповідаютьHr, але не входять в Br.

Значним Vr відносини r називається пара множинHr і Br . Одне з допустимих значень відносини СЛУЖБОВЦІ показано на рис. 2.1.

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

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

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

За визначенням, ступенем, або «арность» , заголовка відносини, кортежу, Що відповідає цьому заголовку, тіла відносини, значення відносини і змінної відносини є потужність заголовка відносини. наприклад, ступінь відносини СЛУЖБОВЦІ дорівнює чотирьом, т. е. воно є 4-арним ( кватернарні).

За наведених визначеннях розумно вважати схемою реляційної бази даних набір пар<имя_VARr, Hr> , Що включає імена і заголовки всіх змінних відносини, Які визначені в базі даних. Реляційна база даних - це набір пар (Звичайно, кожна змінна відносини в будь-який момент часу містить деякий значення- відношення, Зокрема, пусте).

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

· Первинний ключ

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

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

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

· Фундаментальні властивості відносин

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

Відсутність кортежів-дублікатів,
первинний і можливі ключі відносин

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

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

Звичайно, можуть існувати значення відносини з декількома незбіжними мінімальними наборами атрибутів, Що володіють властивостями унікальності. Наприклад, якщо повернутися до припущень лекції 1 про унікальність значень атрибутів СЛУ_НОМЕР і СЛУ_ІМЯ відносини СЛУЖБОВЦІ , То для кожного значення цього відносини ми маємо дві множини атрибутів, Які претендують на звання первинного ключа – (СЛУ_НОМЕР) і (СЛУ_ІМЯ) . В цьому випадку проектувальник бази даних повинен вирішити, яке з альтернативних множин атрибутів назвати первинним ключем, А решта мінімальні набори атрибутів, Що володіють властивістю унікальності, називаються можливими ключами 1).

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

Тепер пояснимо, чому проектувальнику слід явно оголошувати первинний і можливі ключі змінних відносин 2). Справа в тому, що в результаті цього оголошення СУБД отримує інформацію, яка в подальшому буде використовуватися як обмеження цілісності 3). СУБД ніколи не допустить появи в змінної відносини значення- відносини, Що містить два кортежу з однаковим значенням атрибута СЛУ_НОМЕР (визначення первинного ключа для даної змінної відносини скасувати не можна). поява двох кортежів з однаковим значенням атрибута СЛУ_ІМЯ буде також неможливо до тих пір, поки залишається в силі ухвалу(СЛУ_ІМЯ) як можливого ключа. Тим самим оголошення первинного і можливих ключів дають СУБД можливість підтримувати цілісність бази даних навіть в разі спроб занесення в неї некоректних даних.

Нарешті, повернемося до властивості мінімальності первинного і можливих ключів. Як зазначалося вище, це властивість є критично важливим, і важливість проявляється саме при трактуванні первинного і можливих ключів як обмежень цілісності. У нашому прикладі з ставленням СЛУЖБОВЦІ властивістю унікальності буде володіти не тільки безліч атрибутів (СЛУ_НОМЕР) , А й, наприклад, безліч(СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР). Але якби ми виставили в якості примуси вимога унікальності(СЛУ_НОМЕР, СЛУ_ОТД_НОМЕР), То СУБД гарантувала б відсутність кортежів з однаковим значенням атрибута СЛУ_НОМЕР не в усьому значенні відносини СЛУЖБОВЦІ , А тільки в групах кортежів з одним і тим же значенням атрибута СЛУ_ОТД_НОМЕР . Зрозуміло, що це не відповідає змісту моделюється предметної області.

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

Відсутність впорядкованості кортежів

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

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

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

Відсутність впорядкованості атрибутів

атрибути відносин не впорядковані, оскільки за визначенням заголовок відносини є безліч пар<имя атрибута, имя домена> . Для посилання на значення атрибута в кортежі відносини завжди використовується ім'я атрибута. Легко помітити явну аналогію між заголовками відносин і структурними типами в мовах програмування. Навіть в мові програмування C з його практично необмеженими можливостями роботи з покажчиками наполегливо рекомендується звертатися до полів структур тільки за їхніми іменами. Якщо, наприклад, на мові C визначено структурну змінна

struct (int a; char b; int c) d;

то в стандарті мови рішуче не рекомендується використовувати для доступу до символьного полюb конструкцію * (& d + sizeof (int)) (Взяти адресу структурної змінноїd , Додати до нього число байтів в цілому числі і взяти значення байта за отриманим адресою). Це пояснюється тим, що при реальному розташуванні в пам'яті полів такої структурної змінної в тому порядку, як вони визначені, в багатьох комп'ютерах потрібно вирівняти полеc по байту з парних адресою. Тому один байт просто пропаде. При розташуванні структурної змінної в пам'яті економний компілятор (вірніше, оптимізатор) переставити місцями поляb і c , І зазначена вище конструкція не забезпечить доступу до поляb . Для коректного звернення до полюb змінної d потрібно використовувати конструкціїd.b або & d-\u003e b , Т. Е. Явно вказувати ім'я поля.

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

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

Атомарність значень атрибутів
Перша нормальна форма відносини

значення всіх атрибутів є атомарними (вірніше, скалярними). Це випливає з визначення домену як потенційного безлічі значень скалярного типу даних, Т. Е. Серед значень домену не можуть міститися значення з видимою структурою, в тому числі безлічі значень ( відносини). Зауважимо, що це не суперечить тому, що говорилося в розділі «Основні поняття реляційних баз даних» про потенційну можливість використання при специфікації атрибутів типів даних, Що визначаються користувачами. Наприклад, можна було б додати в схему відносини СЛУЖБОВЦІ атрибут СЛУ_ФОТО , Певний на домені (або типі даних) ФОТОГРАФІЇ . Головне в атомарности значень атрибутів полягає в тому, що реляційна СУБД не повинна забезпечувати користувачам явною видимості внутрішньої структури значення. З усіма значеннями можна звертатися тільки за допомогою операцій, визначених у відповідному типі даних.

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

приклад ненормалізованих відносини показаний на рис. 2.2. Можна сказати, що тут ми маємо бінарне відношення, В якому значеннями атрибута ВІДДІЛИ є відносини. Зауважимо, що вихідне відношення СЛУЖБОВЦІ є нормалізованим варіантом відносини ВІДДІЛИ-СЛУЖБОВЦІ . Нормалізований варіант показаний на рис. 2.3.

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

n зарахувати службовця Кузнєцова (пропуск номер 3000, зарплата 25000.00) до відділу номер 320;

n зарахувати службовця Кузнєцова (пропуск номер 3000, зарплата 25000.00) до відділу номер 310.

Мал. 2.

Мал. 3. Ставлення СЛУЖБОВЦІ: нормалізований варіант
відносини ВІДДІЛИ-СЛУЖБОВЦІ

Якщо інформація про службовців представлена \u200b\u200bу вигляді відносини СЛУЖБОВЦІ , Обидва оператори будуть виконуватися однаково (вставити кортеж в відношення СЛУЖБОВЦІ ). Якщо ж працювати з ненормалізованих ставленням ВІДДІЛИ-СЛУЖБОВЦІ , То перший оператор призведе до простою вставці кортежу, А другий - до додаванню кортежу в значення- відношення атрибута ВІДДІЛ кортежу з первинним ключем 310 .

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

· Реляційна модель даних

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

Іншими словами, ми використовували поняття так званої реляційної моделі даних. Модель даних (в контексті області баз даних) Описує якийсь набір родових понять і ознак, якими повинні володіти всі конкретні СУБД і керовані ними бази даних, Якщо вони ґрунтуються на цій моделі. Наявність моделі даних дозволяє порівнювати конкретні реалізації, використовуючи один спільну мову.

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

Загальна характеристика

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

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

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

Цілісність суті і посилань

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

Насправді, вимога цілісності сутності повністю звучить наступним чином: у будь-який змінної відносини повинен існувати первинний ключ, І ніяке значення первинного ключа в кортежі значення- відносини змінної відносини не повинно містити невизначених значень. Щоб це формулювання було повністю зрозуміла, ми повинні хоча б коротко обговорити поняття невизначеного значення (NULL).

Звичайно, теоретично будь-який кортеж, Що заноситься в сохраняемое відношення, Повинен містити всі характеристики модельованої їм сутності реального світу, які ми хочемо зберегти в базі даних. Однак на практиці не всі ці характеристики можуть бути відомі до того моменту, коли потрібно зафіксувати сутність в базі даних. простим прикладом може бути процедура прийняття на роботу людину, розмір заробітної плати якого ще не визначено. В цьому випадку службовець відділу кадрів, який заносить в відношення СЛУЖБОВЦІ кортеж, Що описує нового службовця, просто не може забезпечити значення атрибута СЛУ_ЗАРП (Будь-яке значення домену РАЗМЕРИ_ВИПЛАТ буде невірно характеризувати зарплату нового службовця).

Едгар Кодд запропонував використовувати в таких випадках невизначені значення. невизначене значення не належить ніякому типу даних і може бути присутнім серед значень будь-якого атрибута, Визначеного на будь-якому типі даних (Якщо це явно не заборонено при визначенні атрибута). якщоa - це значення деякого типу даних абоNULL, op - будь-яка двомісна «арифметична» операція цього типу даних (Наприклад,+), А lop - операція порівняння значень цього типу (Наприклад,= ), То за визначенням:

a op NULL \u003d NULL

NULL op a \u003d NULL

a lop NULL \u003d unknown

NULL lop a \u003d unknown

тут unknown - це третє значення логічного, або булевского, типу, що володіє наступними властивостями:

NOT unknown \u003d unknown

true AND unknown \u003d unknown

true OR unknown \u003d true

false AND unknown \u003d false

false OR unknown \u003d unknown

(Нагадаємо, що операції AND і OR є комутативними) 2). У даній лекції нам досить наведеного короткого вступу в невизначені значення, Але в наступних лекціях ми будемо неодноразово повертатися до цієї теми.

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

Друга вимога, яке називається вимогою цілісності по посиланнях (referential integrity), Є більш складним. Очевидно, що при дотриманні нормалізованності відносин складні сутності реального світу представляються в реляційної БД у вигляді декількох кортежів декількох відносин. Наприклад, уявімо, що у Вас можуть запитати в реляційній базі даних сутністьВІДДІЛ з атрибутами ОТД_НОМЕР (номер відділу), ОТД_РАЗМ (Кількість службовців) іОТД_СЛУ (Безліч службовців відділу). Для кожного службовця потрібно зберігатиСЛУ_НОМЕР (Номер службовця),СЛУ_ІМЯ (Ім'я службовця) іСЛУ_ЗАРП (заробітня плата службовця). Як ми побачимо в лекції 7, при правильному проектуванні відповідної БД в ній з'являться два відносини: ВІДДІЛИ (ОТД_НОМЕР, ОТД_РАЗМ) (первинний ключ – (ОТД_НОМЕР)) і СПІВРОБІТНИКИ (СЛУ_НОМЕР, СЛУ_ІМЯ, СЛУ_ЗАРП, СЛУ_ОТД_НОМ) (первинний ключ – (СЛУ_НОМЕР)).

Як видно, атрибут СЛУ_ОТД_НОМ вводиться в відношення СЛУЖБОВЦІ не тому, що номер відділу є власним властивістю службовця, а лише для того, щоб мати можливість при необхідності відновити повну сутністьВІДДІЛ . значення атрибута СЛУ_ОТД_НОМ в будь-якому кортежі відносини СЛУЖБОВЦІ має відповідати значенням атрибута ОТД_НОМ в деякому кортежі відносини ВІДДІЛИ . Атрибут такого роду (можливо, складовою) називається зовнішнім ключем (foreign key) , Оскільки його значення однозначно характеризують сутності, представлені кортежами деякого іншого відносини (Т. Е. Описують їх первинного ключа). Звісно, зовнішній ключ може бути складовим, т. е. складатися з декількох атрибутів. Кажуть що відношення, В якому визначено зовнішній ключ, Посилається на відповідне відношення, В якому такий же атрибут є первинним ключем.

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

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

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

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

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

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

· висновок

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

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

Вступ

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

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

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

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

Базові поняття реляційної моделі даних

Основними поняттями властивими для реляційних даних вважаються тип даних, домен, атрибут, кортеж, первинний ключ відношення. Спочатку відзначимо сенс цих поняття на прикладі ставлення «СПІВРОБІТНИКИ», що містить інформацію щодо співробітників деякої організації

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

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

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

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

У нашому випадку значення доменів "Номери перепусток" і "Номери груп", які мають відношення до типу цілих числі, не може бути порівнянним. Відзначимо, що в деяких випадках в реляційних СУБД саме поняття «домену» не знаходить застосування, тому що вже підтримується в Oracle V.7.

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

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

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

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

Кортеж - це набір іменних значень заданого типу.

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

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

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

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

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

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

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

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

Вимоги, що пред'являються до первинному ключу:

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

первинний ключ не повинен містити порожніх значень.

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

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

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

Зв'язки між таблицями. Записи в таблиці можуть залежати від однієї або декількох записів іншої таблиці. Такі відносини між таблицями називаються зв'язками.Зв'язок визначається наступним чином: поле або кілька полів однієї таблиці, зване зовнішнім ключем,посилається на первинний ключ іншої таблиці. Розглянемо приклад. Так як кожне замовлення повинен виходити від певного клієнта, кожен запис таблиці Orders(Замовлення) повинна посилатися на відповідний запис таблиці Customers(Клієнти). Це і є зв'язок між таблицями Ordersі Customers. В таблиці Ordersмає бути поле, де зберігаються посилання на ті чи інші записи таблиці Customers.

типи зв'язків. Існує три типи зв'язків між таблицями.

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

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

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

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

Реляційна База Даних (РБД) - це набір відносин, імена яких збігаються з іменами схемотношеній в схемі БД.

Основні поняттяреляційних баз даних:

· Тип даних - тип значень конкретного стовпця.

· домен (Domain) - безліч всіх допустимих значень атрибута.

· Атрибут (Attribute) - заголовок стовпця таблиці, що характеризує пойменоване властивість об'єкта, наприклад, прізвище студента, дата оформлення замовлення, підлогу співробітника і т.п.

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

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

· Первинний ключ (Primary key) - поле (або набір полів) таблиці, однозначно ідентифікує кожну з її записів.

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

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

· Реляційна модель даних (РМД)- організація даних у вигляді двовимірних таблиць.

Кожна реляційна таблиця повинна мати наступні властивості:

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

2. Кожне значення, записується на перетині рядка і стовпця - є атомарним (нероздільним).

3. Значення кожного поля повинні бути одного типу.

4. Кожне поле має унікальне ім'я.

5. Порядок розташування записів є несуттєвим.

Основні елементи БД:

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

· Ім'я, наприклад, Прізвище, Ім'я, По батькові, Дата народження;

· Тип, наприклад, строковий, символьний, числовий, Датов;

· Довжина, наприклад, в байтах;

· Точність для числових даних, наприклад, два десяткових знака для відображення дробової частини числа.

запис - сукупність значень логічно пов'язаних полів.

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

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

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

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

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

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

Загальна характеристика роботи з РБД:

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

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

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

28. Алгоритмічні МОВИ. Транслятор (інтерпретатор і компілятор). Алгоритмічні мови БЕЙСІК. СТРУКТУРА ПРОГРАМИ. Ідентифікатор. ЗМІННІ. ОПЕРАТОРИ. ОБРОБКА одномірні і двомірні МАСИВІВ. ФУНКЦІЇ КОРИСТУВАЧА. Підпрограми. РОБОТА З ФАЙЛАМИ ДАНИХ.

Мова високого рівня - мова програмування, поняття і структура якого зручні для сприйняття людиною.

алгоритмічний мову (Algorithmic language) - мова програмування - штучний (формальний) мова, призначена для запису алгоритмів. Мова програмування задається своїм описом і реалізується у вигляді спеціальної програми: Компілятора або інтерпретатора. Прикладами алгоритмічних мов служать - Borland Pascal, C ++, Basic і т.д.

Основні поняття алгоритмічного мови:

склад мови:

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

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

вирази - це послідовність елементарних конструкцій і символів,

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

Опис мови:

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

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

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

символи мови - це основні неподільні знаки, в термінах яких пишуться всі тексти мовою.

елементарні конструкції - це мінімальні одиниці мови, що мають самостійний сенс. Вони утворюються з основних символів мови.

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

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

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

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

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

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

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

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

2. Інтерпретація: Інтерпретатор (Англ. Interpreter - тлумач, усний перекладач) переводить і виконує програму рядок за рядком.

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

Відкомпілювалися програми працюють швидше, але інтерпретуються простіше виправляти і змінювати

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

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

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