им іншим таблицями. Можливість отримання доступу до системних таблиць, за аналогією з будь-якими іншими таблицями, складає основу іншого правила Кодда для реляційних систем. p> Реляційна модель забезпечує незалежність даних на двох рівнях - фізичному і логічному. Фізична незалежність даних означає з точки зору користувача, що подання даних абсолютно не залежить від способу їх фізичного зберігання. Як наслідок цього, фізичне переміщення даних жодним чином не може вплинути на логічну структуру бази даних. Інший тип незалежності, що забезпечується реляційними системами - логічна незалежність - означає, що зміна взаємозв'язків між таблицями і рядками не впливає на правильне функціонування програмних додатків і поточних запитів.
У визначенні системи управління реляційними базами даних згадуються три операції з вибірці даних - проектування, вибір і об'єднання , які дозволяють суворо вказати системі, які дані необхідно показати. Операція проектування вибирає стовпці, операція вибору - рядки, а операція об'єднання збирає разом дані з пов'язаних таблиць.
Віртуальні таблиці можна розглядати як деяку переміщувану за таблицями рамку, через яку можна побачити тільки необхідну частину інформації. Віртуальні таблиці можна отримати з однієї або декількох таблиць бази даних (включаючи і інші віртуальні таблиці), використовуючи будь-які операції вибору, проектування та об'єднання. Віртуальні таблиці, на відміну від В«справжніхВ», або базових таблиць, фізично не зберігаються в базі даних. У той же час необхідно усвідомлювати, що віртуальні таблиці це не копія деяких даних, що поміщається в іншу таблицю. Коли ви змінюєте дані у віртуальній таблиці, то тим самим змінюєте дані в базових таблицях. В ідеальній реляційної системі з віртуальними таблицями можна оперувати як і з будь-якими іншими таблицями. У реальному світі на віртуальні таблиці накладаються певні обмеження, зокрема на оновлення. Одне з правил Кодда говорить, що в істинно реляційної системі над віртуальними таблицями можна виконувати всі В«теоретичноВ» можливі операції. Більшість сучасних систем управління реляційними базами даних не задовольняють цьому правилу повністю.
У реальному світі управління інформацією дані часто є невідомими або неповними: невідомий телефонний номер, не захотіли вказати вік. Такі пропуски інформації створюють В«діркиВ» в таблицях. Проблема, звичайно, полягає не в простій непривабливості подібних дірок. Небезпека полягає в тому, що через них база даних може стати суперечливою. Щоб зберегти цілісність даних в реляційної моделі, так само, як і в правилах Кодда, для обробки пропущеної інформації використовується поняття нуля.
В«НульВ»
Цілісність - дуже складне і серйозне питання при управлінні реляційними базами даних. Неузгодженість між даними може виникати з цілого ряду причин. Неузгодженість або суперечливість даних може виникати внаслідок збою системи - проблеми з апаратним забезпеченням, помилки в програмному забезпеченні або логічної помилки в додатках. Реляційні системи управління базами даних захищають дані від такого типу неузгодженості, гарантуючи, що команда або буде виконана до кінця, або буде повністю скасована. Цей процес зазвичай називають управлінням транзакціями .
Інший тип цілісності, званий об'єктної цілісністю, пов'язаний з коректним проектуванням бази даних. Об'єктна цілісність вимагає, щоб жоден первинний ключ не мав нульового значення.
Третій тип цілісності, званої посилальної цілісністю, означає несуперечливість між частинами інформації, повторюваними в різних таблиць. Наприклад, якщо ви змінюєте неправильно введений номер картки страхового поліса в одній таблиці, інші таблиці, що містять цю ж інформацію, продовжують посилатися на старий номер, тому необхідно оновити і ці таблиці. Надзвичайно важливо, щоб при зміні інформації в одному місці, вона відповідно змінювалася і у всіх інших місцях . Крім того, за визначенням Кодда, обмеження на цілісність повинні:
В· Визначатися на мові високого рівня, використовуваному системою для всіх інших целей;
В· Зберігатися в словнику даних, а не в програмних додатках.
Ці можливості в тому чи іншому вигляді реалізовані в більшості систем.
7. Проектування баз даних
Процес, в ході якого вирішується, який вигляд буде у новостворюваної БД, називається проектуванням бази даних. На...
