5 (26) Условия и ограничения, накладываемые на отношения реляционной моделью данных

Отношение обладает следующими характеристиками:

Отношение имеет имя, которое отличается от имен всех других отношений в реляционной схеме.

Каждая ячейка отношения содержит только одно элементарное (неделимое)значение.

Каждый атрибут имеет уникальное имя.

Значения атрибута берутся из одного и того же домена.

Каждый кортеж является уникальным, т.е. дубликатов кортежей быть не может.

Порядок следования атрибутов не имеет значения.

Теоретически порядок следования кортежей в отношении не имеет значения. (Но практически этот порядок может существенно повлиять на эффективность доступа к ним.)

Большая часть свойств реляционных отношений происходит от свойств математических отношений:

При вычислении декартова произведения множеств с простыми однозначными элементами (например, целочисленными значениями) каждый элемент в каждом кортеже имеет единственное значение. Аналогично, каждая ячейка отношения содержит только одно значение. Однако математическое отношение не нуждается в нормализации. Кодд предложил запретить применение повторяющихся групп с целью упрощения реляционной модели данных.

Набор возможных значений для данной позиции отношения определяется множеством, или доменом, на котором определяется эта позиция. В таблице все значения в каждом столбце должны происходить от одного и того же домена, определенного для данного атрибута.

В множестве нет повторяющихся элементов. Аналогично, отношение не может содержать кортежей-дубликатов.

Поскольку отношение является множеством, то порядок элементов не имеет значения. Следовательно, порядок кортежей в отношении несуществен.

Однако в математическом отношении порядок следования элементов в кортеже имеет значение. Например, допустимая упорядоченная пара значений (1, 2) совершенно отлична от упорядоченной пары (2, 1). Это утверждение неверно для отношений в реляционной модели, где специально оговаривается, что порядок атрибутов несуществен. Дело в том, что заголовки столбцов однозначно определяют, к какому именно атрибуту относится данное значение. Следствием этого факта является положение о том, что порядок следования заголовков столбцов в заголовке отношения несуществен. Однако, если структура отношения уже определена, то порядок элементов в кортежах тела отношения должен соответствовать порядку имен атрибутов.

Преимущества реляционной БД(в историческом аспекте)

В реляционной модели все данные логически структурированы внутри отношений (таблиц). Каждое отношение имеет имя и состоит из именованных атрибутов (столбцов) данных. Каждый кортеж (строка) данных содержит по одному значению каждого из атрибутов. Большое преимущество реляционной модели заключается именно в этой простоте логической структуры. Хотя, конечно же, за этой простотой скрывается серьезный теоретический фундамент, которого не было у первого поколения СУБД (т.е. у сетевых и иерархических СУБД).

6(17) Концептуальное и физическое проектирование бд

Концептуальное проектирование базы данных. Процесс создания модели информации, используемой на предприятии, не зависящей от любых физических аспектов ее представления.

Концептуальное проектирование БД – 1-ый этап проектирования БД

Он заключается в создании концептуальной модели данных для анализируемой части предприятия. Эта модель данных создается на основе информации, записанной в спецификациях требований пользователей. Концептуальное проектирование базы данных абсолютно не зависит от таких подробностей ее реализации, как тип выбранной целевой СУБД, набор создаваемых прикладных программ, используемые языки программирования, тип выбранной вычислительной платформы, а также от любых других особенностей физической реализации.

При разработке концептуальная модель данных постоянно подвергается тестированию и проверке на соответствие требованиям пользователей. Созданная концептуальная модель данных предприятия является источником информации для этапа логического проектирования базы данных.

Этапы концептуального проектирования:

1. Создание локальной концептуальной модели данных исходя из представлений о предметной области каждого из типов пользователей.

2. Определение типов сущностей.

3. Определение типов связей. (между вышестоящими сущностями)

4. Определение атрибутов и связывание их с типами сущностей и связей.

5. Определение доменов атрибутов.

6. Определение атрибутов, являющихся потенциальными и первичными ключами.

7. Обоснование необходимости использования понятий расширенного моделирования (необязательный этап). .

8. Проверка модели на отсутствие избыточности.

9. Проверка соответствия локальной концептуальной модели конкретным пользовательским транзакциям.

10. Обсуждение локальных концептуальных моделей данных с конечными пользователями.

Физическое проектирование базы данных

Физическое проектирование базы данных(3-ий этап, второй был Логическое пр-е). Процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты.

Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой БД. Во время логического проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных.

Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. В случае реляционной модели данных под этим подразумевается следующее:

• создание набора реляционных таблиц и ограничений для них на основе информации, представленной в глобальной логической модели данных;

• определение конкретных структур хранения данных и методов доступа к ним, обеспечивающих оптимальную производительность СУБД;

• разработка средств защиты создаваемой системы.

Проектирование базы данных — это итерационный процесс, который имеет свое начало, но не имеет конца и состоит из бесконечного ряда уточнений. Его следует рассматривать прежде всего как процесс познания. Как только проектировщик приходит к пониманию работы предприятия и смысла обрабатываемых данных, а также выражает это понимание средствами выбранной модели данных, приобретенные знания могут показать, что требуется уточнение и в других частях проекта. Особо важную роль в общем процессе успешного создания системы играет концептуальное и логическое проектирование базы данных. Если на этих этапах не удастся получить полное представление о деятельности предприятия, то задача определения всех необходимых пользовательских представлений или обеспечения защиты базы данных становится чрезмерно сложной или даже неосуществимой. К тому же может оказаться затруднительным определение способов физической реализации или достижения приемлемой производительности системы. С другой стороны, способность адаптироваться к изменениям является одним из признаков удачного проекта базы данных. Поэтому вполне имеет смысл затратить время и энергию, необходимые для подготовки наилучшего возможного проекта.