1. Классификация программных систем (Рис. 1) - Лекции - Базы данных и банки данных

Лекции - Базы данных и банки данных
скачать (226 kb.)

Доступные файлы (1):

1.doc

226kb.

16.12.2011 08:49

скачать

содержание

Загрузка...

1.doc

Реклама MarketGid:

Загрузка...

1. Классификация программных систем (Рис. 1)

Время зарождения - перед холодной войной. (создание банковских сетей).

Р

ис 1

Существует два подхода построения информационных систем.

Файл - область упорядоченной информации, озаглавленный именем.

П

ри файловой организации информация об информации сокрыта в структуре файл-программа. В явном виде не декларируется. Информация об информации - сведения что где лежит в информационной системе. При файловой организации системы для выполнения одних и тех же операций с данными, которые хранятся в различных файлах требуются различные программы. Аналогичные ситуации при работе различных пользователей с одним файлом. Выше изложенное ориентирует системы с файловой организацией на одного пользователя.

Общие характеристики файловой системы:

1. Сложность модификации, расширения, сложность построения многопользовательских систем и высокая гибкость при создании простых систем. При файловой организации сложно организовывать смысловой контроль информации, хранимой в системе, сложно устранять избыточность данных.

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

Ф

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

База данных - это совокупность именованных данных, предназначенных для машинной обработки.

Именованные данные - ассоциация (связь) с информацией об информации

Элемент данных- наименьшая неделимая единица данных которая имеет смысл при описании информации в базе данных
^

Группа данных- объединение элементов по какому-либо признаку

СУБД- совместимость языковых и программных средств предназначенных для создания, ведения и использования данных многих пользователей
^

Система БД- СУБД+ БД которая набита информацией

Система баз данных является аналогом банка информации или базы данных

Банк данных- система технических, программных, языковых и организованных средств, которая решает задачи сбора, хранения, обработки и передачи информации в соответствии с технологией баз данных

Ядром банка данных являются:

БнД = СУБД + БД1 +... Бдn , т.е. СУБД, которая настроена на работу с одной или несколько базами данных

Информационная система- система, которая автоматизирует сбор, хранение, обработку и передачу данных

Информационная система- это совокупность технических средств, программ и обслуживающего персонала

ИС=  железа +  программ + обслуживающий персонал
^

Функции, которые выполняются СУБД

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

и

трансформирует глобальную информационную структуру в структуру, которая позволяет прямо или при помощи прикладных программ решать задачи клиента

ПП- Прикладные программы

Предм Область КП 1 КП 2 .... КП 3

Администратор БД Аналитик

Системный Программист Прикладн программист

БД Системное ПО Прикладное ПО

ОС сервис

Программы

Схема взаимодействия группобслуживания базы данных

Где КП - конечные пользователи. Задача: понять, оформить модели, понять программу.

Опишем функции, которые выполняют группы обслуживания БД.

Специальные программисты занимаются созданием базового ПО для

ПВМ. Они исследуют :

ОС, СУБД, трансляторы с различных языков, сервисные программы (конверторы из одного формата в другой, драйверы, программы изменения конфигураций и т д), другие программные средства ЭВМ
^

КП 1 ...3 - конечные пользователи, т е заказчики

АНАЛИТИК- осуществляет перевод постановки задачи конечного пользователя в некоторую модель, которая понятна прикладному программисту.
^

Результат его работы- ТЗ его программы

ПРИКЛАДНОЙ ПРОГРАММИСТ -преобразует ТЗ в конечную программу.

АДМИНИСТРАТОР БД- мозговой центр фирмы. Он отвечает за определение состава и содержимое БД, защиту и эксплуатацию БД. Администратор БД решает круг проблем, которые условно делим на три части:

планирование

учет математики и железа. Планирование какой будет БД. На этом этапе Администратор БД определяет выбор железа, при этом учитываются требования пользователя и перспективы расширения БД. Сегодня, кроме ПО - СУБД, Администратор БД решают проблему приобретения инструментальных средств, которые автоматизируют сам процесс проектирования БД систем.

проектирование

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

Эксплуатация

В процессе эксплуатации администратор БД выступает гарантом действий пользователя с целью исключения возможностей разрушения целостности информации в БД. Для этого создаются свой стандарты на содержание и использование информации в БД. Кроме этого, он консультирует пользователя по правилам работы с этими стандартами, выступает координатором процесса взаимодействия между различными группами технического обслуживания БД.

Метазнания- знание о знании.

Каким образом осуществляется сбор информации о данных, хранимых в системе?

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

Какие задачи решают при помощи метаданных?

1- Устранение избыточности информации.

2- Устранение противоречивости данных.

3- В крупных ИС метаданные используются для решения проблемы сбора, хранения и обработки информации в системе БД.
^

Кем используется словарь?

1- Конечным пользователем , он необходим для поиска информации в ИС.

2- Прикладные программисты в процессе разработки ПО, должны знать что где лежит.

3- Системные программисты, которые курируют развитие системы.

4- Администраторы БД, которые отвечают за все.

Требования к организации Базы Данных.

------ Два Взгляда ------

Пользователь СУБД Тех. персонал

БД

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

2 взгляд- физическая независимость БД (физическая независимость данных) СУБД способно модифицировать способы организации БД в среде хранения. При этом не требуется вносить изменения в логическую модель БД, таким образом можно перенастраивать комплекс “железа” без ущемления интересов пользователя.

^ Поддержка логической целостности ( непротиворечивости информации в БД)

На сегодняшний день поддержка целостности осуществляется средствами СУБД на этапе ввода информации в БД. Имеется возможность задания множества допустимых значений содержимого поля или полей. В целом для глобального решения используется словарь данных, который хранит метаданные. Радикальным методом решения было бы построение смыслового анализатора информации, которая хранится в БД. Построение такого анализатора с одной стороны невозможно, а с другой- привело бы к отказу от системы БД

Проблема обеспечения физической целостности информации в БД

необходимо иметь средства восстановления информации на носители, утерянной вследствии сбоя системы. Самое простое, дорогое решение- создание контрольной копии. Более гибким является разработка спец. Программы восстановления информации (“спасается все таким образом , что можно спасти), основанных на журнале фиксации изменения БД.

^ Проблемы организации работы нескольких пользователей над одним из информационных носителей

Иванов 50 $ решения исполнения механизма транзакции

Петров 100 $

Итог- самое простое решение: один работает, другой в очереди

Суть проблемы: организации параллельного доступа пользователей к БД требует исключения конфликтных ситуаций, например- обновление одним человеком данных, которые находятся в процессе обработки другим пользователем. Такие конфликты выделяют и разрешают механизмы транзакции. Под транзакцией понимают регламентированную последовательность операций пользователя над базой данных, которая сокращает ее логическую целостность. Возможные подходы к реализации транзакции:

1- В информационном массиве выделяются группы взаимосвязанных элементов данных, работа одного пользователя с элементом из этой группы блокирует работу другого

2- Пользователи( транзакции) разбиваются по уровням приоритета. При работе системы транзакция с более высоким уровнем отменяет транзакцию

с более низким уровнем

Требование к СУБД - возможность настройки или адаптации системы к изменяющимися условиями эксплуатации.

^ Уровни представления данных

1- концептуальный (концептуальная модель)

2- уровень реализации в БД

3- физический уровень

ЭТАПЫ

1- ТЗ

2- концептуальный проект

3- логические проекты

4- физический проект в БД

Сегодня, в классической литературе выделяют 3 вида представления данных:

1- концептуальный уровень, тесно связан (является итогом) этапа концептуальной проектировки БД. Концептуальная модель объединяет информацию о предметной области, обо всех приложениях информационного банка.

^ Свойства концептуальной модели:

1- концептуальная модель - не зависит от ОС, СУБД и компьютера, то есть является машинонезависимой.

2- концептуальная модель должна детально описывать информационные процессы в предметной области. Это является дальнейшим развитием ТЗ- взгляд бюрократа(чиновника) на предметную область.

3- концептуальная модель строится неоднозначно. Сегодня нет четко формализованной процедуры построения концептуальной модели, однако есть наиболее общие концептуальные подходы, которые будут рассмотрены ниже. Как правило, к модели представляется диаграмма “сущность- связь”. Возможно словесное описание концептуальной модели или же при помощи специализированного языка. При построении концептуальные

модели работают с категориями: атрибуты, сущности, связи.

^ Под сущностями будут пониматься множество элементных данных проблемной области ( личности, факты, события)Атрибуты- элементные данные, которые описывают сущности.

Связи- ассоциации между экземплярами элементных данных Типы связей

один к одному (1:1)

один ко многим (1:n)

многие ко многим (m:n)

Пример связи:

1:1- номер студенческого билета и Ф.И.О. студента, где номер студенческого билета?

1-: постоянный клиент фирмы в течении многих лет делает заказы

- : заказ состоит из множества товаров, а каждый товар покупается несколькими покупателями

Как правило, к модели представляется диаграмма “ сущность связи”

Примеры:

заказы 1-

-1

атрибуты

Физический уровень представления данных рассмотрен не будет

Модель данных дает ответ на вопрос: “что, где лежит” Информация в БД представляется следующими классическими моделями, которые разбиваются на 2 класса:

1 -графовые : а) иерархическая б) сетевая

2 - реляционная модель

Выделяют также (кроме классических моделей) прочие модели:

1- объектноориентированные модели

2- семантическая модель данных

3- специализированная модель

1 модель

Основная идея: в каких СУБД была заимствована

Одной из важнейших характеристик СУБД является данная модель, которая определяла до недавнего времени:

1- правила порождения корректных дел данных СУБД структур данных

2- правила манипуляции с данными в БД

3- ограждения, которые накладывает пакет

Сегодня категория модели БД кроме всего прочего отображает процесс предметной области и динамику ее развития На сегодняшний день выделяют классические модели данных, это соответственно реляционная, иерархическая и сетевая модели и прочие модели. Рассмотрим их:

^ Графовые модели

иерархическая структура сетевая структура

Входная

к

орневая запись

исх. данные

1:1

1:m порожденная

запись

По какой схеме осуществляется манипуляция элементов данных определяет иерархическая и сетевая структура

Сетевые структуры более гибкие, чем иерархические Таким образом в иерархической структуре выделяется корневой тип записи Между различными записями в иерархии устанавливается связь 1:1 или 1:m. Чисто условно в рамках концепции записи делятся на исходную и порожденную Соответственно для каждой записи существует только одна исходная запись, исключение составляет корневая Второе ограничение сетевой модели:

как правило между 2 записями может быть только одна связь

Для отношения 1 : 1 порожденная запись

1 : m

исходная запись

^ Сетевая модель - усложненный вариант иерархической В ней любая запись может быть определена как входная Связи между записями обязательно однозначны, то есть

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

будет осуществлена эта операция называются текущими

^ Общая схема обработки информации в графовых моделях

1- Найти требуемые данные и сделать их текущими

2- Извлечь из БД текущие записи и положить их в буфер

3- Обработать информацию в буфере

4- Записать результата в БД

В сетевой модели данных проблема навигации обостряется

^ Объектноориентированная модель данных

эта модель имитирует жизнь предметной области подпрогаммы При построении этой модели используют следующий подход:

1- берут определенный объект с фиксированным множеством состояний-

директор

2- дополнительные объекты- оклад, гараж, секретарь

Директор посылает сообщения СК, который посылает сигнал в Г, как и СК, который должен ответить на него

Объектноориентированные модели появились под влиянием объектноориентированного программирования Терминология для этих БД “сырая” Общая концепция: есть понятие объекта, класса, отношения наследования Объекты ставятся в соотношении 2 множества: множество операций и множество состояний Объекты обмениваются сообщением, которое изменяет состояние объекта Есть категория класса, которая позволяет создавать новые объекты при помощи специальных операций; отношения наследования позволяют создавать иерархию класса Каждый класс такой структуры наследует свойства одного или нескольких супер-классов.

^ СЕМАНТИЧЕСКАЯ МОДЕЛЬ

В 70-х годах на них был бум, основная их идея- привлечь для обработки информации в БД семантику, то есть смысловое наполнение предметной области

^ Специализированные модели данных

на сегодняшний день они активно развиваются: экспертные оценки, статистический анализ, картография и т д Требуют создания оригинальных способов хранения информации в БД, которые были бы ориентированы на изящную программную редакцию операций обработки данных Как правило каждой модели данных соответствует своя СУБД Однако на компьютерном рынке появляются СУБД, которые поддерживают несколько моделей данных Такие СУБД называются мультимодельными

^ Реляционная модель данных

В 1968 г Коддом была предложена эта модель Она оказала сильное влияние сразу в 2 научных сферах: БД и искусственном числителе

^ Атомарное значение - наименьшая неделимая единица данных в реляционной модели

Домены- множество значений одного и того же типа , например множество значений одного атрибута: города

Атрибут- “характеристика “- одно из атомарных значений записи в котором хранится , например: поле

Поле - часть записи, которая содержит данные конкретного типа В acesse

это имя колонки

Д	Фамилия	Имя	Телефон	Адрес	Индекс

строка или запись			столбец или колонка

	поле

бинарное отношение ( из курса дискретной математики)

декартово подмножество выделяют (декартово произведение не посмотреть в дискрете)

Бинарное отношение используется, а не декартово произведение, т к у клиента может быть не известен телефон или адрес, а значит на этом месте будет пустое место

дискретное произведение - множество

бинарное отношение- множество

^ Ключ- одно или несколько полей, совокупность значений которых определяет любую запись таблицы

Простой ключ- ключ, построенный при помощи одного поля

Составной ключ - ключ, который состоит из нескольких полей

^ Составной ключ

ключ-код код Связь таблицы клиента и заказов (1:  )

Ф дата заказа

И тип товара

О сумма

Есть 2 таблицы -клиента и заказчика Клиент идентично определяется кодом, заказ однозначно идентифицируется 3 полями: кодом, датой и типом товара

^ Внешний ключ - одно или несколько полей таблицы, связанной с ключом другой таблицы В рассмотренном примере- внешний ключ это код

Индекс используется в БД реляционного типа Идея- при запросе нахождения информации по ключу, либо:

а) залезаем в район и сверяем запись за записью

б) переход от последнего доступа к прямому доступу, то есть

известен адрес- структура индекса файла

Значение ключевого поля

Адрес записи в БД

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

^ Реляционная алгебра

Правила обработки информации в таблицах описываются реляционной алгеброй, которая состоит из 8 операций Операндами в этой алгебре являются одна или несколько таблиц ( это называется отношением) Результат -новая таблица или отношение

Кодд выделил 8 операций:

1- объединение 2- пересечение 3- разность 4- декартов произведение

a x

a b x

b * x = c x

c y a y

b y

c y

5- селекция ( выделение исходной совместимости записи по определенному признаку)

6- проекция 7- деление 8 - соединение

Рассмотрим операцию подробно:

Только 5 операций являются теоретическими примитивами ( селекция, проекция, декартово произведение, объединение, разность) Все остальные операции могут быть выражены через теоретические примитивы

например: R= R2R2 = R1-( R1 -R2)

не всякая реляционная БД поддерживает все эти 8 операций

Нормализация

с одной стороны является критерием чистоты проекта в целом, с другой стороны- научным средством оптимизации структур таблиц Под чистотой проекта понимают концептуальный тезис: каждое поле представляет некоторый факт о ключе и ни о чем более кроме ключа

Под ключом понимают сущность, которая идентифицируется ключом и описывается полями таблиц Всего в теории выделяются 5 норм. Форм, проектировщики БД работают как правило с тремя Каждая нормальная форма описывается множеством логических условий Если таблица находится во II нормальной форме, то она обязательно соответствует I нормальной форме, если таблица в III нормальной форме, таким образом она удовлетворяет II нормальной форме

^ Условия I нормальной формы

1 - таблица не должна иметь повторяющихся записей

2 - в таблице нет повторяющихся групп полей

3 - строчки таблицы не упорядочены

4 - столбцы не упорядочены

Для удовлетворения I нормальной формы каждая таблица должна иметь ключ Построим I нормальную форму, исходная таблица:

1- (кл.поле) код покупателя 13- кредит

2- Ф 14- примечание 1

3- И 15- код товара

4- О 16- дата заказа

5- телефон 17- заказано

6- индекс 18- дата продажи

7- строка 19- продано

8- область 20- цена

9- город 21- примечание

10- адрес предприятия 22- категория

11- предприятие 23- наименование товара

12- руководитель

Если один клиент должен делать несколько заказов, таким образом эта таблица будет I нормальной формой Тогда разобьем эту таблицу на две:

1-14 -таблица 1

1- код покупателя (связь по этому полю)

2- код товара 3- дата заказа

таким образом

получили таблицу I нормальной формы Во второй таблице ключ составной, содержит поля 1,2,3 . Связь между таблицами - по полю, код покупателя

^ II нормальная форма

Таблица находится во II нормальной форме, если она удовлетворяет условиям I нормальной форме, и любое не индексное поле однозначно идентифицируется полным набором индексов полей

Во 2 таблице :

поле код товара идентифицирует 7,9,10 этой же таблицы

Построим 3 таблицу:

1- код товара

2- цена

3- категория

4- наименование

А зн-во 2 таблицы останется:

код покупателя Связь II,III таблицы 1:1 по полю “код

код товара товара”

дата заказа

заказано

дата продажи

продано

Примечание 2

Если у таблицы только одно ключевое поле , она автоматически находится во II нормальной форме

^ III нормальная форма

Условия:

1- таблица находится в III нормальной форме если она удовлетворяет II

нормальной форме

2- любое не индексное поле таблицы не индексируется с помощью не индексного поля таблицы

Из таблицы 1 выделим в отдельную таблицу поля:

Предприятие (класс)

Руководитель

Получим таблицу 4 ,таким образом получим связь 1:1 между 1 и 4 таблицами

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

10-04-96 ЛЕКЦИЯ 4

Проектирование БД, жизненный цикл БД

операционная система

комплекс технических устройств

1 фаза - проектирование системы

2 фаза- что идет после проектирования : заполнение системы информацией, расширение БД

Жизненный цикл БД делится на эти 2 фазы

С точки зрения проектировщика систем БД проектирование системы - объединение системы БД, ППО, программного обеспечения СУБД,ОС и комплексы технических средств в единую систему информации сервиса пользователя При анализе проблем жизненного цикла приложения целесообразно искать ответы на следующие 3 вопроса:

1- что представляет собой требования пользователя и в какой форме они выражаются

2- какая структура БД ( смотри рисунок выше) позволит удовлетворить требования пользователя

3- каким образом структура БД должна перестраиваться в соответствии с новыми или изменившимися требованиями

Проблемы проектирования системы БД -нечто более широкое, чем проектирование логической структуры Необходимо анализировать и в той или иной мере оговаривать или обосновывать выбор средств, которые представлены на рисунке При обосновании целесообразно ссылаться на требования пользователей, которые формируются в ТЗ Как правило, при анализе всплывают 2 класса проблем:

1- заключается в максимальном снижении себестоимости проекта при условии отсутствия “обиженных” пользователей ( система БД -многопользуемая система и необходимо избежать низкого качества обслуживания отдельных пользователей)

2- при проектировании системы БД необходимо обеспечить ее гибкость: ориентировать ее на последующую ее модификацию и расширение

^ Жизненный цикл системы БД

Концепция жизненного цикла системы БД позволяет наукообразно писать развитие системы БД во времени

Жизненный цикла системы БД состоит из 2 фаз:

1- анализы и проектирования системы БД

2- эксплуатация

В рамках каждой фазы удалось сформировать отдельные этапы:

Первая фаза (анализа и проектирования систем) включает следующими этапы:

1- формирование, анализ требований пользователей (ТЗ)

2- концептуальное проектирование

3- проектирование и реализация

4- физическое проектирование системы, которое не отображено в дипломе

Вторая фаза (эксплуатации) включает этапы:

1- реализация БД

2- поддержка функционирования

3- модификация и адаптация системы

^ Детальное обсуждение этапов жизненных циклов системы БД

Формирование и анализ требований пользователей являются наименее изученным, трудным процессом этапа проектирования В рамках этого этапа часто бывает необходимо опросить десятки клиентов, которые говорят с тобой на разных языках Провести анализ их требований и сформировать ТЗ, которое удовлетворило бы заказчика, не стало бы бременем для исполнителя

Цель этапа - выделить “ откуда берется информация” , каким образом обрабатываются данные , требования к данным ( секретность и т д) и куда они в дальнейшем передаются В рамках этого этапа остро стоят 2 проблемы:

1- как корректно собирать информацию от пользователя

2- как ее согласовать в рамках вышеформируемой задачи

Помощь и оказание -метод экспертных оценок, которые разработаны

социологами

^ Концептуальное проектирование - цель: построение концептуальной модели, которая с одной стороны СУБД и программно независимы, с другой стороны концентрированно отображает соответствующие точки зрения пользователей на их проблемы ( на предметную область)

^ Проектирование и реализация - состоит из 2 компонентов :

1- проектирование логической структуры БД

2- проектирование прикладных программ при помощи инструментальных средств, генерации программного обеспечения, которая встроена в СУБД

( в рамках vizual технологии vizual basic ): экране формы, командные кнопки, макросы, запросы, мастера и т д

или при помощи языковых средств, которые обязательно входят в состав СУБД ( Acess Basic, X- Base-язык) или при помощи вставок, программ на языке С, Паскаль, Asm

^ Физическое проектирование - включает 2 компонента

1- определение физической структуры БД в рамках комплекса технических средств

2- отладка программных модулей в рамках физической структуры Итогом этого этапа является полностью готовая к внедрению структура БД

^ Фаза реализации и функции БД -

Первый этап: реализация БД включает в себя заполнение спроектированной системы БД информации После загрузки в БД информации ( при помощи конверторов) неизбежно следует фаза проверки как содержимого БД так и работоспособности прикладной ПО в рамках генерированной системы

Второй этап: поддержка функционирования работы СУБД включает в себя 2 комплекса проблем :

1- а) обеспечение целостности БД б) борьба со сбоями, несанкционированным доступом к информации

2- выделение “узких мест “ проекта в целом и выработка комплекса мер по их преодолению

При выделении “узких мест “ помогает сбор статистической информации, которая отображает функционирование системы в целом: чистота обращения к этим данным, фиксация всех сбоев и задержек

^ Модернизация и адаптация системы- предусматривает внесение в реализованный проект изменения

Различают 2 причины

1- изменение требований пользователя

2- “узкие места” проекта

Цель этого этапа жизненного цикла- улучшить функционирование систем

изменение узкие

требований места

пользователя проекта

реорганизация

реформатирование реструктурирование

Реформирование- изменение физической структуры БД, то есть

оптимизация размещения информации на носителях в соответствии с результатами обработки статистической информации ( что чаще всего для работы и должно быть под рукой)

Реструктурирование- изменение логической структуры, форматов полей, ведение новых таблиц (если это реляционная модель)

Изменение ПО, кроме этих 2 причин (смотри выше) возможно потребуется вносить после реструктурирования

^ Процесс проектирования БД

1- составление ТЗ

2- концептуальное проектирование

3- проектирование и реализации

4- физическое проектирование

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

^ Метод интеллектуального штурма ( экспертной оценки )

преследует цель обнаружить ошибки, “узкие места” проекта на ранних этапах жизненного цикла БД (чем раньше может быть выявлено “ узкое место”, тем меньше придется платить за ее преодоление) Соответственно для проведения экспертизы формируются бригады экспертов, которые включают ведущих специалистов из групп : администраторов БД, разработки ПО, системных программистов, обслуживающего персонала, ведущих специалистов предметных областей создания БД Соответственно назначается руководитель бригады экспертов ( как правило администратор БД ) Заседание экспертов целесообразно проводить не менее 4 раз в течении жизненного цикла БД Во-первых после этапа концептуального проектирования, во- вторых после реализации, в третьих перед началом эксплуатации системы, в четвертых в процессе эксплуатации системы когда обнаружены “узкие места “ проекта

^ Схема проведения экспертизы -

1- председатель курирует оформление документации по обсуждаемой проблеме, которая распространяется среди экспертов за несколько дней до экспертизы ( 8-12 дней )

2- при заседании делается сообщение по обсуждаемым проблемам и возможных пути преодоления

3- все замечания экспертов в устной и письменной форме протоколируются

4- заседания ведет председатель, который наделен большими полномочиями , в частности в случае возникновения “базара” он прерывает заседания экспертной бригады

5- заседание должно продолжаться не более полутора часов Если время истекло и люди не пришли к соглашению, заседание готовит новый пакет документов для новой экспертизы Как правило за 2-3 заседания вырабатывается приемлемая для всех решение проблем

Концептуальное Проектирование

Цель этапа: необходимо представить информацию о предметной области

в форме, которая позволяет реализовать БД несколькими альтернативными

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

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

С другой стороны, описание концептуальной модели должно позволять

“красиво перейти” к этапу проектирования и описанию логической структуры БД.

Выделяют несколько способов описания концептуальной модели:

1. Диаграмма сущность-связь

2. Словесное описание

3. Отношение при помощи таблиц или системы Фрейма

4. При помощи специализированных языков

Сравним эти способы описания:

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

Словесное описание или описание при помощи таблиц удобно для проектировщика, но не всегда на руку пользователю.

Описание концептуальной модели специализированными языками ориентируется на процесс проектирования и позволяет гибко перейти от концептуальной модели к проектированию логической структуры БД с использованием средств автоматизации ( САПР , и так далее ).

Диаграмма сущность-связь

как средство высокоуровнего представления концептуальной модели.

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

Пример описания диаграммы сущность-связь процесса назначения служащего на работу над конкретным проектом.

1 вариант.

сущность назначение (связь)

сущность

2

вариант: проект (атрибут)

служащий (атрибут)

3

вариант: сущность

назначенный назначение на

служащий проект

(атрибут) (атрибут)

Один и тот же объект на разных диаграммах могут выступать в различных ролях, например проект может выступать в качестве сущности или атрибута, назначение выступает в качестве сущности, атрибута и связи.

Исходя из этого главной проблемой являтся проблема- как “красиво” описать предметную область , оптимально . Другой проблемой является проблема интеграции различных концептуальных схем: при создании сложных проектов , например , создание информационного сервиса завода , как правило дел каждого отдела или подразделения создаются свои концептуальные схемы , которые затем должны быть объединены в единую .

Сложности возникают при попытке объедимнения одних элементов структур различных концептуальных схем ( например- объединение различных множеств в сущности в одно) . Сложность возрастает в несколько раз , если одни и те же примитивы предметной области в различных концептуальных схемах играют различные роли ( например- один и тот же объект в различных схемах интегрируется как сущность , атрибут или связь одновременно)

Выходом из тупиковой ситуации является применение абстракции .

^ Подходы к концептуальному проектированию

требования

Высокоуровневое

Традиционный ( абстрактное )

Подход Представление

Моделирование Объектное

Сущностей Представление

Объектное (высокоуровневое или абстрактное ) представление процессов в предметной области

Суть концепсии;- задаемся гипотезой , что в предметной области существует “ чистое множество понятий” , которые могут быть объединены в концептуальную схему .

Термин , “чистое понятие” подразумевает , что каждый элемент множества содержит в себе значение свойства или характеристику , которая отличает его от других .

Вторая гипотеза: элементы множества “чистых понятий “ могут быть объединены в иерархическую структуру , каждый элемент которой аккумулирует свойства , которые являются общими для связанных элементов несущих ступеней иерархии .

Абстрактный , то есть не связанный с каким либо конкретными предметами или явлениями предметной области При помощи абстракции создаются математические модели и концепции , которые позволяют выделять и описывать законы различных предметных областей При объектном подходе возникают следующии проблемы:

1- как выделять абстрактный объект

2- как синтезировать их атрибуты ( свойства)

3- как их объединять в иерархию

Выделяют 2 подхода к построению абстрактных объектов:

1) обобщение 2) агрегация

Агрегация

Примеры агрегации:

объекты в предметной области агрегатный объект

1- человек бронирует номер бронирование

в гостинице на дату

2- машина перевозит груз

от пункта загрузки до перевозка (рейс)

места назначения

то есть АГРЕГАТНЫЙ ОБЪЕКТ охватывает несколько более мелких

теоретических объектов , причем он своим появлением в концептуальной модели отображает деление

Агрегатный объект заключает в себе смысл (цель) агрегатных компанентов ( они подчеокнуты) .

Каждый компанент не является подмножеством какогото сложного объекта , а на уровне концепции рассматривается как простой Генерированный абстрактный объект описывает взаимосвязи между простыми объектами и отображает смысл процесса в предметной обдласти

Обобщение

класс объекта родовой объект

собака , кошка , слон животное

повозка ,тягач , велосипед дорожное средство

классы объектов обобщены категорией

Родовой объект подчеркивает общую природу класса объектов , при этом игнорируются отличия

Говорят , что класс объектов обобщается категорией , ччто эдлемент класса относится категории

^ Соотношение между агрегацией и обобщением

между агрегатными и родовыми объектами есть общее свойство : они абстрактны . Соответственно при построении диаграмм родовой объект может выступать в качестве агрегатного и наоборот Различия заключаются только в путях синтнза абстрактных объектов

^ Иерархия абстракции - если несколько раз последовательно применить операции обобщения или агрегации , таким образом получится иерархия объекта

В

елосипед Тягач Лайнер Самолет Планер

МАЗ ГАЗ

в структуре иерархии обобщения отметим следующие особенности:

1- иерархия может содержать несколько корней ( если средства передвижения удалить , таким образом получим 3 корня)

2- некоторые категории могут одновременно принадлежать нескольким объектам ( например- самолет)

пример иерархии агрегации

Обслуживание Перевозка

1-n

Механик Дата Пункт назначения Груз

мя Мастерская Изготовитель

Идент. № Стоимость

Название

Фирмы Расположение

Между агрегатными объектами и его компонентами существует соотношение 1 : n Анализ 2-х диаграмм позволяет выделить общий абстрактный объект - моторное средство передвиижения Это позволяет объединить 2 концепцуальные схемы в одну

с

тратегия

тягач лайнер самолет

бобщение

Идентифицирующий № Стоимость Изготовитель

Название фирмы Расположение

использованный подход к построению 3 -х мерных диаграмм позволяет весьма часто решить задачи объединения различных концептуальных схем в одну , которая наиболее удобна для пользователя

^ Моделирование сущностей

Сущность- основное содержание явления или процесса в предметной области , о которой собирается информация

Пример: личность , вещь , документ- все это сущность

Выделяют категории:

1- тип сущностей- набор однородных предметов или вещей , которые на уровне концепции выступают как одно целое ( аналогично категория множества)

2- экземпляр сущности - конкретная вещь в наборе типа сущностей (аналогично элементам множества)

3- атрибуты - средства определения сущности , или именованная характеристика сущности

Наименования атрибута должно быть уникальным для конкретного типа сущности Атрибуты могут повторятся для различных типов сущностей

4- связи - отображают ассоциации между сущностями Связи бывают:

1 :1, 1 : многим , многие ко многим Эта характеристика называется степенью ассоциативности

^ Суть подхода моделирования сущности при построениии концепции модели (метод штыковой атаки)

1- при анализе предметной области выделяют различные типы сущностей

2- для каждого типа формируется множество атрибутов , которые должны выполнять функции:

а) идентифицировать сущности

б) описывать их свойства ( характеристики)

в) организовывать взаимосвязи ( ассоциации ) между различными типами сущностей

3- строятся связи ( через атрибуты или напрямую) При этом выделяют следующие ситуации:

а) возможна обязательная связь , то есть существование обоих сущностей жестко зависит от связи При удалении одной сущности , удаляется сущность взаимосвязанная с ней

б) необязательная связь: существование обоих сущностей не зависит от связи

в) условная связь , когда существование подчиненной сущности зависит от связи и от логического условия , которые ему приписывается

пример- связь 1 : многим , клиент : заказы