12 правил Кодда
Правила Кодда для РСУБД
Доктор Эдгар Франк Кодд (19 августа 1923 г. - 18 апреля 2003 г.) был специалистом по вычислительной технике, работая в IBM, он изобрел реляционную модель управления базами данных (теоретические основы для реляционных баз данных). Кодд предложил тринадцать правил (от нуля до двенадцати) и сказал, что если система управления базами данных соответствует этим правилам, ее можно назвать системой управления реляционными базами данных. Эти правила называются правилами Codd's12. Вряд ли какой-либо коммерческий продукт следует за всем.
Правило Ноль
- Система должна квалифицироваться как реляционная, как база данных и как система управления. Чтобы система квалифицировалась как система управления реляционными базами данных (RDBMS), эта система должна использовать свои реляционные средства (исключительно) для управления базой данных.
- Другие 12 правил вытекают из этого правила. Правила следующие:
Правило 1. Правило информации: вся информация в базе данных должна быть представлена одним и только одним способом, а именно значениями в позициях столбцов в строках таблиц.
Правило 2: Правило гарантированного доступа: все данные должны быть доступны. Это правило, по сути, является повторением основного требования к первичным ключам. В нем говорится, что каждое отдельное скалярное значение в базе данных должно быть логически адресуемым путем указания имени содержащей таблицы, имени содержащего столбца и значения первичного ключа содержащей строки.
Правило 3: Систематическая обработка нулевых значений: СУБД должна позволять каждому полю оставаться пустым (или пустым). В частности, он должен поддерживать представление «отсутствующей информации и неприменимой информации», которое является систематическим, отличным от всех обычных значений (например, «отличным от нуля или любого другого числа», в случае числовых значений), и независимым от данных тип. Также подразумевается, что такие представления должны систематически обрабатываться СУБД.
Правило 4: Активный онлайн-каталог на основе реляционной модели. Система должна поддерживать онлайновый встроенный реляционный каталог, который доступен для авторизованных пользователей с помощью их обычного языка запросов. То есть пользователи должны иметь возможность доступа к структуре (каталогу) базы данных, используя тот же язык запросов, который они используют для доступа к данным базы данных.
Правило 5: Правило всеобъемлющего подъязыка данных: система должна поддерживать как минимум один реляционный язык, который
1. Имеет линейный синтаксис
2. Может использоваться как в интерактивном режиме, так и в прикладных программах,
3. Поддерживает операции определения данных (включая определения представлений), операции манипулирования данными (обновление, а также извлечение), ограничения безопасности и целостности, а также операции управления транзакциями (начало, принятие и откат).
Правило 6: Правило обновления представления: Все представления, те, которые могут быть обновлены теоретически, должны обновляться системой.
Правило 7: Вставка, обновление и удаление высокого уровня. Система должна поддерживать операторы вставки, обновления и удаления по заданному времени. Это означает, что данные могут быть извлечены из реляционной базы данных в наборах, составленных из данных из нескольких строк и / или нескольких таблиц. Это правило гласит, что операции вставки, обновления и удаления должны поддерживаться для любого извлекаемого набора, а не только для одной строки в одной таблице.
Правило 8: Физическая независимость данных. Изменения на физическом уровне (способ хранения данных, будь то в массивах или связанных списках и т. Д.) Не должны требовать изменения приложения на основе структуры.
Правило 9: логическая независимость данных: изменения на логическом уровне (таблицы, столбцы, строки и т. Д.) Не должны требовать изменения приложения на основе структуры. Независимость от логических данных труднее достичь, чем независимость от физических данных.
Правило 10: Независимость целостности. Ограничения целостности должны указываться отдельно от прикладных программ и храниться в каталоге. Должно быть возможным изменить такие ограничения по мере необходимости, без ненужного влияния на существующие приложения.
Правило 11: Независимость распространения. Распределение частей базы данных по различным местам должно быть незаметно для пользователей базы данных. Существующие приложения должны продолжать успешно работать:
1. когда впервые представлена распределенная версия СУБД; а также
2. когда существующие распределенные данные перераспределяются по всей системе.
Правило 12 : Правило не подрывной деятельности: если система предоставляет низкоуровневый интерфейс (запись за один раз), то этот интерфейс нельзя использовать для подрыва системы, например, в обход ограничения безопасности или целостности.
Упражнения по SQL
- Упражнения по SQL, практика, решение
- SQL Получить данные из таблиц [33 Упражнения]
- Булевы и реляционные операторы SQL [12 упражнений]
- Подстановочные знаки SQL и специальные операторы [22 упражнения]
- Агрегатные функции SQL [25 упражнений]
- Вывод запроса форматирования SQL [10 упражнений]
- SQL-запросы к нескольким таблицам [7 упражнений]
- ФИЛЬТРАЦИЯ И СОРТИРОВКА в базе данных персонала [38 упражнений]
- SQL СОЕДИНЯЕТ
- SQL ПОДПИСИ
- SQL Union [9 упражнений]
- SQL View [16 упражнений]
- Управление учетными записями пользователей SQL [16 упражнение]
- База данных фильмов
- ОСНОВНЫЕ запросы к базе данных фильмов [10 упражнений]
- ПОДПИСКИ на фильм База данных [16 упражнений]
- ПРИСОЕДИНЯЕТСЯ к базе данных фильма [24 упражнения]
- Футбольная база
- Вступление
- ОСНОВНЫЕ запросы по футболу базы данных [29 упражнений]
- ПОДПИСКИ по футбольной базе данных [33 упражнения]
- База данных больницы
- База данных сотрудников
- ОСНОВНЫЕ запросы к базе данных сотрудников [115 упражнений]
- БРОНИРОВАНИЕ на сотрудника База данных [77 Упражнения]
- Еще не все!
Хотите улучшить вышеуказанную статью? Вносите свои заметки / комментарии / примеры через Disqus.
Предыдущая: Синтаксис SQL
Далее: Компоненты таблицы
Новый контент: Composer: менеджер зависимостей для PHP , R программирования