21. Логическая и физическая модели данных.

Логическая модель данных - описание объектов предметной области, их атрибутов и взаимосвязей между ними в том объеме, в котором они подлежат непосредственному хранению в базе данных системы. Строится на основе концептуальной модели данных.

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

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

На этапе проектирования физическая модель данных определяет сущности, атрибуты, связку, ограничение целостности в терминах конкретной СУБД. На этапе реализации физическая модель - совокупность файлов определенного формата (. Dbf для FoxPro). На этапе проектирования физической модели складывается описание реляционных таблиц, которые дальше должны быть реализованы в среде конкретной СУБД (FoxPro for Windows, Access, Clarion).

22. Базовые понятия реляционных баз данных. Правила Кодда.

Отношение представляет собой двумерную таблицу, которая содержит некоторые данные. Сущность - объект любой природы, данные о котором хранятся в БД. Атрибуты - свойства, которые характеризуют сущность (столбцы). Степень отношения -кількість столбцов. Схема отношения - список имен атрибутов, например, СОТРУДНИК (№ФИО, Год рождения, Должность, Кафедра). Домен - совокупность значений атрибутов отношения (типданих). Кортеж - строка таблицы. Кардинальность (мощность) - количество строк в таблице.

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

1. Правило информации. Вся информация в базе данных должна быть предоставлена Исключительно на логическом уровне и только одним способом - в виде значений, которые содержатся в таблицах.

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

3. Правило поддержки недействительных значений. На данный реляционной базе данных должна быть реализованная поддержка недействительных значений, которые отличаются от сроки символов нулевой длинные, сроки пробельных символов, и вот нуля или любого второго числа и используются для представления отсутствующих данных независимо от типа ЭТИХ данных.

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

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

- Определение данных; - Определение представлений; - Обработка данных (интерактивную и программную); - Условия целостности; - Идентификация прав доступа; - Пределы транзакций (начало, завершение и отмена).

6. Правило возобновления представлений. Все представления, которые теоретически можно обновить, должны быть доступные для обновления.

7. Правило добавления, обновления и удаления. Возможность работать с отношением как с одним операндом должна существовать НЕ только при чтении данных, но и при добавление, обновление и удаление данных.

8. Правило независимости физических данных. Прикладные программы и утилиты для работы с данными Должны на логическом уровне оставаться неприкосновенными за любых изменениях способов хранения данных или методов доступа к ним.

9. Правило независимости логических данных. Прикладные программы и утилиты для работы с данными Должны на логическом уровне оставаться неприкосновенными при ВНЕСЕНО в базовые таблицы любых изменений, которая теоретически позволяет сохранить неприкосновенными содержатся в ЭТИХ таблицах данные.

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

11. Правило независимости распространения. Реляционная СУБД не должна зависеть от потребностей конкретного клиента.

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