Для вмісту окремого стовпця таблиці в реляційній базі даних існує обмеження: значення стовпця у всіх рядках таблиці мають бути одного і того ж типа|типу|. Наприклад, всі назви міст в стовпці CityName| таблиці Sities| є символьними рядками змінної довжини.
У стандарті SQL2| формальне визначення домена реалізовано як частина|частка| визначення бази даних. Згідно|згідно з| цьому стандарту, домен є іменованою сукупністю значень даних і широко використовується у визначенні бази даних як додатковий тип даних. Домен створюється за допомогою оператора CREATE| DOMAIN| на основі базових типів даних. Після|потім| створення|створіння| домена на нього можна посилатися усередині|всередині| визначення таблиці як на типа|тип| даних.
2.4.5 Індекси (оператори CREATE/DROP INDEX|)
Одним із структурних елементів фізичної пам'яті, присутніх в більшості реляційних СУБД, є|з'являється| індекс – засіб|кошт| забезпечує швидкий доступ до рядків таблиці на основі значення одного або декількох стовпців.
Для створення|створіння| і видалення|віддалення| індексів застосовуються оператори CREATE| INDEX| і DROP| INDEX|, синтаксис яких описаний нижчим.
Слід також відмітити|помітити|, що СУБД автоматично створює індекси для первинних ключів|джерел|.
Коли СУБД зустрічає в операторові SQL| заслання|посилання| на виставу|подання|, вона відшукує його визначення, збережене в базі даних. Потім СУБД перетворить призначений для користувача запит, що посилається на виставу|подання|, в еквівалентний запит до вихідних|початкових| таблиць вистави|подання|, і виконує цей запит. Таким чином, СУБД створює ілюзію існування вистави|подання| у вигляді окремої таблиці і в той же час зберігає цілісність вихідних|початкових| таблиць.
2.5.1 Переваги вистав|подань|
Вживання|застосування| вистав|подань| в базах даних різних типів може виявитися корисним в найрізноманітніших ситуаціях. У базах даних на персональних комп'ютерах вистави|подання| застосовуються для зручності і дозволяють спрощувати запити до бази даних. У промислових базах даних вистави|подання| грають головну|чільну| роль в створенні|створінні| власної структури бази даних для кожного користувача і забезпеченні її безпеки. Основні переваги вистав|подань| перераховані нижче.
1. Безпека. Кожному користувачеві можна вирішити доступ до невеликого числа вистав|подань|, що містять|утримують| лише|тільки| ту інформацію, яку йому дозволено знати. Таким чином, можна здійснити обмеження доступу користувачів до інформації, що зберігається.
2. Простота запитів. За допомогою вистави|подання| можна прочитати дані з|із| декількох таблиць і представити|уявляти| їх як одну таблицю, перетворюючи тим самим запит до багатьом таблицям в однотабличный| запит до вистави|подання|.
3. Простота структури. За допомогою вистав|подань| для кожного користувача можна створити власну "структуру" бази даних, визначивши її як безліч доступних користувачеві віртуальних таблиць.
4. Захист від змін. Вистава|подання| може повертати несуперечливий і незмінний образ|зображення| структури бази даних, навіть якщо вихідні|початкові| таблиці розділяються, реструктуируются| або перейменовуються.
5. Цілісність даних. Якщо доступ до даних або введення даних здійснюється за допомогою вистави|подання|, СУБД може автоматично перевіряти, чи виконуються певні умови цілісності.
2.5.2 Недоліки|нестачі| вистав|подань|
Поряд з|поряд із| перерахованими вище перевагами, вистави|подання| володіють і двома істотними|суттєвими| недоліками|нестачами|;
1. Продуктивність. Вистава|подання| створює лише видимість існування відповідної таблиці, і СУБД доводиться перетворювати запит до вистави|подання| в запит до вихідних|початкових| таблиць. Якщо виставу|подання| відображує|відображає| багатотабличний запит, то простий запит до вистави|подання| стає складним об'єднанням і на його виконання може потрібно багато часу.
2. Обмеження на оновлення. Коли користувач намагається|пробує| відновити рядки вистави|подання|, СУБД повинна встановити їх відповідність рядкам вихідних|початкових| таблиць, а також відновити останні. Це можливо лише|тільки| для простих вистав|подань|; складні вистави|подання| оновлювати|обновляти| не можна, вони доступні лише|тільки| для читання.
Вказані недоліки|нестачі| означають, що не стоїть без розбору застосовувати вистави|подання| замість вихідних|початкових| таблиць. У кожному конкретному випадку необхідно враховувати перераховані переваги і недоліки|нестачі| вистав|подань|.
2.6 Вистави|подання| в SQL|.
Оператор CREATE| VIEW|, синтаксис якого змальований|зображати| нижче, використовується для створення|створіння| вистав|подань|. У нім вказуються|указують| ім'я вистави|подання| і запит, лежачий в його основі. Для успішного створення|створіння| вистави|подання| необхідно мати дозвіл на доступ до всіх таблиць, що входять в запит.
При необхідності в операторові CREATE| VIEW| можна задати ім'я для кожного стовпця створюваної вистави|подання|. Якщо вказується|указує| список імен стовпців, то він повинен містити|утримувати| стільки елементів, скільки стовпців міститься|утримується| в запиті. Звернете увагу на те, що задаються лише|тільки| імена. Наприклад, створити виставу|подання|, що містить|утримує| прізвища студентів групи A-98-51|.
2.6.1 Оновлення вистав|подань| і стандарт ANSI/ISO
У стандарті SQL1| точно вказано, для яких вистав|подань| в базі даних повинна існувати можливість|спроможність| оновлення. Згідно|згідно з| стандарту, виставу|подання| можна оновлювати|обновляти| в тому випадку, якщо|у тому випадку , якщо| визначальний його запит відповідає наступним|слідуючим| вимогам:
1. Має бути відсутнім предикат DISTINCT|, тобто рядки, що повторюються, не повинні виключатися з|із| таблиці результатів запиту.
2. У пропозиції|реченні| FROM| має бути задана лише|тільки| одна таблиця, яку можна оновлювати|обновляти|; тобто у|біля| вистави|подання| має бути одна вихідна|початкова| таблиця, а користувач повинен мати відповідні права доступу до неї. Якщо вихідна|початкова| таблиця сама є виставою|поданням|, то воно також повинне задовольняти цим умовам.
3. Кожне ім'я в списку повертаних стовпців має бути засланням|посиланням| на простий стовпець; у цьому списку не повинні міститися|утримуватися| вирази, обчислювані|вичисляти| стовпці або агрегатні функції.
4. Пропозиція|речення| WHERE| не повинна містити|утримувати| вкладений запит; у нім можуть бути присутніми лише|тільки| прості умови пошуку.
5. У запиті не повинна міститися|утримуватися| пропозиція|речення| GROUP| BY| або HAVING|.
Правила, встановлені|установлені| в стандарті SQL1|, є дуже жорсткими. Існує безліч вистав|подань|, які теоретично можна оновлювати|обновляти|, хоча вони не відповідають цим правилам. Крім того, існують вистави|подання|, над якими можна проводити|виробляти| не всі операції оновлення, а також вистави|подання|, в яких можна оновлювати|обновляти| не всі стовпці. У більшості комерційних СУБД правила оновлення вистав|подань| значно менш строгі|суворі|, чим в стандарті SQL1|.
У стандарті SQL2| було формально закріплене використання оператора DROP| VIEW| для видалення|віддалення| вистав|подань|. У нім також деталізовані правила видалення|віддалення| вистав|подань|, на основі яких були створені інші вистави|подання|.
