Реляционная модель данных
Основные этапы проектирования БД
Проектирование – процесс создания описаний новой системы, которая способна функционировать. В процессе проектирования базы данных выделяют 3 этапа:
1. концептуальное проектирование – создается концептуальная модель БД
2. логическое проектирование – создается логическая модель БД для выбранной СУБД
3. физическое проектирование – создаются файлы БД на машинном носителе.
Процесс создания информационной (концептуальной) модели начинается с определения концептуальных требований ряда пользователей. Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность переделки в дальнейшем. Требования отдельных пользователей должны быть представлены в едином «обобщенном представлении». Последнее называют концептуальной моделью.
Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения (Объект – это абстракция множества предметов реального мира, обладающих одинаковыми характеристиками и законами поведения. Класс – это множество предметов реального мира, связанных общностью структуры и поведением. Объекты объединяются в классы по общим характеристикам). Таким образом, концептуальная модель является, по существу, моделью предметной области. При проектировании концептуальной модели все усилия разработчика должны быть направлены в основном на структуризацию данных и выявление взаимосвязей между ними без рассмотрения особенностей реализации и вопросов эффективности обработки. Проектирование концептуальной модели основано на анализе решаемых на этом предприятии задач по обработке данных. Концептуальная модель включает описания объектов и их взаимосвязей, представляющих интерес в рассматриваемой предметной области и выявляемых в результате анализа данных. Имеются в виду данные, используемые как в уже разработанных прикладных программах, так и в тех, которые только будут реализованы.
Реляционная модель данных.
Логическая модель данных описывает факты и объекты, подлежащие размещению в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута - поле этой таблицы.
С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми.
На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность.
Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: <Клиент размещает заказ>, где существительными являются названия связанных между собой сущностей.
В резу4льтате проектирования базы данных должна быть создана информационно-логическая модель данных (ИЛМ), представляющая собой совокупность таблиц, для которых определен их состав и логические связи между ними. Структура таблицы определяется перечнем полей, их типом, размером, а также ключом таблицы.
Компонентами ИЛМ являются информационные объекты и структурные связи между ними. ИО – это информационное отображение определенной сущности (отличимый объект реального мира). Сведения об ИО (о сущности) имеют вид атрибутов – реквизит (свойство), характеризующий сущность, и связей – ассоциирование двух или более сущностей. У каждой сущности ноль или более атрибутов. Если нет ни атрибутов, ни связей, то это не сущность. Каждый экземпляр сущности (строка таблицы) имеет ровно одно значение, возможно, NULL).
Состав реквизитов ИО определяет его структуру. Каждый ИО с определенной структурой образует класс (вид) объекта, которому можно присвоить имя. ИО имеет линейную структуру данных, что обеспечивает простоту отражения в реляционную таблицу.
Структурные связи ИО представляют собой бинарные связи между парами ИО. Они характеризуются реальными отношениями экземпляров различных ИО (совокупностями конкретных значений реквизитов) и функциональными связями, отражающими потребности их совместной обработки.
При проектировании реляционной БД структурная связь устанавливается между ИО (если они характеризуются реальными отношениями) независимо от наличия функциональной связи, так как БД должна обеспечивать всевозможные запросы. Конкретные отношения пары ИО определяются природой реальных объектов, отображаемых этими ИО (поставщик-товар, группа-преподаватель и т.д.).