Разработка реляционной БД курсового проекта

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

Условно процесс проектирования БД можно представить последовательностью выполнения основных трех этапов: 1. Информационно-логическое (инфологическое) моделирование; 2. Логическое моделирование; 3. Физическое моделирование.

Инфологическое моделирование 1. На основе анализа ПО выявляются документы и их реквизиты, подлежащие хранению в БД. Определяются ограничения ПО. Реквизит – качественная или количественная характеристика. Ограничения – перечень условий, налагаемых на возможные значения реквизитов документа.

Пример ПО – планирование производства продукции несколькими цехами предприятия. Входные документы: 1. Справочник товаров, справочник цехов – документы условно-постояной информации (сохраняют значения длительный период времени); 2. План – документ оперативно-учетной информации (постоянно меняющаяся информация).

Внешний вид входных документов примера

Инфологическое моделирование 2. Установим функциональные (не арифметические!) зависимости между реквизитами документа на основе описания ПО и ограничений.

Пример

• • Код (номер) является определяющим для других реквизитов, т. к. : Уникален и постоянен; Размер кода (номера) в символах меньше, чем наименования.

Пример

Инфологическое моделирование 3. Выявляем первичные ключи (реквизит или реквизиты однозначно определяющие остальные описательные реквизиты) и описательные реквизиты (функционально зависимые от первичного ключа). Первичный ключ : • Простой – состоит из одного реквизита; • Составной – состоит из нескольких реквизитов.

Инфологическое моделирование

Пример NЦ {НЦ}

Пример Есть транзитивные зависимости (КТ и ЕИ, КТ и NC). КТ {НТ, КЕИ, Ц, НЗ, NC} КЕИ {ЕИ} NС {НС}

Пример Есть транзитивные зависимости. NЦ {НЦ} КТ {НТ, КЕИ} КЕИ {ЕИ} NЦ, КТ , КЕИ – простые ключи NЦ, КТ, NМВ {К} NЦ, КТ, NМВ – составной ключ

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

Пример 1. Документ «Справочник цехов» - сущность «Справочник цехов» (NЦ {НЦ}) – ИО «Цех» . 2. Документ «Справочник товаров» - сущность «Справочник товаров» : КТ {НТ, КЕИ, Ц, НЗ, NC} – ИО «Товар» ; КЕИ {ЕИ} – ИО «Единица измерения» ; NС {НС} – ИО «Склад» . 3. Документ «План выпуска продукции» - сущность «План выпуска продукции» : NЦ {НЦ} – ИО «Цех» - повтор ; КТ {НТ, КЕИ} – ИО «Товар» - повтор в меньшем кол-ве реквизитов; КЕИ {ЕИ} - ИО «Единица измерения» - повтор ; NЦ, КТ, NМВ {К} – ИО «План» .

Инфологическое моделирование • • • При правильном построении ИО должен соответствовать требованиям нормализации: ИО должен иметь уникальный идентификатор – ключ (простой или составной); Описательные реквизиты должны быть взаимонезависимы; Реквизиты, входящие в составной ключ, должны быть взаимонезависимы; Каждый описательный реквизит должен функционально-полно зависеть от ключа ИО. Это означает, что каждому значению ключа соответствует только одно значение описательного реквизита. При составном ключе ИО описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ (не допускается полная зависимость описательного реквизита от какой-либо части ключа); Описательный реквизит в ИО не может зависеть от ключа транзитивно, т. е. через другой промежуточный реквизит. В случае транзитивной зависимости между реквизитами ИО необходимо выполнить расщепление совокупности реквизитов на два ИО.

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

Инфологическое моделирование Типы реальных отношений между ИО: • Нет связи; • Одно - однозначные (1: 1); Каждому экземпляру объекта А соответствует один экземпляр объекта В и наоборот.

Инфологическое моделирование Экземпляр – совокупность конкретных значений реквизитов. Каждый экземпляр уникален. Первичный ключ однозначно определяет каждый экземпляр ИО.

Инфологическое моделирование Типы реальных отношений между ИО (продолжение): • Одно - многозначные (1: М); Каждому экземпляру объекта А соответствует несколько экземпляров объекта В и каждому экземпляру объекта В соответствует один экземпляр объекта А. Объект А – главный, объект В – подчиненный.

Инфологическое моделирование • Много - многозначные (М: N). Каждому экземпляру объекта А соответствует несколько экземпляров объекта В и каждому экземпляру объекта В соответствует много экземпляров объекта А.

Инфологическое моделирование В реляционной БД много-многозначные связи не реализуются. Они модифицируются в одно-многозначные связи с образованием объекта - связки.

Инфологическое моделирование Ключ связи (внешний ключ) – общий номерной (кодовый) реквизит или реквизиты, на основе которого устанавливается связь между парой ИО. При связи 1: М в главном ИО (со стороны 1) ключ связи является первичным ключом, в подчиненном ИО (со стороны М) ключ связи – часть первичного ключа или описательный реквизит.

Пример • Документ «Справочник товаров» • Документ «План выпуска продукции»

Инфологическое моделирование 6. Построение информационно-логической модели (ИЛМ) в каноническом виде – графическое представление ПО в виде совокупности ИО и связей между ними с учетом иерархии подчинения ИО. Методы построения ИЛМ: • Неформальный (при малом количестве ИО); • Формальный (большом количестве ИО).

Пример

Пример матрицы смежности

Пример

Логическое моделирование Перед этапом логического моделирования – выбор СУБД, реализовывающей проект. ИЛМ ПО - основа для определения логической структуры БД в соответствии с типом модели данных, поддерживаемой выбранной СУБД.

Логическое моделирование В результате логического проектирования должна быть определена структура реляционной базы: • состав реляционных таблиц; • структура реляционных таблиц; • логические связи между таблицами.

Логическое моделирование Каждый ИО отображается реляционной таблицей. Логическая структура реляционной таблицы определяется реквизитным составом соответствующего ИО, где каждый столбец (поле) соответствует одному из реквизитов ИО. Ключевые реквизиты ИО отображаются полями, образующими уникальный первичный ключ реляционной таблицы. Для каждого поля должен быть определен ряд свойств.

Логическое моделирование

Логическое моделирование Структурные связи (типа 1: М) канонической ИЛМ отображаются логической связью таблиц, которая реализуется одинаковыми полями в связываемых таблицах (ключом связи). При этом ключ связи всегда должен быть идентификатором главной таблицы связи (первичный ключ) и не может быть полным первичным ключом в подчиненной таблице. Ключ связи в подчиненной таблице может быть или частью ее первичного ключа или вообще быть полем, которое не входит в ключ подчиненной таблицы.

Логическое моделирование Результат отображения ИЛМ в логическую структуру реляционной БД можно представить графически в виде схемы данных.

Пример (схема данных)

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

Пример На уровне физического моделирования каждая реляционная таблица станет таблицей БД СУБД ACCESS с соответствующей структурой. Логическая схема данных отобразится в схеме данных ACCESS. Заполняются таблицы на основе данных входных документов.