Слайд 1Разработка реляционной БД курсового проекта
Слайд 2Реляционная база данных (РБД) – совокупность реляционных двумерных таблиц (отношений),
описывающих конкретную предметную область (ПО), организованных специальным образом для хранения
на машинном носителе и управляемых реляционной СУБД (РСУБД).
ПО – совокупность реальных объектов, процессов, связей между ними.
Слайд 3Условно процесс проектирования БД можно представить последовательностью выполнения основных трех
этапов:
Информационно-логическое (инфологическое) моделирование;
Логическое моделирование;
Физическое моделирование.
Слайд 4Инфологическое моделирование
На основе анализа ПО выявляются документы и их реквизиты,
подлежащие хранению в БД. Определяются ограничения ПО.
Реквизит – качественная
или количественная характеристика.
Ограничения – перечень условий, налагаемых на возможные значения реквизитов документа.
Слайд 5Пример
ПО – планирование производства продукции несколькими цехами предприятия.
Входные документы:
Справочник товаров,
справочник цехов – документы условно-постояной информации (сохраняют значения длительный период
времени);
План – документ оперативно-учетной информации (постоянно меняющаяся информация).
Слайд 6Внешний вид входных документов примера
Слайд 7Инфологическое моделирование
Установим функциональные (не арифметические!) зависимости между реквизитами документа на
основе описания ПО и ограничений.
Слайд 9Код (номер) является определяющим для других реквизитов, т.к.:
Уникален и постоянен;
Размер
кода (номера) в символах меньше, чем наименования.
Слайд 12Инфологическое моделирование
Выявляем первичные ключи (реквизит или реквизиты однозначно определяющие остальные
описательные реквизиты) и описательные реквизиты (функционально зависимые от первичного ключа).
Первичный ключ :
Простой – состоит из одного реквизита;
Составной – состоит из нескольких реквизитов.
Слайд 15Пример
Есть транзитивные зависимости (КТ и ЕИ, КТ и NC).
КТ
{НТ, КЕИ, Ц, НЗ, NC}
КЕИ {ЕИ}
NС
{НС}
Слайд 16Пример
Есть транзитивные зависимости.
NЦ {НЦ}
КТ
{НТ, КЕИ}
КЕИ {ЕИ}
NЦ, КТ , КЕИ –
простые ключи
NЦ, КТ, NМВ {К}
NЦ, КТ, NМВ – составной ключ
Слайд 17Инфологическое моделирование
Образовать информационный объект из каждой группы описательных реквизитов с
общим для них первичным ключом.
Информационный объект (ИО) – информационное описание
некоторой сущности (реального объекта, процесса, явления, события), о которой должна накапливаться информация в БД.
Сущность – источник информации. Сущность первична, ИО вторичны.
Слайд 18Пример
Документ «Справочник цехов» - сущность «Справочник цехов» (NЦ
{НЦ}) – ИО «Цех».
Документ «Справочник товаров» - сущность «Справочник
товаров»:
КТ {НТ, КЕИ, Ц, НЗ, NC} – ИО «Товар»;
КЕИ {ЕИ} – ИО «Единица измерения»;
NС {НС} – ИО «Склад».
Документ «План выпуска продукции» - сущность «План выпуска продукции»:
NЦ {НЦ} – ИО «Цех» - повтор ;
КТ {НТ, КЕИ} – ИО «Товар» - повтор в меньшем кол-ве реквизитов;
КЕИ {ЕИ} - ИО «Единица измерения» - повтор ;
NЦ, КТ, NМВ {К} – ИО «План».
Слайд 19Инфологическое моделирование
При правильном построении ИО должен соответствовать требованиям нормализации:
ИО должен
иметь уникальный идентификатор – ключ (простой или составной);
Описательные реквизиты должны
быть взаимонезависимы;
Реквизиты, входящие в составной ключ, должны быть взаимонезависимы;
Каждый описательный реквизит должен функционально-полно зависеть от ключа ИО. Это означает, что каждому значению ключа соответствует только одно значение описательного реквизита. При составном ключе ИО описательные реквизиты должны зависеть целиком от всей совокупности реквизитов, образующих ключ (не допускается полная зависимость описательного реквизита от какой-либо части ключа);
Описательный реквизит в ИО не может зависеть от ключа транзитивно, т.е. через другой промежуточный реквизит. В случае транзитивной зависимости между реквизитами ИО необходимо выполнить расщепление совокупности реквизитов на два ИО.
Слайд 20Инфологическое моделирование
Определение связей между парой ИО на основе реальных отношений
(из описания ПО, природы ИО) между этими ИО.
Функциональная связь между
ИО имеется, если необходима совместная обработка данных, представленных соответствующими ИО.
Слайд 21Инфологическое моделирование
Типы реальных отношений между ИО:
Нет связи;
Одно - однозначные (1:1);
Каждому экземпляру объекта А соответствует один экземпляр объекта В и
наоборот.
Слайд 22Инфологическое моделирование
Экземпляр – совокупность конкретных значений реквизитов. Каждый экземпляр уникален.
Первичный ключ однозначно определяет каждый экземпляр ИО.
Слайд 23Инфологическое моделирование
Типы реальных отношений между ИО (продолжение):
Одно - многозначные (1:М);
Каждому экземпляру объекта А соответствует несколько экземпляров объекта В и
каждому экземпляру объекта В соответствует один экземпляр объекта А. Объект А – главный, объект В – подчиненный .
Слайд 24Инфологическое моделирование
Много - многозначные (М:N).
Каждому экземпляру объекта А соответствует
несколько экземпляров объекта В и каждому экземпляру объекта В соответствует
много экземпляров объекта А.
Слайд 25Инфологическое моделирование
В реляционной БД много-многозначные связи не реализуются. Они модифицируются
в одно-многозначные связи с образованием объекта - связки.
Слайд 26Инфологическое моделирование
Ключ связи (внешний ключ) – общий номерной (кодовый) реквизит
или реквизиты, на основе которого устанавливается связь между парой ИО.
При
связи 1:М в главном ИО (со стороны 1) ключ связи является первичным ключом, в подчиненном ИО (со стороны М) ключ связи – часть первичного ключа или описательный реквизит.
Слайд 27Пример
Документ «Справочник товаров»
Документ «План выпуска продукции»
Слайд 28Инфологическое моделирование
Построение информационно-логической модели (ИЛМ) в каноническом виде – графическое
представление ПО в виде совокупности ИО и связей между ними
с учетом иерархии подчинения ИО.
Методы построения ИЛМ:
Неформальный (при малом количестве ИО);
Формальный (большом количестве ИО).
Слайд 32Логическое моделирование
Перед этапом логического моделирования – выбор СУБД, реализовывающей
проект.
ИЛМ ПО - основа для определения логической структуры БД в
соответствии с типом модели данных, поддерживаемой выбранной СУБД.
Слайд 33Логическое моделирование
В результате логического проектирования должна быть определена структура
реляционной базы:
состав реляционных таблиц;
структура реляционных таблиц;
логические связи между таблицами.
Слайд 34Логическое моделирование
Каждый ИО отображается реляционной таблицей.
Логическая структура реляционной
таблицы определяется реквизитным составом соответствующего ИО, где каждый столбец (поле)
соответствует одному из реквизитов ИО.
Ключевые реквизиты ИО отображаются полями, образующими уникальный первичный ключ реляционной таблицы.
Для каждого поля должен быть определен ряд свойств.
Слайд 36Логическое моделирование
Структурные связи (типа 1:М) канонической ИЛМ отображаются логической
связью таблиц, которая реализуется одинаковыми полями в связываемых таблицах (ключом
связи).
При этом ключ связи всегда должен быть идентификатором главной таблицы связи (первичный ключ) и не может быть полным первичным ключом в подчиненной таблице. Ключ связи в подчиненной таблице может быть или частью ее первичного ключа или вообще быть полем, которое не входит в ключ подчиненной таблицы.
Слайд 37Логическое моделирование
Результат отображения ИЛМ в логическую структуру реляционной БД
можно представить графически в виде схемы данных.
Слайд 39Физическое моделирование
увязка логической структуры БД и физической среды хранения с
целью наиболее эффективного размещения данных.
Слайд 40Пример
На уровне физического моделирования каждая реляционная таблица станет таблицей
БД СУБД ACCESS с соответствующей структурой. Логическая схема данных отобразится
в схеме данных ACCESS. Заполняются таблицы на основе данных входных документов.