ЖЦ СБД

1.

ЖИЗНЕННЫЙ ЦИКЛ
СИСТЕМЫ БАЗ ДАННЫХ
(СБД)

2.

ЖИЗНЕННЫЙ ЦИКЛ ИНФОРМАЦИОННЫХ
СИСТЕМ
Жизненный цикл информационных систем –
это непрерывный процесс, который начинается
с момента принятия решения о необходимости
создания информационной системы и
заканчивается в момент полного изъятия её из
эксплуатации.
Понятие жизненного цикла является одним из
базовых понятий методологии проектирования
информационной системы. Жизненный цикл –
концепция, в рамках которой удобно
рассматривать развитие системы баз данных во
времени.

3.

ФАЗЫ ЖИЗНЕННОГО ЦИКЛА
1. Фаза анализа и проектирования
1.1. Формулировка и анализ требований.
1.2. Концептуальное проектирование.
1.3. Проектирование реализации.
1.4. Физическое проектирование
2. Фаза реализации и функционирования
2.1. Реализация ИС.
2.2. Анализ функционирования и
поддержка.
2.3. Модификация и адаптация.

4.

ФОРМУЛИРОВКА И АНАЛИЗ ТРЕБОВАНИЙ
сбор требований к содержанию и процессу обработки данных
всеми пользователями, как известными, так и потенциальными.
Предусмотреть возможности расширения функций ИС (пример с
п/с учёт счетов – учёт клиентов, учёт заказов, учёт товаров, заказ
товаров…);
определение сферы применения (потребности в обработке данных
– собеседование);
сбор информации об использовании данных (источники
информации –документы, схема информационных потоков);
преобразование собранной информации в форму, удобную для ее
анализа;
определение состава и структуры данных:
составление списка всех используемых и создаваемых элементов
данных;
определение производственных задач и используемых в них
данных;
определение управленческих задач;
список правил и линий поведения в деятельности организации.

5.

КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
При разработке концептуальной модели существуют
два подхода:
выделяются основные задачи и потребности в данных
для этих задач – прикладное проектирование
+: можно сделать оптимальную структуру данных и
написать БД;
-: если возникают новые задачи, то это приводит к
реорганизации.
предметное проектирование – определяются типовые
объекты, предметные области
+: можно решать текущие и будущие задачи;
-: переизбыток данных.

6.

КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ
Определение сущностей (информационных объектов).
Сущность (entity) - это реальный или представляемый
объект, информация о котором должна сохраняться и
быть доступна.
определение характеристик – атрибутов. Атрибут –
это поименованная характеристика сущности,
значимая с точки зрения пользователя;
определение ключевых атрибутов и связей между
атрибутами. Ключ – минимальный набор атрибутов,
по значениям которых можно однозначно найти
требуемый экземпляр сущности.
Определение связей между объектами. Связь –
ассоциирование двух или более сущностей.

7.

СВОЙСТВА ИНФОРМАЦИОННЫХ ОБЪЕКТОВ
Информационный объект выделяется на основе описания предметной
области путем определения функциональных зависимостей между
атрибутами.
Пусть R(a1, a2,….an). A = {a1, a2,….an} – множество атрибутов. X, Y А
– произвольные подмножества множества атрибутов. Говорят, что Y
функционально зависит от X (X→Y) или X функционально определяет
Y, тогда и только тогда, когда каждое значение X связано точно с одним
значением Y.
Информационный объект должен обладать свойствами:
любой информационный объект должен содержать ключевой
атрибут – уникальный идентификатор, который может быть
простым или составным;
все атрибуты, входящие в составной ключ должны быть взаимно
независимыми;
любой не ключевой атрибут должен функционально зависеть от
ключа, то есть любое значение ключа соответствует одному
значению не ключевого атрибута;
при составном ключе не ключевые атрибуты должны зависеть от
всего ключа, а не от его частей.
все не ключевые атрибуты должны быть взаимно независимыми

8.

ПОДХОД МАРТИНА
на основании описания предметной области
выделить атрибуты, подлежащие хранению;
определить функциональные зависимости
между атрибутами и изобразить их
графически в виде линий, идущих от
ключевого атрибута;
выбрать все зависимые атрибуты и указать
для каждого все его ключевые;
сгруппировать атрибуты одинаково зависимые
от ключа. Полученные группы образуют
информационный объект;
проверить свойства каждого объекта

9.

Все атрибуты, входящие в составной ключ должны быть взаимно
независимыми, в противном случае зависимый атрибут необходимо
исключить из состава ключа.
R {А, В, С, D} PRIMARY KEY {А, В}. Предполагается наличие функциональной
зависимости А → В.
Атрибут В исключаем из состава ключа R {А, В, С, D} PRIMARY KEY {А}
При составном ключе не ключевые атрибуты должны зависеть от
всего ключа, а не от его частей.
R {А, В, С, D} PRIMARY KEY {А, В}
{А, В} → С {А, В} → D. Существует функциональная зависимость А → D.
Заменяем R его двумя проекциями R1 и R2.
R1 {A, D} PRIMARY KEY {A}
R2 {А, В, С} PRIMARY KEY {А, В}
FOREIGN KEY {A} REFERENCES Rl
Все не ключевые атрибуты должны быть взаимно независимыми.
R(А, В, С) PRIMARY KEY {A}
А → В и А → С. Предполагается наличие функциональной зависимости В → С
Функциональная зависимость А → C называется транзитивной
функциональной зависимостью, т.е. С зависит от А транзитивно, или
проходя через В.
В этом случае необходимо произвести расщепление данного информационного
объекта, заменить его двумя проекциями R1 и R2.
R1 {В, С} PRIMARY KEY {В}
R2 {А, В} PRIMARY KEY {A}
FOREIGN KEY {В} REFERENCES Rl.

10.

ПРИМЕР «СОТРУДНИКИ»
Сотрудник (код, фамилия, должность, стаж работы,
дата рождения, домашний адрес, национальность,
оклад, надбавка)
Оклад по должности (должность, оклад)
Надбавка за стаж(стаж работы, надбавка)

11.

ПРИМЕР «СОТРУДНИКИ»
В таблице сотрудники есть транзитивные зависимости
Сотрудник (код, фамилия, должность, стаж работы, дата
рождения, домашний адрес, национальность, оклад, надбавка)
Сотрудник (код, фамилия, должность, стаж работы, дата рождения,
домашний адрес, национальность, надбавка)
Х (должность, оклад). Уже есть такой объект
Сотрудники (код, фамилия, должность, стаж работы, дата
рождения, домашний адрес, национальность);
Х (стаж работы, надбавка). Уже есть такой объект.
Сотрудники (код, фамилия, должность, стаж работы, дата
рождения, домашний адрес, национальность);
Оклад по должности (должность, оклад)
Надбавка за стаж (стаж работы, надбавка)

12.

ER-МОДЕЛЬ (ENTITY-RELATIONSHIP,
СУЩНОСТЬ-СВЯЗЬ)
Основными понятиями ER-модели являются
сущность, связь и атрибут.
В диаграммах ER-модели сущность представляется в
виде прямоугольника, содержащего имя сущности,
атрибуты – овалами, связи – стрелками.
База данных "Питание", где должна храниться информация о
блюдах, их ежедневном потреблении, продуктах, из которых
приготавливаются эти блюда, и поставщиках этих продуктов.

13.

ТИПЫ СВЯЗЕЙ
1:1 – «один к одному»
В каждый момент времени каждому экземпляру объекта А
соответствует 1 или 0 экземпляров объекта В и наоборот.
Объекты могут быть объединены в один информационный объект,
структура которого образуется объединением атрибутов исходных
информационных объектов. В качестве ключа может быть выбран
любой из ключей исходных объектов.
1:М – «один ко многим» M:1 – «многие к одному»
Каждому экземпляру объекта А
соответствует ноль, один или
несколько экземпляров объекта В.
Нескольким экземплярам объекта
А соответствует ноль или один
экземпляр объекта В.
Связь между информационными объектами осуществляется путем вставки
дополнительного атрибута в подчиненный информационный
объект. Этот дополнительный атрибут является ключом в
исходном объекте и внешним ключом в подчиненном.

14.

ТИПЫ СВЯЗЕЙ
M:N – «многие ко многим»
Нескольким экземплярам объекта А соответствует ноль, один или
несколько экземпляров объекта В и наоборот.
Связь преобразуется в 1:М путем введения дополнительного
объекта - связки (ассоциации). В дополнительном объекте АВ
будет составной ключ, состоящий из ключей исходных объектов
(ka, kb). В дополнительном объекте АВ будет два внешних ключа:
ka для связи с объектом А и kb для связи с объектом В. Могут быть
собственные атрибуты.

15.

ТИПЫ СВЯЗЕЙ
А – поставщик, В – деталь. Поставщик может поставлять детали
различных наименований. Детали одинаковых наименований
могут поставляться различными поставщиками
Поставщик(Код поставщика (PK), Имя поставщика, город, )
Деталь (Код детали (PK), наименование, цена, )
Поставка((Код поставщика (FK), Код детали (FK)) (PK),
количество, дата,…)
Заключительный этап проектирования - нормализация.
Нормализация - разбиение таблицы (отношения) на две или
более, обладающих лучшими свойствами по сравнению с
исходной при вводе данных,внесении изменений и удалении
данных. Окончательная цель нормализации - получение такого
проекта БД, в котором каждый факт появляется лишь в одном
месте. То есть исключаются избыточность и противоречивость
данных, хранящихся в БД.
.

16.

КОНЦЕПТУАЛЬНАЯ МОДЕЛЬ
(СХЕМА ДАННЫХ)

17.

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

18.

ФАЗА РЕАЛИЗАЦИИ И ФУНКЦИОНИРОВАНИЯ
2.1. Реализация ИС
Установка информационной системы на компьютер
и загрузка реальных исходных данных. Обучение
персонала.
2.2 Анализ функционирования и поддержка
Сбор статистики и мнений, выявление и
исправление ошибок.
Анализ и восстановление данных после сбоев
2.3. Модификация и адаптация
Появление новых задач приводит к изменениям в
уже существующий проект. Меняется структура,
добавляются новые элементы данных.
Модификация происходит таким образом, чтобы
уже существующие данные не изменялись и
пользователи не видели этих изменений.