3. Основные свойства баз данных.

1. Совместный доступ к данным, т.е. данные введенные единожды используются многократно. 2. Минимизация избыточности данных. Ни одна БД не существует без избыточности. Избыточность существует двух видов. Управляемая - та, о которой мы знаем. Неуправляемая - хаотичная. 3. Целостность и непротиворечивость данных. Целостность - семантические правила предметной области для БД, обеспечивающиеся чаще всего за счет расширения метаданных. 4. Защита БД. 5. Поддержка транзакций - последовательность операций над БД неделимых для СУБД. 6. Увеличение гибкости обслуживания запросов данных - оптимизация запросов в СУБД. 7. Обеспечение логической независимости программы от данных, т.е. возможность изменять логическую структуру БД без изменения программы. 8. Физическая независимость, т.е. возможность изменения физического строения БД без изменения приложения. 9. Наличие развитых средств поддержки БД. 10. Сокращение времени разработки приложения за счет стандартных средств. 11. Стандартизация.

4. Этапы проектирования баз данных и их характеристика.

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

• обследование предметной области, изучение ее информационной структуры

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

• моделирование и интеграция всех представлений

По окончании данного этапа получаем концептуальную модель, инвариантную к структуре базы данных. Часто она представляется в виде модели «сущность-связь».

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

3. Физическое проектирование — определение особенностей хранения данных, методов доступа и т. д.

Различие уровней представления данных на каждом этапе проектирования реляционной базы данных:

КОНЦЕПТУАЛЬНЫЙ УРОВЕНЬ — Представление аналитика (используется инфологическая модель «сущность-связь»)

* сущности

* атрибуты

* связи

ЛОГИЧЕСКИЙ УРОВЕНЬ — Представление программиста

* записи

* элементы данных

* связи между записями

ФИЗИЧЕСКИЙ УРОВЕНЬ — Представление администратора

* группирование данных

* индексы

* методы доступа

5. Case-средства для проектирования бд. Общая характеристика. Примеры.

История систем автоматизации проектирования баз данных (CASE-средств) началась с автоматизации процесса рисования диаграмм, проверки их формальной корректности, обеспечения средств долговременного хранения диаграмм и другой проектной документации.

Эта идея, естественно, показалась разумной производителям CASE-средств проектирования БД. Подавляющее большинство подобных систем, представленных на рынке, обеспечивает автоматизированное преобразование диаграммных концептуальных схем баз данных, представленных в той или иной семантической модели данных, в реляционные схемы, специфицированные чаще всего на языке SQL. У читателя может возникнуть вопрос, почему в предыдущем предложении говорится про «автоматизированное», а не про «автоматическое» преобразование? Все дело в том, что в типичной схеме SQL-ориентированной БД могут содержаться определения многих объектов (ограничений целостности общего вида, триггеров и хранимых процедур и т. д.), которые невозможно сгенерировать автоматически на основе концептуальной схемы. Поэтому на завершающем этапе проектирования реляционной схемы снова требуется ручная работа проектировщика.

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

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

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

• прямая реализация СУБД, основанная на какой-либо семантической модели данных.

Многие авторитетные специалисты полагают, что ближе всего ко второму подходу объектно-ориентированные СУБД, чьи модели данных по многим параметрам близки к семантическим моделям (хотя в некоторых аспектах они более мощны, а в некоторых – более слабы).