Разлика между версии на „12-те правила на Код“
| (Не са показани 8 междинни версии от същия потребител) | |||
| Ред 1: | Ред 1: | ||
| − | + | Множеството разработени СУБД (система за управление на бази от [[Анализ на данните|данни]]), които са обявени за релационни, всъщност не отговарят напълно на изискванията на релационния модел. Поради това, Код формулира '''едно основно и 11 допълнителни правила''', които '''определят критериите за оценка дали даден [[софтуер]] може да се приеме за релационна СУБД'''. | |
| − | Множеството разработени СУБД (система за управление на бази от данни), които са обявени за релационни, всъщност не отговарят напълно на изискванията на релационния модел. Поради това, Код формулира '''едно основно и | ||
==Основно правило на Код== | ==Основно правило на Код== | ||
| + | |||
| + | |||
Всяка релационна СУБД трябва да може да управлява БД посредством възможностите на Релационния модел. | Всяка релационна СУБД трябва да може да управлява БД посредством възможностите на Релационния модел. | ||
==Допълнителни правила на Код== | ==Допълнителни правила на Код== | ||
| − | 1. Представяне на | + | [[file:bd.jpg|right|thumb|500px|Отчет на база данни в Аccess]] |
| + | 1. Представяне на [[информация]]та. | ||
Цялата информация на релационната БД се представя на логическо ниво и по единствен начин – чрез стойностите в таблиците. | Цялата информация на релационната БД се представя на логическо ниво и по единствен начин – чрез стойностите в таблиците. | ||
| Ред 13: | Ред 15: | ||
2. Гарантиран достъп. | 2. Гарантиран достъп. | ||
| − | Всяка атомарна стойност в релационната БД е логически достижима чрез името на | + | Всяка атомарна [[стойност]] в релационната БД е логически достижима чрез името на [[таблица]]та, стойността на първичния ключ и името на [[колона]]та. |
3. Системно третиране на стойността “nul”. | 3. Системно третиране на стойността “nul”. | ||
| Ред 19: | Ред 21: | ||
Стойностите “nul” се поддържат от СУБД по системен път, независимо от типовете данни. | Стойностите “nul” се поддържат от СУБД по системен път, независимо от типовете данни. | ||
| − | 4. Динамичен интерактивен каталог. | + | 4. Динамичен интерактивен [[каталог]]. |
Описанието на данните се представя на логическо ниво по същия начин както и самите данни. | Описанието на данните се представя на логическо ниво по същия начин както и самите данни. | ||
| Ред 27: | Ред 29: | ||
*СУБД трябва да предоставя поне един език, с който да се изразяват: | *СУБД трябва да предоставя поне един език, с който да се изразяват: | ||
*Дефинирането на данните; | *Дефинирането на данните; | ||
| − | *Дефинирането на | + | *Дефинирането на [[потребител]]ските представи; |
*Обработка на данните; | *Обработка на данните; | ||
*Ограниченията на целостта; | *Ограниченията на целостта; | ||
| − | *Правилата за достъп; | + | *Правилата за [[достъп]]; |
*Границите на транзакциите. | *Границите на транзакциите. | ||
| Ред 36: | Ред 38: | ||
*Потребителските представи се обновяват от СУБД. | *Потребителските представи се обновяват от СУБД. | ||
| − | *Обновяване на данните на високо ниво | + | *Обновяване на данните на високо [[ниво]]. |
*Обновяването на данните трябва да може да се извършва на ниво таблица. | *Обновяването на данните трябва да може да се извършва на ниво таблица. | ||
| Ред 43: | Ред 45: | ||
При промяна на методите на достъп или представянето в паметта, приложните програми не се променят логически. | При промяна на методите на достъп или представянето в паметта, приложните програми не се променят логически. | ||
| − | 8. Логическа независимост на данните. | + | 8. Логическа [[независимост]] на данните. |
При промяна в таблиците, наложена от разработването на нови приложения, старите приложения не се променят логически. | При промяна в таблиците, наложена от разработването на нови приложения, старите приложения не се променят логически. | ||
| Ред 51: | Ред 53: | ||
Ограниченията за цялостност се задават с езика за заяви и се съхраняват в каталога, а не в приложните програми. | Ограниченията за цялостност се задават с езика за заяви и се съхраняват в каталога, а не в приложните програми. | ||
| − | 10. Независимост на | + | 10. Независимост на [[разпределение]]то. |
| − | Приложната програма, която се обръща към дадена СУБД, трябва да работи и при разпределение на БД по възлите на | + | Приложната [[програма]], която се обръща към дадена СУБД, трябва да работи и при разпределение на БД по възлите на [[мрежа]]та. |
11. Защита на данните. | 11. Защита на данните. | ||
| − | + | [[Достъп]]ът до данните се контролира изцяло от СУБД и нейната цялостност не може да бъда нарушена без знанието на [[администратор]]а или потребителя. | |
==Вижте още== | ==Вижте още== | ||
| Ред 65: | Ред 67: | ||
*[[Кевин Уоруик]] | *[[Кевин Уоруик]] | ||
*[[Линеен код]] | *[[Линеен код]] | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
==Източници== | ==Източници== | ||
| Ред 79: | Ред 76: | ||
*[http://office.microsoft.com/bg-bg/access-help/HA001224247.aspx Основи на проектирането на бази данни] | *[http://office.microsoft.com/bg-bg/access-help/HA001224247.aspx Основи на проектирането на бази данни] | ||
*[http://www.grao.bg/nbd.html Национална база данни ГРАО] | *[http://www.grao.bg/nbd.html Национална база данни ГРАО] | ||
| − | [[category: | + | [[category:Информатика]] |
Текуща версия към 15:37, 9 април 2014
Множеството разработени СУБД (система за управление на бази от данни), които са обявени за релационни, всъщност не отговарят напълно на изискванията на релационния модел. Поради това, Код формулира едно основно и 11 допълнителни правила, които определят критериите за оценка дали даден софтуер може да се приеме за релационна СУБД.
Основно правило на Код
Всяка релационна СУБД трябва да може да управлява БД посредством възможностите на Релационния модел.
Допълнителни правила на Код
1. Представяне на информацията.
Цялата информация на релационната БД се представя на логическо ниво и по единствен начин – чрез стойностите в таблиците.
2. Гарантиран достъп.
Всяка атомарна стойност в релационната БД е логически достижима чрез името на таблицата, стойността на първичния ключ и името на колоната.
3. Системно третиране на стойността “nul”.
Стойностите “nul” се поддържат от СУБД по системен път, независимо от типовете данни.
4. Динамичен интерактивен каталог.
Описанието на данните се представя на логическо ниво по същия начин както и самите данни.
5. Сложен език на заявки.
- СУБД трябва да предоставя поне един език, с който да се изразяват:
- Дефинирането на данните;
- Дефинирането на потребителските представи;
- Обработка на данните;
- Ограниченията на целостта;
- Правилата за достъп;
- Границите на транзакциите.
6. Обновяване на потребителските представи.
- Потребителските представи се обновяват от СУБД.
- Обновяване на данните на високо ниво.
- Обновяването на данните трябва да може да се извършва на ниво таблица.
7. Физическа независимост на данните.
При промяна на методите на достъп или представянето в паметта, приложните програми не се променят логически.
8. Логическа независимост на данните.
При промяна в таблиците, наложена от разработването на нови приложения, старите приложения не се променят логически.
9. Независимост на ограниченията за цялостност.
Ограниченията за цялостност се задават с езика за заяви и се съхраняват в каталога, а не в приложните програми.
10. Независимост на разпределението.
Приложната програма, която се обръща към дадена СУБД, трябва да работи и при разпределение на БД по възлите на мрежата.
11. Защита на данните.
Достъпът до данните се контролира изцяло от СУБД и нейната цялостност не може да бъда нарушена без знанието на администратора или потребителя.