Читайте также:
|
|
правило 0: Основное правило (Foundation Rule): Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными.:
Чтобы быть реляционной системой управления базами данных (СУБД), система должна использовать исключительно свои реляционные возможности для управления базой данных.
правило 1: Явное представление данных (The Information Rule):
Информация должна быть представлена в виде данных, хранящихся в ячейках. Данные, хранящиеся в ячейках, должны быть атомарны. Порядок строк в реляционной таблице не должен влиять на смысл данных.
правило 2: Гарантированный доступ к данным (Guaranteed Access Rule):
Доступ к данным должен быть свободен от двусмысленности. К каждому элементу данных должен быть гарантирован доступ с помощью комбинации имени таблицы, первичного ключа строки и имени столбца.
правило 3: Полная обработка неизвестных значений (Systematic Treatment of Null Values):
Неизвестные значения NULL, отличные от любого известного значения, должны поддерживаться для всех типов данных при выполнении любых операций. Например, для числовых данных неизвестные значения не должны рассматриваться как нули, а для символьных данных — как пустые строки.
правило 4: Доступ к словарю данных в терминах реляционной модели (Active On-Line Catalog Based on the Relational Model):
Словарь данных должен сохраняться в форме реляционных таблиц, и СУБД должна поддерживать доступ к нему при помощи стандартных языковых средств, тех же самых, которые используются для работы с реляционными таблицами, содержащими пользовательские данные.
правило 5: Полнота подмножества языка (Comprehensive Data Sublanguage Rule):
Система управления реляционными базами данных должна поддерживать хотя бы один реляционный язык, который
(а) имеет линейный синтаксис,
(б) может использоваться как интерактивно, так и в прикладных программах,
(в) поддерживает операции определения данных, определения представлений, манипулирования данными (интерактивные и программные), ограничители целостности, управления доступом и операции управления транзакциями (begin, commit и rollback).
правило 6: Возможность модификации представлений (View Updating Rule):
Каждое представление должно поддерживать все операции манипулирования данными, которые поддерживают реляционные таблицы: операции выборки, вставки, модификации и удаления данных.
правило 7: Наличие высокоуровневых операций управления данными (High-Level Insert, Update, and Delete):
Операции вставки, модификации и удаления данных должны поддерживаться не только по отношению к одной строке реляционной таблицы, но по отношению к любому множеству строк.
правило 8: Физическая независимость данных (Physical Data Independence):
Приложения не должны зависеть от используемых способов хранения данных на носителях, от аппаратного обеспечения компьютеров, на которых находится реляционная база данных.
правило 9: Логическая независимость данных (Logical Data Independence):
Представление данных в приложении не должно зависеть от структуры реляционных таблиц. Если в процессе нормализации одна реляционная таблица разделяется на две, представление должно обеспечить объединение этих данных, чтобы изменение структуры реляционных таблиц не сказывалось на работе приложений.
правило 10: Независимость контроля целостности (Integrity Independence):
Вся информация, необходимая для поддержания целостности, должна находиться в словаре данных. Язык для работы с данными должен выполнять проверку входных данных и автоматически поддерживать целостность данных.
правило 11: Дистрибутивная независимость (Distribution Independence):
База данных может быть распределенной, может находиться на нескольких компьютерах, и это не должно оказывать влияние на приложения. Перенос базы данных на другой компьютер не должен оказывать влияния на приложения.
правило 12: Согласование языковых уровней (The Nonsubversion Rule):
Если используется низкоуровневый язык доступа к данным, он не должен игнорировать правила безопасности и правила целостности, которые поддерживаются языком более высокого уровня.
Связывание таблиц. Назначение, типы связей и средства установки связей. Понятия родительской и дочерней таблиц, первичного и внешнего ключей с примерами. Правила контроля целостности связей.
Связь (отношение) между родительским (основным, ведущим) и дочерним (подчиненным, ведомым) объектами (таблицами) производится по равенству значений ключа связи (ключ может состоять из нескольких атрибутов или полей связи) в обеих таблицах. В терминах графа родительский объект можно назвать исходным узлом, а дочерний ‑ подчиненным.
При связывании объектов используются следующие понятия:
Корневые узлы ‑ узлы без исходных узлов.
Терминальные узлы(листья) ‑ узлы без подчиненных узлов.
Подобные узлы ‑ подчиненные узлы с одним исходным узлом.
Семейство ‑ множество подобных узлов.
Размерность исходного узла ‑ число подобных узлов.
Первичный ключ ‑ уникальный ключ, используемый для связи с другим объектом. Такой ключ может быть только один на объект.
Вторичный ключ(кандидат) ‑ ключ, который может быть первичным.
Внешний ключ ‑ атрибут или группа атрибутов дочернего объекта, которые являются первичным ключом в родительском объекте (атрибут “Код подразделения” в объекте “СОТРУДНИК” является внешним ключом, так как он является первичным ключом в родительском объекте “ПОДРАЗДЕЛЕНИЕ”).
Класс принадлежности объекта(КП) ‑ обязательный (все экземпляры объекта участвуют в рассматриваемой связи) и необязательный.
Типы (степени) связей между объектами
Тип связи “Один-к-одному”, или бинарная связь (1:1). Полями связи являются ключевые поля. Одной записи родительского объекта “A” соответствует только одна запись дочернего объекта “B” и наоборот (A<-->B).
Пример. Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ” по полям связи “Табельный номер преподавателя” и “Код предмета”.
Связь типа “Один-ко-многим” (1:М). Полями связи являются ключевое поле родительского объекта и неключевое поле дочернего объекта. Одной записи родительского объекта “A” соответствует несколько записей дочернего объекта “B” (A-->>B). Объект “A” называют односвязанным, а “B” ‑ многосвязанным.
Пример. Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ”, если допускается преподавание одним преподавателем нескольких предметов, но один предмет не может преподаваться несколькими преподавателями.
Связь типа “Многие-к-одному” (М:1). Полями связи являются неключевое поле родительского объекта “А” и ключевое поле дочернего объекта ‘B” (A<=B).
Пример. Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ”, если допускается преподавание одним преподавателем не более одного предмета, но один предмет может преподаваться несколькими преподавателями.
Связь типа “Многие-ко-многим” (М:М). Полями связи являются неключевые поля родительского и дочернего объектов. Одной записи родительского объекта “A” соответствуют несколько записей дочернего объекта “B” и наоборот (A<=>B).
Пример. Связь между объектами “ПРЕПОДАВАТЕЛЬ” и “ПРЕДМЕТ”, если допускается преподавание одним преподавателем нескольких предметов и один предмет может преподаваться несколькими преподавателями.
Тип связи обычно указывается над линией связи между объектами символами “1”, “M”. Для наглядности связи типа “M” на схеме она может быть указана в виде линии с двумя стрелочками или “гусиной лапкой”, а отношение 1 ‑ в виде линии с вертикальной чертой.
Контроль целостности связей осуществляется автоматически СУБД согласно правилам, которые устанавливаются при проектировании БД.
Ввод данных. Если добавляется новая запись в дочерний объект, для которого отсутствует запись из родительского объекта, то такой ввод может быть заблокирован (режим Restrict).
Пример. Блокировка ввода записи дочернего объекта “СОТРУДНИК”, если указывается значение атрибута “Код подразделения”, отсутствующего в родительском объекте “ПОДРАЗДЕЛЕНИЕ”.
Корректировка данных. Если корректируется поле связи родительского объекта, то автоматически меняются поля связей соответствующих записей дочернего объекта (режим Cascade ‑ каскадное обновление), или корректировку нужно заблокировать (режим Restrict).
Пример. После изменения в родительском объекте “ПОДРАЗДЕЛЕНИЕ” значения атрибута “Код подразделения” с 2 на 202 автоматически изменятся в дочернем объекте “СОТРУДНИК” все записи со значением атрибута “Код подразделения”, равным 2, на новое значение 202 (все сотрудники из подразделения с кодом 2 переведутся в подразделение с новым кодом 202). Если такой перевод не может быть реальным, то можно установить правило блокировки корректировки, что не позволит изменить код подразделения в объекте “ПОДРАЗДЕЛЕНИЕ” на новое значение, если есть сотрудники в данном подразделении.
Удаление записей. Если удаляется запись родительского объекта, то автоматически удаляются все соответствующие записи дочернего объекта (режим Cascade), или удаление нужно заблокировать (режим Restrict).
Пример. После удаления в родительском объекте “ПОДРАЗДЕЛЕНИЕ” записи со значением атрибута “Код подразделения”, равным 201, автоматически удаляются в дочернем объекте “СОТРУДНИК” все записи со значением атрибута “Код подразделения”, равным 201 (все сотрудники из подразделения с кодом 201 увольняются). Если такого расформирования подразделения не может быть, то устанавливают правило блокировки каскадного удаления записей. Это не позволит удалить запись с кодом подразделения в объекте “ПОДРАЗДЕЛЕНИЕ”, равным значению 201 (сначала нужно удалить все записи из объекта “СОТРУДНИК” со значением атрибута “Код подразделения”, равным 201, а затем удалить запись в родительском объекте “ПОДРАЗДЕЛЕНИЕ” со значением атрибута “Код подразделения”, равным 201).
Дата добавления: 2014-12-20; просмотров: 18 | Поможем написать вашу работу | Нарушение авторских прав |