Слайд 2
Существует много разновидностей методологии рассмотрения баз данных.
На рис
показана совокупность процедур проектирования централизованной БД, которые можно объединить
в четыре этапа.
Слайд 5
1. Первый этап – формулирование и анализ
На этапе
формулирования и анализа требований устанавливаются цели организации, определяются требования
к БД. Они состоят из:
Общих требований.
Специфических требований (используется методика интервьюирования (опроса) персонала различных уровней управления).
Слайд 6
Все требования документируются в форме, доступной конечному пользователю
и проектировщику БД.
Слайд 7
2. Этап концептуального проектирования
Этап концептуального проектирования заключается в
описании и синтезе информационных требований пользователей в первоначальный проект
БД.
Слайд 8
Исходными данными могут быть:
Совокупность документов пользователя при классическом
подходе
Алгоритмы приложений (алгоритмы бизнеса) при современном подходе.
Результатом этого
этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.
Слайд 9
Требования пользователей включают в себя:
1. Выбор модели БД.
2. Создание структуры БД, которая заполняется данными с помощью
команд, систем меню, экранных форм или в режиме просмотра таблиц БД.
Обеспечивается защита и целостность данных с помощью СУБД .
Слайд 10
3. Этап логического проектирования
В процессе логического проектирования высокоуровневое
представление данных преобразуется в структуру используемой СУБД.
Основной целью
этапа является устранение избыточности данных с использованием специальных правил нормализации.
Слайд 11
Цель нормализации – минимизировать повторение данных и возможные
структурные изменения БД при процедурах обновления.
Это достигается разделением
(декомпозицией) одной таблицы в две или несколько с последующим использованием при запросах операции навигации.
Слайд 12
Полученная логическая структура БД может быть оценена количественно
с помощью различных характеристик:
число обращений к логическим записям;
объем данных
в каждом приложении;
общий объем данных.
На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности.
Слайд 13
Процедура управления БД.
проста в однопользовательском режиме.
В многопользовательском
режиме и в распределенных БД процедура сильно усложняется. При
одновременном доступе нескольких пользователей без принятия специальных мер возможно нарушение целостности.
Слайд 14
Для устранения этого явления используют систему транзакций и
режим блокировки таблиц или отдельных записей.
Транзакция – процесс изменения
файла, записи или базы данных, вызванный передачей одного входного сообщения.
Слайд 15
4. Этап физического проектирования
На этапе физического проектирования решаются
вопросы, связанные с производительностью системы, определяются структуры хранения данных
и методы доступа.
Слайд 16
Количественными критерии
Время ответа на запрос;
Стоимость модификации;
Стоимость
памяти;
Время на создание;
стоимость на реорганизацию.
Затруднение может вызывать
противоречие критериев друг другу.
Слайд 17
Качественные критерии
Гибкость;
Адаптивность;
Доступность для новых пользователей;
Совместимость
с другими системами;
Возможность конвертирования в другую вычислительную среду;
Возможность восстановления;
Возможность распределения и расширения.
Слайд 18
Процесс проектирования является длительным и трудоемким и обычно
продолжается несколько месяцев.
Основными ресурсами проектировщика БД являются его
собственная интуиция и опыт, поэтому качество решения во многих случаях может оказаться низким.
Слайд 19
Основными причинами низкой эффективности проектируемых БД могут быть:
недостаточно
глубокий анализ требований (начальные этапы проектирования);
большая длительность процесса структурирования,
делающая этот процесс утомительным и трудно выполнимым при ручной обработке.
В этих условиях важное значение приобретают вопросы автоматизации разработки.
Слайд 20
2.1. Классический подход к проектированию баз данных
Этот подход
восходит к автоматизированным системам управления информационно-поискового типа, основной целью
которых являлась автоматизация документооборота (совокупности документов, циркулирующих на предприятии).
Слайд 21
I. При проектировании с использованием классического подхода исходят
из следующих положений.
1. На входе БД имелась одна система
документов, которая при использовании БД трансформировалась в другую (выходную) систему документов (таблиц, файлов).
Слайд 22
2. Запрос к БД мог осуществляться регулярно (по
регламенту) или по запросу. (Запрос предполагал получение любой структуры
документов из имеющихся в БД полей данных).
3. Данные БД использовались затем для задач принятия решений, становясь информацией. (Считалось, что алгоритмы задач более подвижны, чем данные. В силу этого создание универсальной БД позволит решить любую задачу).
Слайд 23
II. В проектировании БД, в соответствии с классической
методологией выделялись следующие этапы:
анализ требований;
концептуальное моделирование;
логическое моделирование;
физическое моделирование;
реализация.
Слайд 24
При этом, как показала практика, акцент следует делать
на начальные этапы, на которых имеет место наибольшее число
трудно исправимых ошибок
Слайд 26
Хранимые в базе данные имеют определенную логическую структуру
– иными словами, описываются некоторой моделью представления данных (моделью
данных), поддерживаемой СУБД.
Слайд 27
В некоторых СУБД поддерживаются одновременно несколько моделей данных.
Например, в системе ИНТЕРБАЗА для приложений применяется сетевой язык
манипулирования данными, а в пользовательском интерфейсе реализованы языки SQL и QBE
Слайд 28
3.1. Классификация моделей данных
Слайд 29
3.1.1. Инфологическая модель базы
Инфологическая модель базы данных представляет
собой описание объектов (сущностей), с набором атрибутов и связей
между ними, которые выявляются в процессе исследования как входных, так и выходных данных.
Слайд 30
Самая распространенная модель в инфологическом моделировании это модель
"сущность-связь" или ER-модель, к главным компонентам её относятся -
сущности и связи.
Сущности - содержание объекта, о котором набирают необходимую информацию.
Экземпляром сущности представляется - чёткий объект.
Слайд 31
ER-модель, предложенная П. Ченом в 1976 г., является
наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной
области и представляется в графической форме, с использованием оригинальной нотации
П. Чена, называемой ER-диаграмма
Слайд 32
Основные преимущества ER-моделей:
наглядность;
модели позволяют проектировать базы данных с
большим количеством объектов и атрибутов;
ER-модели реализованы во многих системах
автоматизированного проектирования баз данных (например, ERWin).
Слайд 33
Основные элементы ER-моделей:
объекты (сущности);
атрибуты объектов;
связи между объектами.
Связь
между сущностями характеризуется:
типом связи (1:1, 1:N, N:М);
классом принадлежности. Класс
может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.
Слайд 34
Диаграмма Бахмана фактически является графом типов БД. Любопытно,
что граф знаков (каждой вершине соответствует конкретная запись, а
дуге – конкретный набор) является лесом, т.е. графом, каждая компонента связности которого является деревом.
Слайд 35
3.2. Иерархическая модель
В иерархической модели связи между данными
можно описать с помощью упорядоченного графа (или дерева).
Слайд 36
Тип дерево является составным.
включает в себя подтипы
(поддеревья), каждый из которых, в свою очередь, является типом
«дерево».
Каждый из типов дерево состоит из одного корневого типа и упорядоченного набора (возможно, пустого) подчиненных типов.
Слайд 38
Корневым называется тип, который имеет подчиненные типы и
сам не является подтипом.
Подчиненный тип (подтип) является потомком
по отношению к типу, который выступает для него в роли предка (родителя).
Потомки одного и того же типа являются близнецами по отношению друг к другу.
Слайд 39
В целом тип «дерево» представляет собой иерархически организованный
набор типов запись. Поля записей хранят собственно числовые или
символьные значения, составляющие основное содержание БД. Обход всех элементов иерархической БД обычно производится сверху вниз и слева направо.
Слайд 40
достоинства иерархической модели данных
эффективное использование памяти ЭВМ
неплохие показатели времени выполнения основных операций над данными. Иерархическая
модель данных удобна для работы с иерархически упорядоченной информацией.
Слайд 41
Недостатки иерархической модели
громоздкость для обработки информации с
достаточно сложными логическими связями,
сложность понимания для обычного пользователя.
Слайд 42
На иерархической модели данных основано сравнительно ограниченное количество
СУБД, в числе которых можно назвать зарубежные системы IMS,
PC/Focus, Team-Up и Data Edge, а также отечественные системы Ока, Р1НЭС и МИРИС.
Слайд 43
3.3. Сетевая модель
Разница между иерархической моделью данных и
сетевой том, что в иерархических структурах запись-потомок должна иметь
в точности одного предка, а в сетевой структуре данных у потомка может иметься любое число предков.
Слайд 44
Сетевая модель данных позволяет отображать разнообразные взаимосвязи элементов
данных в виде произвольного графа, обобщая тем самым иерархическую
модель данных.
Наиболее полно концепция сетевых БД впервые была изложена в Предложениях группы КОДАСИЛ (KODASYL).
Слайд 47
Операций манипулирования данными баз сетевого
поиск записи в
БД;
переход от предка к первому потомку;
переход от потомка к
предку;
создание новой записи;
удаление текущей записи;
обновление текущей записи;
включение записи в связь;
исключение записи из связи;
изменение связей и т. д.
Слайд 48
Достоинство сетевой модели данных
возможность эффективной реализации по
показателям затрат памяти и оперативности.
В сравнении с иерархической
моделью сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей.
Слайд 49
Недостатки сетевой модели данных
высокая сложность и жесткость
схемы БД, построенной на ее основе,
сложность для понимания
и выполнения обработки информации в БД обычным пользователем.
ослаблен контроль целостности связей вследствие допустимости установления произвольных связей между записями.
Слайд 50
Системы на основе сетевой модели не получили широкого
распространения на практике.
Наиболее известными сетевыми СУБД являются следующие:
IDMS, db_VistaIII, СЕТЬ, СЕТОР и КОМПАС.
Слайд 51
3. Реляционная модель
Реляционная модель данных предложена сотрудником фирмы
IBM Эдгаром Коддом и основывается на понятии отношение (relation).
Отношение
представляет собой множество элементов, называемых кортежами.
Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица.
Слайд 52
Таблица имеет:
строки (записи)
столбцы (колонки).
Каждая строка
таблицы имеет одинаковую структуру и состоит из полей.
Слайд 53
Например, таблица может содержать сведения о группе обучаемых,
о каждом из которых известны следующие характеристики:
фамилия,
имя
отчество,
пол,
возраст
образование.
Слайд 54
Поскольку в рамках одной таблицы не удается описать
более сложные логические структуры данных из предметной области, применяют
связывание таблиц.
Слайд 55
простота,
понятности
удобстве физической реализации на
ЭВМ.
Именно простота и понятность для пользователя явились основной
причиной их широкого использования.
Проблемы эффективности обработки данных этого типа технически вполне разрешимыми.
Достоинство реляционной модели данных
Слайд 56
Основными недостатками реляционной модели
отсутствие стандартных средств идентификации отдельных
записей
сложность описания иерархических и сетевых связей.
Слайд 57
Примерами зарубежных реляционных СУБД для ПЭВМ являются следующие:
dBaselll Plus и dBase IY (фирма Ashton-Tate),
DB2 (IBM),
R:BASE
(Microrim),
FoxPro ранних версий и FoxBase (Fox Software),
Paradox и dBASE for Windows (Borland),
FoxPro более поздних версий,
Visual FoxPro и Access (Microsoft),
Clarion (Clarion Software),
Ingres (ASK Computer Systems) и Oracle (Oracle).
Слайд 58
К отечественным СУБД реляционного типа относятся системы:
ПАЛЬМА
(ИК АН УССР),
система HyTech (МИФИ).
Слайд 59
3.5. Постреляционная модель
Постреляционная модель данных представляет собой расширенную
реляционную модель, снимающую ограничение неделимости данных, хранящихся в записях
таблиц.
Постреляционная модель данных допускает многозначные поля, значения которых состоят из подзначений.
Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу.
Слайд 60
Пример
Информации о накладных и товарах для сравнения приведено
представление одних и тех же данных с помощью реляционной
(а) и постреляционной (б) моделей.
Слайд 61
Таблица НАКЛАДНЫЕ содержит данные о номерах накладных (№
накл) и номерах покупателей (№ пок).
Ттаблица НАКЛАДНЫЕ-ТОВАРЫ содержатся
данные о каждой из накладных: номер накладной (№ накл), название товара (Наим_тов) и количество товара (Кол-во).
Таблица Накладная связана с таблицей НАКЛАДНЫЕ-ТОВАРЫ по полю № накл.
Слайд 63
На длину и количество полей в записях таблицы
не накладывается требование постоянства.
Это означает, что структура данных
и таблиц имеет большую гибкость.
Слайд 64
Поскольку постреляционная модель допускает хранение в
таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости
данных.
Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах.
Слайд 65
Достоинством постреляционной модели
возможность представления совокупности связанных реляционных
таблиц одной постреляционной таблицей.
Это обеспечивает высокую наглядность представления
информации и повышение эффективности ее обработки.
Слайд 66
Недостатки постреляционной модели сложность решения проблемы обеспечения целостности
непротиворечивости хранимых данных.
Постреляционная модель данных поддерживается СУБД uniVers. К
числу других СУБД, основанных на постреляционной модели данных, относятся также системы Bubba и Dasdb.
Слайд 67
3.6. Многомерная модель
Многомерный подход к представлению данных в
базе появился практически одновременно с реляционным, но реально работающих
многомерных СУБД (МСУБД) до настоящего времени было очень мало.
С середины 90-х годов интерес к ним стал приобретать массовый характер.
Слайд 68
Многомерные системы позволяют оперативно обрабатывать информацию для проведения
анализа и принятия решения.
В развитии концепций ИС можно выделить
следующие два направления:
системы оперативной (транзакционной) обработки;
системы аналитической обработки (системы поддержки принятия решений).
Слайд 69
Реляционные СУБД предназначались для информационных систем оперативной обработки
информации и в этой области были весьма эффективны.
Более
эффективными для аналитической обработки оказываются многомерные СУБД (МСУБД).
Многомерные СУБД являются узкоспециали-зированными СУБД, предназначенными для интерактивной аналитической обработки информации.
Слайд 70
Раскроем основные понятия, используемые в этих СУБД:
агрегируемость,
историчность
прогнозируемость данных.
Слайд 71
Агрегируемость данных означает рассмотрение информации на различных уровнях
ее обобщения. В информационных системах степень детальности представления информации
для пользователя зависит от его уровня:
аналитик,
пользователь-оператор,
управляющий, руководитель.
Слайд 72
Историчность данных предполагает обеспечение высокого уровня статичности (неизменности)
собственно данных и их взаимосвязей, а также обязательность привязки
данных ко времени.
Временная привязка данных необходима для частого выполнения запросов, имеющих значения времени и даты в составе выборки.
Слайд 73
Прогнозируемость данных подразумевает задание функций прогнозирования и применение
их к различным временным интервалам.
Многомерность модели данных означает не
многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными.
Слайд 74
По сравнению с реляционной моделью многомерная организация данных
обладает более высокой наглядностью и информативностью.
Слайд 75
Основные понятия многомерных моделей данных
Измерение (Dimension) –
это множество однотипных данных, образующих одну из граней гиперкуба.
Примерами наиболее часто используемых временных измерений являются Дни, Месяцы, Кварталы и Годы.
В качестве географических измерений широко употребляются Города, Районы, регионы и Страны.
В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба.
Слайд 76
Ячейка (Cell) или показатель – это поле, значение
которого однозначно определяется фиксированным набором измерений.
Тип поля чаще
всего определен как цифровой.
Слайд 77
В зависимости от того, как формируются значения некоторой
ячейки, она может быть:
переменной (значения изменяются и могут
быть загружены из внешнего источника данных или сформированы программно)
формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам).
Слайд 79
В многомерной модели данных применяется ряд специальных операций
формирование среза,
вращение,
агрегация и детализация.
Слайд 80
Срез (Slice) - подмножество гиперкуба, полученное в результате
фиксации одного или нескольких измерений.
Например, если ограничить значения
измерения Модель автомобиля в гиперкубе маркой «Жигули», то получится двухмерная таблица продаж этой марки автомобиля различными менеджерами по годам.
Слайд 81
Операция вращение (Rotate) применяется при двухмерном представлении данных
и заключается в изменении порядка измерений при визуальном представлении
данных.
Операции агрегация (Drill Up) и «детализация» (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба.
Слайд 82
Основным достоинством многомерной модели данных является удобство и
эффективность аналитической обработки больших объемов данных, связанных со временем.
Недостатком является ее громоздкость для простейших задач обычной оперативной обработки информации.
Слайд 83
Примерами систем, поддерживающих многомерные модели данных, являются:
Essbase
(Arbor Software),
Media Multi-matrix (Speedware),
Oracle Express Server (Oracle)
Cache (InterSystems).
Слайд 84
3.7. Объектно-ориентированная модель
В объектно-ориентированной модели при представлении
данных имеется возможность идентифицировать отдельные записи базы.
Между записями
базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования.
Слайд 85
Структура объектно-ориентированной БД графически представима в виде дерева,
узлами которого являются объекты. Свойства объектов описываются некоторым стандартным
типом:
строковым – string
типом, конструируемым пользователем (определяется как class).
Слайд 86
Логической структура объектно-ориентированной БД на примере библиотечного дела
Слайд 87
Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров
классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА.
Различные объекты типа КНИГА
могут иметь одного или разных родителей.
Объекты типа КНИГА, имеющие одного и того же родителя, должны различаться по крайней мере инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn,ydK, название и автор.
Слайд 88
Понятия объектно-ориентированной модели БД.
Инкапсуляция ограничивает область видимости
имени свойства пределами того объекта, в котором оно определено.
Так, если в объект типа КАТАЛОГ добавить свойство, задающее телефон автора книги и имеющее название телефон, то мы получим одноименные свойства у объектов АБОНЕНТ и КАТАЛОГ.
Смысл такого свойства будет определяться тем объектом, в который оно инкапсулировано.
Слайд 89
Наследование распространяет область видимости свойства на всех потомков
объекта.
Так, всем объектам типа КНИГА, являющимся потомками объекта
типа КАТАЛОГ, можно приписать свойства объекта-родителя:
isbn,
удк,
название
автор.
Слайд 90
Полиморфизм - способность одного и того же программного
кода работать с разнотипными данными.
Он означает допустимость в
объектах разных типов иметь методы (процедуры или функции) с одинаковыми именами. Во время выполнения объектной программы одни и те же методы оперируют с разными объектами в зависимости от типа аргумента.