Социология. Моделирование данных hl. Системы управления базами данных
 Скачать 0.68 Mb.
|
|
Код_клиента Фамилия Имя Отчество Паспорт Страна Город Адрес Кредит Примечание Товары Код_товара Наим_товара Код_категории Цена 1 ∞ Заказы Код_заказа Код_клиента Код_товара Дата_заказа Количество Полная_цена Прим_заказ 1 Телефоны Телефон Код_клиента Категории Код_категории Категория Размещение 1 ∞ ∞ ∞ A B C атрибута С. Такая взаимозависимость требует дальнейшей декомпозиции таблицы. 2.4.5. Нормальные формы более высоких порядков Четвертая нормальная форма устраняет нетривиальные многозначные зависимости. Если таблица содержит два и более никак не связанных между собой многозначных атрибута, то по требованиям первой нормальной формы нам потребуется записать по отдельной записи для каждого значения каждого многозначного атрибута. Общее число записей будет равно числу сочетаний значений, принимаемыми многозначными атрибутами, и может быть очень большим. Легко увидеть, что часть информации будет повторяться. Следовательно, для уменьшения избыточности информации и устранения возможности появления несогласованного состояния данных необходимо прибегнуть к дальнейшей декомпозиции отношения. Пятая нормальная форма основывается на концепции устранения зависимостей объединения. Может быть ситуация, когда нельзя разбить таблицу на две таким образом, чтобы получить после объединения исходный результат (некоторые записи могут быть потеряны или наоборот, могут появиться подложные записи). Но при этом существует ситуация, что такую таблицу можно разбить на три и более таблиц при выполнении всех привил нормализации. На практике этот вид зависимости очень трудно обнаружить и, следовательно, устранить. 2.4.6. Правила нормализации Резюмируя вышесказанное, сформулируем несколько правил, которых следует придерживаться при нормализации таблиц: 1. Разрабатывайте схему данных таким образом, чтобы можно было бы легко объяснить ее, т.е. не комбинируйте атрибуты независимых объектов и не создавайте сложные связи; 2. Разрабатывайте схему данных таким образом, чтобы исключить возможность появления аномалий обновления; 3. Разрабатывайте схему данных таким образом, чтобы в связях участвовали только первичные (можно допустить потенциальные) и внешние ключи. Это позволит избежать появления подложных записей; Требование, чтобы все таблицы были нормализованы, не является обязательным. В нашем случае вполне можно было бы обойтись без таблицы «Телефоны». В заключение сформулируем определение реляционной базы данных как совокупность нормализованных отношений. 30 2.4.7. Выводы Резюмирую вышесказанное, выделим основные свойства реляционной модели, выделяющие ее из остальных моделей данных: a) Основной единицей обработки данных является отношение. Данные хранятся в связанных отношениях, любая выборка из БД представляет собой отношение, пусть она даже будет единственным числом; b) Данные представляются одним и только одним способом, а именно явными скалярными значениями. Даже связи задаются явными значениями, а не указателями; c) Нет указателей на отдельные строки таблицы. Строка идентифицируется по явному значению ключевого поля. Ключи играют огромную роль в реляционных БД и используются для достижения следующих целей: 1. исключения дублирования кортежей и, как следствие, адресации кортежей; 2. организации связывания отношений. Достоинства реляционной модели заключаются в следующем: 1. Простота. Использование таблиц очень наглядно и легко постигаемо; 2. Гибкость. Один и тот же набор данных можно представить различными способами; 3. Точность. Действия с данными основаны на точных математических операциях; 4. Связность. Реляционное преставление дает ясную картину связей; 5. Логическая независимость данных. Можно добавлять новые таблицы, поля, и связи, не разрушая старых. Можно удалять таблицы, связи и поля, не участвующие в связи и не являющиеся ключевыми. Среди недостатков можно выделить следующие: 1. Однородная структура данных, и как следствие, невозможность хранения объектов со сложной структурой в одном кортеже отношения. Для хранения таких объектов приходится выделять несколько связанных отношений, что приводит к потере реальности восприятия сохраненных объектов; 2. Отсутствие стандартных средств идентификации отдельных записей и, как следствие, возможность повторного добавления одного и того же объекта; 3. Запрещение многозначных и составных полей; 4. Сложность описания рекурсивных, иерархических и сетевых связей; 31 5. Фиксированный и ограниченный набор операций (нет возможности определения новых операций. Примерами реляционных СУБД для ПЭВМ являются следующие: Paradox (Borland) и Access (Microsoft), DB2 (IBM), MS SQL Server (Microsoft), Ingres (ASK Computer Systems) и Oracle (Oracle). Первым коммерческим продуктом стал Oracle (Oracle) в 1978 году. 2.5. Постреляционная модель Классическая реляционная модель предполагает неделимость данных, хранящихся в полях записей таблиц. Существует ряд случаев, когда это ограничение мешает эффективной реализации приложений. Постреляционная модель данных представляет собой расширенную реляционную модель, снимающую ограничение неделимости данных, хранящихся в ячейках таблицы. Поскольку атомарность данных постулируется первой нормальной формой, то исходя из этого определения, ее называют также Non-First Normal Form (NFNF или NF 2 ) реляционной моделью. Постреляционная модель данных допускает многозначные и составные поля. Набор значений многозначных полей считается самостоятельной таблицей, встроенной в основную таблицу. Вследствие этого ее еще часто называют вложенной (Nested) реляционной моделью. Все атрибуты в постреляционной модели рассматриваются как составные, имеющие иерархическую структуру, причем на количество ветвей не накладывается каких либо ограничений. Это позволяет на одном уровне иерархии хранить целые массивы данных, как показано ниже в таблице. По сравнению с реляционной в постреляционной модели данные хранятся более эффективно, а при обработке не требуется выполнять операцию соединения данных из двух и более таблиц. Помимо обеспечения вложенности полей постреляционная модель поддерживает ассоциированные многозначные поля (множественные группы). Совокупность ассоциированных полей называется ассоциацией. При этом в некоторой строке первое значение одного столбца ассоциации соответствует первым значениям всех остальных столбцов ассоциации. Аналогичным образом связаны все вторые значения столбцов и т. д. На ID Имя Адрес Тел Фамилия Имя Отчество Страна Город Доп. адрес Улица Д. Кв. Номер Тип 1 Сидоров Петр Петрович Беларусь Минск Ландера 6 67 2786544 Дом. Коржа 33 23 2367678 Раб. 6257533 Моб. 2 Иванов Иван Иванович Беларусь Гродно Ленина 23 12 244466 Дом. Литва Вильнюс Лесная 43 65 567543 Дом. 32 длину полей и количество полей в записях таблицы не накладывается требование постоянства. Это означает, что структура данных и таблиц имеют большую гибкость. Но поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается с помощью процедур, автоматически выполняемых до или после обращения к данным. Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки. Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных. Эта модель пока не реализована в полном объеме в коммерческих СУБД. Примером использования некоторых концепций этой модели может служить Oracle 8. В этой СУБД реализована поддержка составных и многозначных атрибутов, а также вложенных таблиц (Nested Tables). Для хранения составных атрибутов в Oracle 8 используется тип данных OBJECT. Например, составной атрибут «Телефон» описывается так: CREATE TYPE Tel_Type AS OBJECT(Tel_Number CHAR(10), Tel_Descr CHAR(5)); Для хранения многозначных атрибутов в Oracle 8 используется тип данных VARRAY, представляющий собой массив некоторых объектов переменной длинны, имеющий два свойства: (1) Count – число элементов в массиве и (2) Limit – максимальное число элементов в массиве (задается при определении этого типа). Для формирования массива объектов вначале требуется определить тип объектов, которые будут храниться в массиве, например: CREATE TYPE Tel_Type AS OBJECT(Tel_Number CHAR(15), Tel_Descr CHAR(5)); Затем необходимо определить тип массива, указав его максимальную размерность: CREATE TYPE Tel_List_Type AS VARRAY(5) OF Tel_Type; Этот же набор данных можно определить и как вложенную таблицу: CREATE TYPE Tel_List_Type AS TABLE OF Tel_Type; Оба объекта VARRAY и TABLE имеют похожие свойства, но имеют и существенные различия. Во первых, тип VARRAY имеет верхний предел число элементов, а TABLE – не имеет. Во вторых, во вложенных таблицах можно обращаться к отдельным ее элементам и дополнительно определять индексы, что не допустимо в VARRAY. 33 2.6. Многомерная модель Многомерный подход к представлению данных в базе появился практически одновременно с реляционным, но реально работающих многомерных СУБД (МСУБД) до недавнего времени было очень мало. С середины 90-х годов с развитием систем OLAP (On Line Analytical Processing — оперативная аналитическая обработка данных), Data Warehousing (хранилища данных) и Data Mining (добыча данных), применяющихся для сложного анализа данных, принятия решений, менеджмента и получения новых знаний, интерес к ним стал приобретать массовый характер. Основное назначение OLAP систем заключается в динамическом синтезе, анализе и консолидации больших объемов многомерных данных, а это, в свою очередь, связано с необходимостью извлекать большое количество записей из больших БД и производить их оперативную обработку (например, быстро вычислять итоговые значения). Если дать самую краткую характеристику Data Warehousing, то ее можно определить как предметно (проблемно) ориентированную, интегрированную, постоянную в структуре, но зависящую от времени совокупность данных, предназначенных для принятия некоторых решений. Главное отличие от стандартных баз данных состоит в том, что оно представляется собранием данных из многих баз данных, объединенных вместе для решения какой-либо частной задачи, либо является построенной по определенным правилам выдержкой из очень большой базы данных. Существенным отличием можно считать также отсутствие операций обновления данных. Data Mining также является системой, хотя и основанной на данных, до весьма далекую от целей хранения данных. Ее главная цель состоит в исследовании данных с целью получения новых знаний, т.е. для сложного анализа данных, как например, поиск цепочек ДНК и т. д. Data Mining преследует следующие цели: • предсказание (например, прогноз погоды); • идентификация (по образцу, …); • классификация; • оптимизация (создание более оптимально действующих систем на основе анализа уже существующих). Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации. Многомерность модели данных в них означает не многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными. При этом зачастую создается только 34 многомерное логическое представление данных, а не их хранение. Т.е. сами данные могут храниться в больших БД, например, реляционных, а в требуемый момент времени извлекаться оттуда. Обычно в этом случае доступ производится с помощью многомерных индексов. Поскольку многомерные модели предназначены в основном для аналитической обработки данных, а не для создания удобных хранилищ информации, основной задачей в них является операциями консолидации, т.е. расчет всех промежуточных и основных итоговых значений, причем по всем размерностям. Это позволяет в много раз уменьшить объем представляемой информации и значительно ускорить доступ к данным и их последующую обработку. Такое предварительное обобщение является особенно ценным при работе с иерархически связанной информацией, например, при работе с данными, зависящими от времени. По сравнению с реляционной моделью многомерная модель данных обладает более высокой скоростью доступа к данным, наглядностью и информатив- ностью. Для сравнения ниже приведены реляционное (таблица 1) и многомерное (таблица 2 и рис. 11) представления одних и тех же данных о продаже товаров: Таблица 1 Клиент Товар Цена Количество Дата Иванов Масло 1000,00 1 02.02.2005 Петров Молоко 400,00 2 02.02.2005 Иванов Сметана 750,00 2 06.02.2005 Иванов Масло 1000,00 1 22.02.2005 Петров Молоко 400,00 3 03.03.2005 Сидоров Масло 1000,00 2 02.03.2005 Иванов Сметана 1500,00 2 12.03.2005 Иванов Молоко 500,00 1 05.04.2005 Сидоров Сметана 800,00 3 14.04.2005 Петров Масло 1200,00 2 28.04.2005 Таблица 2 Дата Товар Июнь 2005 Июль 2005 Август 2005 Масло 2000 2000 2400 Молоко 800 1200 500 Сметана 1500 3000 2400 35 Рис 11. Пример трехмерной модели Если размерностей всего две (таблица 2), то такое представление называется перекрестной или сводной таблицей. Объем продаж вычисляется на основе группированного представления продаж по товарам, клиентам и месяцам. На рис. 11 показан пример трехмерной модели данных, где введена еще одна размерность Клиент. Если число размерностей велико, то информация не обязательно должна представляется визуально в виде многомерных объектов (n-мерных гиперкубов), тем более, что это не представляется возможным. Пользователь привык иметь дело с двумерными таблицами, диаграммами, графиками. Многомерная модель как раз предоставляет расширенный набор средств для выборки данных из многомерного хранилища данных, выполненных с разной степенью детализации. Основными понятиями многомерных моделей являются измерение и ячейка, а операциями – консолидация, срез, вращение, агрегация и детализация: Измерение (Dimension) – это множество однотипных данных, образующих одну из граней гиперкуба. В многомерной модели данных измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба; Ячейка (Cell) или показатель – это поле, значение которого однозначно определяется фиксированным набором измерений. В зависимости от того, как формируются значения некоторой ячейки, обычно она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам); Консолидация включает в себя простые обобщающие операции типа расчета итоговых значений, матричную арифметику, а также расчет сложных выражений; Срез (Slice) представляет собой подмножество гиперкуба, полученное в результате фиксации одного или нескольких измерений. Формирование среза выполняется для ограничения выборки данных, поскольку все значения гиперкуба очень трудно представить визуально. Вращение (Rotate) заключается в изменении порядка измерений при визуальном представлении данных. Агрегация (Drill Up) и Детализация (Drill Down) означают соответственно переход к более общему и к более детальному представлению информации пользователю из гиперкуба. Например, в БД хранится информация о дате продажи товара. Тогда с помощью операции детализации можно уточнить момент продажи, а с помощью операции агрегации представить суммарную информацию по месяцам, кварталам и годам. 36 Основным достоинством многомерной модели данных является удобство и эффективность аналитической обработки больших объемов данных, связанных со временем. При организации обработки аналогичных данных на основе реляционной модели происходит нелинейный рост трудоемкости операций в зависимости от размерности БД и существенное увеличение затрат оперативной памяти на индексацию. Недостатком многомерной модели данных является ее громоздкость для простейших задач обычной оперативной обработки информации. Примерами систем, поддерживающими многомерные модели данных, являются Essbase (Arbor Software), Media Multi-matrix (Speedware), Oracle Express Server (Oracle), Cache (Inter Systems). В последней СУБД, основанной на многомерной модели данных, реализованы три способа доступа к данным: прямой (на уровне узлов многомерных массивов), объектный и реляционный. 2.7. Объектно-ориентированная модель Основное назначение объектно-ориентированных БД (ООБД) состоит в длительном хранении структур данных и объектов программ. Эта задача появилась очень давно, так как для достаточно большой программы фактически всегда актуальной задачей являлось сохранение и восстановление промежуточных результатов работы. Обычно для этой цели использовались файлы и потоковый ввод-вывод. Но в этом случае главный недостаток файловой системы хранения данных, заключающийся в невозможности использования сохраненных данных другими программами, являлся серьезным препятствием при разработке больших программных комплексов, состоящих из многих взаимодействующих приложений. Приходилось для каждой программы писать специальные конверторы объектов в формат, пригодный для совместного хранения и общего использования. И наоборот, чтение данных в программу подразумевало написание конвертора сохраненных в файле объектов обратно в переменные оперативной памяти компьютера. С появлением баз данных для хранения общих данных стали использовать технологию баз данных. Но это не решило проблемы, так как приходилось конвертировать объекты в формат БД и наоборот. По разным оценкам, на это уходило до 30% времени выполнения программы. Успех объектно-ориентированного стиля программирования (ООП), наращивание объема программ, необходимость создания очень сложных программных комплексов, состоящих из многих компонентов, привело к созданию стандартов совместного хранения и использования объектов, что в свою очередь, привело к созданию объектно-ориентированной модели данных (ООМД). С другой стороны, оказалось очень удобным использовать 37 классы как определенные пользователем инкапсулированные типы объектов произвольной внутренней сложности для хранения данных. При этом подходе появилась возможность представления и реализации сложных моделей данных, так как не было необходимости учитывать многочисленные ограничения, накладываемые моделью данных, например, требование атомарности атрибутов в реляционной модели. Несомненным достоинством ООМД является также способность к хранению объектов произвольной сложности, отражающих сложность реальных объектов. Для хранения подобного объекта в реляционной БД потребовалось бы множество записей в нескольких таблицах, что привело бы к потере соответствия между реальным объектом и сохраненным. ООБД преимущественно используются вместе с объектно- ориентированными программами и служат для длительного хранения их объектов. Такие программы специально разрабатываются для совместной работы с ООБД. В обычных объектно-ориентированных программах объекты существуют в оперативной памяти компьютера в течение времени выполнения программы и соответственно называются временными. ООБД расширяют время существования объектов так, чтобы они были доступными длительное время и после завершения работы программы. Другими словами, ООБД позволяет сохранять области оперативной памяти, представляющие собой копии объектов, во внешней памяти. С другой стороны ООБД обеспечивает возможность восстановления сохраненных объектов в оперативной памяти и обеспечение доступа к ним другим программам. Такая возможность длительного хранения объектов требует включения механизмов поиска, индексации, обеспечения целостности и безопасности информации, принятые в базах данных. Структура ООМД графически представима в виде дерева, узлами которого являются объекты, а соединительные линии предоставляют связи объектов. Говорить о строгой иерархической структуре нельзя, так как объекты могут наследовать свойства нескольких базовых объектов. Несмотря на внешнюю схожесть логической структуры, ООМД коренным образом отличается от иерархической модели. Основное отличие состоит в методах обработки данных. Для моделирования объектно-ориентированных систем разработан язык моделирования UML (Universal Modeling Language), который можно определить как промышленный объектно-ориентированный стандарт моделирования. С помощью построителя диаграмм классов этого языка можно визуально разрабатывать (и представлять) объектно- ориентированные приложения, в том числе БД. 38 |