Этапы проектирования БД

1. Системный анализ предметной области.
2. Инфологическое проектирование(словесное описание тех задач, кот. нужно решить)
3. Выбор СУБД
4. Даталогическое проектирование (логическое описание на языке SQL)
5. Физическое проектирование БД(это делает админ БД, располагает сегменты, функции)

Основная цель проектирования БД – это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.

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

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

Даталогическое проектирование - разработка схемы БД, совокупность схем отношений, модели объекты предметной области и связи между этими объектами.
В ходе даталогического проектирования необходимо:
1) построить схемы отношений
2) описать концептуальную схему БД и выбранную СУБД.
3) описание внешней модели
4) описание целостности правил БД.
5) разработка процедур целостности БД.
Физическое проектирование базы данных (с использованием реляционной СУБД)

Перенос глобальной логической модели данных в среду СУБД. Этап включает в себя следующие стадии:
проектирование основных таблиц в среде СУБД;
реализация бизнес-правил предприятия в среде СУБД.

Проектирование физического представления базы данных. Этап включает в себя следующие стадии:
1. анализ транзакций;
2. выбор файловой структуры;
3. определение вторичных индексов;
4. анализ необходимости введения контролируемой избыточности данных;
5. определение требований к дисковой памяти.

Этап 6. Разработка механизмов защиты.
1. разработка пользовательских представлений (видов);
2. определение прав доступа.

Организация мониторинга и настройка функционирования системы.
Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д.

Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений (например, «Красный», «Синий», «Банановый», «Белая ночь» и т.д.), однако каждому экземпляру сущности присваивается только одно значение атрибута.
Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся атрибутам. Для сущности Студент ключом может являться атрибут Номер_зачетной_книжки или набор: Фамилия, Имя, Отчество и Год рождения (при условии, что в учебном заведении не будут учиться два однофамильца, родившиеся в одном году).

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

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