Моделирование сетевых структур с использованием вспомогательной таблицы. |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 24 - Жизненный цикл базы данных. Информационные хранилища – OLAP-технология.
Часть 25 - Хранимые процедуры. Языки для написания хранимых процедур.
Часть 26 - Моделирование сетевых структур с использованием вспомогательной таблицы.
Часть 27 - Основные функции СУБД. Типовая организация СУБД. Жизненный цикл базы данных.
Часть 28 - Кластерные и распределенные СУБД. Пример: IBM DB2 Parallel Edition, MS SQL Server и Oracle. Применение триггеров
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Хранимые процедуры. Языки для написания хранимых процедур. |
Хранимая процедура — объект базы данных, представляющий собой набор SQL-инструкций, который компилируется один раз и хранится на сервере. Хранимые процедуры очень похожи на обыкновенные процедуры языков высокого уровня, у них могут быть входные и выходные параметры и локальные переменные, в них могут производиться числовые вычисления и операции над символьными данными, результаты которых могут присваиваться переменным и параметрам. В хранимых процедурах могут выполняться стандартные операции с базами данных (как DDL, так и DML). Кроме того, в хранимых процедурах возможны циклы и ветвления, то есть в них могут использоваться инструкции управления потоком.
Реализация хранимых процедур (языки для написания).
Хранимые процедуры обычно создаются с помощью языка SQL или конкретной его реализации в выбранной СУБД. Например, для этих целей в СУБД Microsoft SQL Server существует язык Transact-SQL, в Oracle Database — PL/SQL, в Interbase и Firebird - PSQL, в PostgreSQL — PL/pgSQL, PL/Tcl, PL/Perl, PL/Python, в IBM DB/2 — SQL/PL и MySQL достаточно близко следует стандарту SQL:2003, её язык похож на SQL/PL. В некоторых СУБД возможно использование хранимых процедур, написанных на любом языке программирования, способном создавать независимые исполняемые файлы, например, на C++ или Delphi. В терминологии Microsoft SQL Server такие процедуры называются расширенными хранимыми процедурами и являются просто функциями, содержащимися в DLL Win32. А, например, в Interbase и Firebird для функций, вызываемых из DLL/SO, определено другое название - UDF (User Defined Function).
Назначение и преимущества хранимых процедур. Хранимые процедуры позволяют повысить производительность, расширяют возможности программирования и поддерживают функции безопасности данных. Вместо хранения часто используемого запроса, клиенты могут ссылаться на соответствующую хранимую процедуру. При вызове хранимой процедуры её содержимое сразу же обрабатывается сервером. Кроме собственно выполнения запроса, хранимые процедуры позволяют также производить вычисления и манипуляцию данными - изменение, удаление, выполнять DDL-операторы (не во всех СУБД!) и вызывать другие хранимые процедуры, выполнять сложную транзакционную логику. Один-единственный оператор позволяет вызвать сложный сценарий, который содержится в хранимой процедуре, что позволяет избежать пересылки через сеть сотен команд и, в особенности, необходимости передачи больших объёмов данных с клиента на сервер. В большинстве СУБД при первом запуске хранимой процедуры она компилируется (выполняется синтаксический анализ и генерируется план доступа к данным). В дальнейшем её обработка осуществляется быстрее. В СУБД Oracle выполняется интерпретация хранимого процедурного кода, сохраняемого в словаре данных. Начиная с версии Oracle 10g поддерживается так называемая естественная компиляция (native compilation) хранимого процедурного кода в Си и затем в объектный код целевой машины, после чего при вызове хранимой процедуры происходит прямое выполнение её скомпилированного объектного кода.
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 23 - Сжатие (упаковка) данных. Основы фракталов. Фрактальные методы в архивации
Часть 24 - Жизненный цикл базы данных. Информационные хранилища – OLAP-технология.
Часть 25 - Хранимые процедуры. Языки для написания хранимых процедур.
Часть 26 - Моделирование сетевых структур с использованием вспомогательной таблицы.
Часть 27 - Основные функции СУБД. Типовая организация СУБД. Жизненный цикл базы данных.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Жизненный цикл базы данных. Информационные хранилища – OLAP-технология. |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 22 - Моделирование сложных структур средствами реляционной СУБД. Рекурсивные деревья. Проблема образования петель.
Часть 23 - Сжатие (упаковка) данных. Основы фракталов. Фрактальные методы в архивации
Часть 24 - Жизненный цикл базы данных. Информационные хранилища – OLAP-технология.
Часть 25 - Хранимые процедуры. Языки для написания хранимых процедур.
Часть 26 - Моделирование сетевых структур с использованием вспомогательной таблицы.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Сжатие (упаковка) данных. Основы фракталов. Фрактальные методы в архивации |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 21 - Понятие транзакции. Средства реализации транзакций. Предложения COMMIT и ROLLBACK.
Часть 22 - Моделирование сложных структур средствами реляционной СУБД. Рекурсивные деревья. Проблема образования петель.
Часть 23 - Сжатие (упаковка) данных. Основы фракталов. Фрактальные методы в архивации
Часть 24 - Жизненный цикл базы данных. Информационные хранилища – OLAP-технология.
Часть 25 - Хранимые процедуры. Языки для написания хранимых процедур.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Моделирование сложных структур средствами реляционной СУБД. Рекурсивные деревья. Проблема образования петель. |
При построении информационных систем, приходится обеспечивать хранение в реляционной БД информации о «вложенных» друг в друга сущностях, т.е. иерархические данные. Классически проблема представления иерархий решается с помощью рекурсивной связи, что позволяет хранить в одной таблице дерево любой глубины и размерности.
Рекурсивные деревья. Наиболее общим случаем является дерево с неограниченным уровнем вложенности и неограниченным количеством потомков. Для хранения такого рода иерархии необходимо добавить в описание сущности дополнительное поле – ссылку на первичный ключ предка. (Т.е. в нашей таблице будет три столбца: ID – первичный ключ, Data – собственно данные(содержательная часть узлов дерева), Parent – ссылка на предка.) Такой способ организации иерархии является самым распространенным и универсальным. Однако ему присущи следующие недостатки: -необходимость рекурсивных запросов для получения полного пути от произвольного элемента до корня дерева; -cложность вычисления уровня вложенности произвольного элемента; -cложность получения всех (в том числе и не прямых) потомков данного узла. В данной структуре присутствует опасный недостаток – отсутствие контроля правильности ссылки на родителя. Если ссылки на родителя не верна может получиться петля, которая породит бесконечный цикл.
ПРЕИМУЩЕСТВА И НЕДОСТАТКИ РЕКУРСИВНОГО МЕТОДА
Быстрая вставка новых узлов, быстрое перемещение поддерева, быстрое(каскадное) удаление поддерева, кол-во уровней не ограничено, нет избыточности хранения, дополнительная поддержка целостности не нужна. Нет прямой выборки поддерева(всех потомков), всех предков, нет быстрого определения уровня и т.д.
2)Курсоры. DECLARE CURSOR, DROP CURSOR. Операции, требующие использования курсоров.
Запрос к реляционной базе данных обычно возвращает несколько рядов (записей) данных, но приложение за один раз обрабатывает лишь одну запись. Даже если оно имеет дело одновременно с несколькими рядами (например, выводит данные в форме электронных таблиц), их количество по-прежнему ограничено. Кроме того, при модификации, удалении или добавлении данных рабочей единицей является ряд. В этой ситуации на первый план выступает концепция курсора, и в таком контексте курсор – указатель на ряд.
Курсор в SQL – это область в памяти базы данных, которая предназначена для хранения последнего оператора SQL. Если текущий оператор – запрос к базе данных, в памяти сохраняется и строка данных запроса, называемая текущим значением, или текущей строкой курсора. Указанная область в памяти поименована и доступна для прикладных программ.
Обычно курсоры используются для выбора из базы данных некоторого подмножества хранимой в ней информации. В каждый момент времени прикладной программой может быть проверена одна строка курсора. Курсоры часто применяются в операторах SQL, встроенных в написанные на языках процедурного типа прикладные программы. Некоторые из них неявно создаются сервером базы данных, в то время как другие определяются программистами.
В соответствии со стандартом SQL при работе с курсорами можно выделить следующие основные действия: создание или объявление курсора; открытие курсора, т.е. наполнение его данными, которые сохраняются в многоуровневой памяти; выборка из курсора и изменение с его помощью строк данных; закрытие курсора, после чего он становится недоступным для пользовательских программ; освобождение курсора, т.е. удаление курсора как объекта, поскольку его закрытие необязательно освобождает ассоциированную с ним память. В разных реализациях определение курсора может иметь некоторые отличия. Так, например, иногда разработчик должен явным образом освободить выделяемую для курсора память. После освобождения курсора ассоциированная с ним память также освобождается. При этом становится возможным повторное использование его имени. В других реализациях при закрытии курсора освобождение памяти происходит неявным образом. Сразу после восстановления она становится доступной для других операций: открытие другого курсора и т.д. В некоторых случаях применение курсора неизбежно. Однако по возможности этого следует избегать и работать со стандартными командами обработки данных: SELECT, UPDATE, INSERT, DELETE. Помимо того, что курсоры не позволяют проводить операции изменения над всем объемом данных, скорость выполнения операций обработки данных посредством курсора заметно ниже, чем у стандартных средств SQL. Курсор перебирает строки. Курсор необходим для того, чтобы можно было работать с данными одной строки. Создание курсора (ORACLE).
DECLARE CURSOR c_american_pie AS SELECT Film_Title FROM Film_Table WHERE Film_Title like "American Pie%"; OPEN c_american_pie; LOOP
FETCH c_american_pie INTO v_film_title; EXIT WHEN c_american_pie%NOT_FOUND;
END LOOP; CLOSE c_american_pie;
Чтобы работать с курсором необходимо его открыть, надо выбрать значения с помощью этого курсора, когда значения закончатся мы должны выйти; Курсор не имеет смысла без объемлющего языка.
3)IBM eServer iSeries (AS/400) и OS/400 – пример архитектуры для создания высоконадёжных систем средней и малой ёмкости. Особенности организации управления памятью.
OS/400 — операционная система компании IBM. Была выпущена в 1988. C 2004 г. называется i5/OS. Представляет собой многопользовательскую операционную систему с вытесняющей многозадачностью. Характерными особенностями OS/400 являются: объектно-ориентированная архитектура, разрядность 64 бит; одноуровневая память (Single Level Storage); интегрированная СУБД DB2/400 (используется в качестве файловой системы). тесная интеграция с аппаратным обеспечением, не позволяющая устанавливать эту ОС на серверы иных производителей;
По мере того, как возникают все более сложные задачи, ИТ-профессионалам приходится обращаться к новым технологиям, чтобы обеспечить конкурентоспособность своих компаний. Для обеспечения гибкости и оперативности, эффективности и экономичности работы малых и крупных фирм в сферах традиционного и электронного бизнеса современные серверы должны обладать разнообразными возможностями, и прежде всего вычислительной мощностью, позволяющей обрабатывать огромные потоки транзакций. Эти компьютеры должны быстро реагировать на изменение внешних условий и допускать быстрое расширение с учетом новых требований. Значительные преимущества в этом случае обеспечивает тесная интеграция оборудования, операционной системы, базы данных, устройств ввода-вывода, промежуточного ПО и инструментальных средств. Основная концепция AS / 400 -- большое семейство мощных мини-компьютеров с единой архитектурой аппаратных и программных средств. Эти компьютеры представляют собой полностью законченные системы. Это означает, что все функции и возможности, обычно используемые в бизнесе, полностью интегрированы в операционную систему IBM Operating System/ 400 ( OS / 400 ). Аппаратная часть системы состоит из независимых блоков, которые взаимодействуют между собой посредством одной или нескольких системных шин. Весь ввод-вывод реализуется с помощью периферийных процессоров и не зависит от центрального процессора (полный аналог каналов ввода-вывода на мэйнфреймах).
Системы, построенные в такой архитектуре, по производительности обычно заметно превосходят компьютеры с общей шиной, в которых практически всеми действиями управляет центральный процессор. Так, в AS / 400 пропускная способность внутренних коммуникационных каналов по существу не ограничена. Перечисленные особенности архитектуры обеспечивают AS / 400 гибкость и позволяют адаптировать состав системы к условиям эксплуатации.
Концепция AS / 400 основана на нескольких фундаментальных принципах, таких как многоуровневая архитектура, объектная реализация, одноуровневая память и т. д. Необычность системы AS / 400 как машины состоит и в программном, и в аппаратном обеспечении. Команды, представляемые машинному интерфейсу, сперва подвергаются трансляции и только потом передаются аппаратным средствам. Эту трансляцию осуществляет так называемый лицензионный внутренний код (Licensed Internal Code, LIC). Другими словами, когда программа выдает машинному интерфейсу команды для выполнения, она "думает", что этот интерфейс и есть само системное оборудование. Характеристики аппаратных средств меняются с развитием технологии, однако с точки зрения пользователя машинный интерфейс остается прежним. От необходимости изменений его избавляет именно лицензионный внутренний код. В рамках платформы AS / 400 посредством копирования можно переносить программы, написанные и отлаженные на младшей модели, на все прочие компьютеры, вплоть до самого мощного. При этом перенесенная программа будет использовать все преимущества старшей модели, что достигается за счет компиляции исходных текстов не в конкретные команды процессора, а в команды независимого машинного интерфейса (Technology Independent Machine Interface, TIMI).
Все содержимое системы представлено в виде объектов. Тип и функциональность объекта определяются при его создании. Таким образом, объект сочетает в себе данные и допустимые методы его использования. Благодаря этому система может очень эффективно манипулировать объектами, определяя способ их использования в зависимости от типа объекта. Контроль допустимости действий над объектами осуществляется аппаратно. Эти особенности повышают общую целостность системы и ее данных. Вся память AS / 400 (как основная, так и дисковая) имеет единое адресное пространство. Единый, независимый от конкретного устройства механизм адресации позволяет не беспокоиться о месте расположения программы или о выделении и освобождении памяти для нее. Адресное пространство серверов AS / 400 огромно они могут адресовать весь диапазон, поддерживаемый 64-разрядной архитектурой.
Одноуровневая архитектура памяти обеспечивает еще одно чрезвычайно важное преимущество объектную персистентность (способность ПО создавать и поддерживать постоянные объекты). Персистентность означает, что объект продолжает существовать в одноуровневой памяти, если только он не удален пользователем намеренно. Система обеспечивает чрезвычайно быстрый доступ к памяти.
В традиционной машине для обобществления или долгосрочного хранения информации требуется, чтобы информация была сохранена в какой-либо конкретной файловой системе. Виртуальная адресация системы AS / 400 не зависит от физического размещения объекта, а также от типа, емкости и числа дисковых устройств системы. Это означает, что не нужно модифицировать прикладные программы для того, чтобы использовать преимущества новых технологий памяти.
Особенности архитектуры. Серверы iSeries и AS / 400 разработаны для выполнения бизнес-приложений. Одна из важнейших особенностей таких приложений - высокая интенсивность операций ввода-вывода, а не собственно вычислительных операций. Микропроцессоры, которые обслуживают специфическое устройство ввода-вывода, размещены на платах ввода-вывода, располагающихся в гнездах на системных шинах. Одна из таких плат может быть интегрированным сервером хSeries (сервер на базе Intel-архитектуры) для систем iSeries. Фактически это отдельный ПК на вставной плате, который позволяет серверу Windows NT работать на системе iSeries.
В настоящее время единая конфигурация большой системы на основе iSeries может содержать более 200 процессоров. Комплекс основного процессора системы (который объединяет до 24 отдельных процессоров) может получать запрос на считывании или запись данных в любое устройство ввода-вывода. Этот запрос делегируется специализированному микропроцессору, обслуживающему данное устройств ввода-вывода. Тем временем главный системный процессор продолжает выполнять другую прикладную программу.
Наличие независимых путей передачи данных дает значительный выигрыш в быстродействии системы в сравнении с предыдущими конструкциями с единой общедоступной шиной памяти, за доступ к которой боролись все компоненты системы.
"Горячее" подключение Возможность "горячего" подключения PCI-устройств была реализована во всех моделях iSeries серии 8xx и в некоторых моделях серии 270 с выходом в свет версии OS / 400 V4R5. Эта версия обеспечивает управление питанием для индивидуальных гнезд расширения, при этом PCI процессоры ввода-вывода или адаптеры ввода-вывода (IOA, Input Output Adapter) можно добавлять, удалять или заменять без изменения статуса активности системы. В большинстве случаев можно изменить конфигурацию адаптера ввода-вывода, оставив другие такие адаптеры в рабочем состоянии.
Логические разделы
Виртуальная консолидация нескольких машин на одном сервере может существенно повысить эффективность использования ресурсов при параллельных вычислениях, например, при выполнении бизнес-приложения одновременно с разработкой или тестированием новой системы или при обслуживании нескольких клиентов и т. п. Выделение логических разделов (LPAR, Logical PARtitioning) расширяет роль сервера iSeries как объединяющей системы.
Разделы имеют различные системные имена и могут работать с различными первичными или вторичными национальными языками, их можно настраивать на использование различных часовых поясов. Все системные параметры каждого раздела можно устанавливать независимо. Теперь для обслуживания раздела можно выделять дробную долю процессорных ресурсов.
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 20 - Общие понятия реляционного подхода к организации БД. Основные концепции и термины. Основные реляционные СУБД
Часть 21 - Понятие транзакции. Средства реализации транзакций. Предложения COMMIT и ROLLBACK.
Часть 22 - Моделирование сложных структур средствами реляционной СУБД. Рекурсивные деревья. Проблема образования петель.
Часть 23 - Сжатие (упаковка) данных. Основы фракталов. Фрактальные методы в архивации
Часть 24 - Жизненный цикл базы данных. Информационные хранилища – OLAP-технология.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Понятие транзакции. Средства реализации транзакций. Предложения COMMIT и ROLLBACK. |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 19 - Способы визуализации структур данных. ER-диаграммы.
Часть 20 - Общие понятия реляционного подхода к организации БД. Основные концепции и термины. Основные реляционные СУБД
Часть 21 - Понятие транзакции. Средства реализации транзакций. Предложения COMMIT и ROLLBACK.
Часть 22 - Моделирование сложных структур средствами реляционной СУБД. Рекурсивные деревья. Проблема образования петель.
Часть 23 - Сжатие (упаковка) данных. Основы фракталов. Фрактальные методы в архивации
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Общие понятия реляционного подхода к организации БД. Основные концепции и термины. Основные реляционные СУБД |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 18 - Триггеры в реляционных базах данных.
Часть 19 - Способы визуализации структур данных. ER-диаграммы.
Часть 20 - Общие понятия реляционного подхода к организации БД. Основные концепции и термины. Основные реляционные СУБД
Часть 21 - Понятие транзакции. Средства реализации транзакций. Предложения COMMIT и ROLLBACK.
Часть 22 - Моделирование сложных структур средствами реляционной СУБД. Рекурсивные деревья. Проблема образования петель.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Способы визуализации структур данных. ER-диаграммы. |
При помощи средств визуализации поддерживаются важные задачи бизнеса, среди которых - процесс принятия решений. В связи с этим возникает необходимость перехода средств визуализации на более качественный уровень, который характеризуется появлением абсолютно новых средств визуализации и взглядов на ее функции, а также развитием ряда тенденций в этой области. Большинство визуализаций данных построено на основе диаграмм стандартного типа (секторные диаграммы, графики рассеяния и.т.д.). Эти способы являются одновременно старейшими, наиболее элементарными и распространенными. В последние годы перечень видов диаграмм, поддерживаемых инструментальными средствами визуализации, существенно расширился. Поскольку потребности пользователей весьма многообразны, инструменты визуализации поддерживают самые различные типы диаграмм. Средства создания диаграмм и презентационной графики предназначены главным образом для визуализации данных. Однако возможности такой визуализации обычно встроены и во множество различных других программ и систем - в инструменты репортинга и OLAP, средства для Text Mining и Data Mining, а также в CRM-приложения и приложения для управления бизнесом. Для создания встроенной визуализации многие поставщики реализуют визуализационную функциональность в виде компонент, встраиваемых в различные инструменты, приложения, программы и web-страницы (в том числе инструментальные панели и персонализированные страницы порталов).
Повышение уровня взаимодействия с визуализацией пользователя. Еще совсем недавно большая часть средств визуализации представляла собой статичные диаграммы, предназначенные исключительно для просмотра. Сейчас широко используются динамические диаграммы, уже сами по себе являющиеся пользовательским интерфейсом, в котором пользователь может напрямую и интерактивно манипулировать визуализацией, подбирая новое представление информации. Например, базовое взаимодействие позволяет пользователю вращать диаграмму или изменять ее тип в поисках наиболее полного представления данных. Кроме того, пользователь может менять визуальные свойства - к примеру, шрифты, цвета и рамки. В визуализациях сложного типа (графиках рассеяния или диаграммах констелляции) пользователь может выбирать информационные точки с помощью мыши и перемещать их, облегчая тем самым понимание представления данных.
Более совершенные методы визуализации данных часто включают в себя диаграмму или любую другую визуализацию как составной уровень. Пользователь может углубляться (drill down) в визуализацию, исследуя подробности обобщенных ею данных, или углубляться в OLAP, Data Mining или другие сложные технологии. Сложное взаимодействие позволяет пользователю изменять визуализацию для нахождения альтернативных интерпретаций данных. Взаимодействие с визуализацией подразумевает минимальный по своей сложности пользовательский интерфейс, в котором пользователь может управлять представлением данных, просто "кликая" на элементы визуализации, перетаскивая и помещая представления объектов данных или выбирая пункты меню. Инструменты OLAP или Data Mining превращают непосредственное взаимодействие с визуализацией в один из этапов итерационного анализа данных. Средства Text Mining или управления документами придают такому непосредственному взаимодействию характер навигационного механизма, помогающего пользователю исследовать библиотеки документов.
Увеличение размеров и сложности структур данных, представляемых визуализацией. Элементарная секторная диаграмма или гистограмма визуализирует простые последовательности числовых информационных точек. Однако новые усовершенствованные типы диаграмм способны визуализировать тысячи таких точек и даже сложные структуры данных - например, нейронные сети. Скажем, средства OLAP (а также инструменты генерации запросов и выпуска отчетов) уже давно поддерживают диаграммы для своих онлайновых отчетов. Новые визуализационные программы обновляют контент за счет периодически повторяющегося считывания данных.
Пользователи инструментов Data Mining обычно анализируют очень большие наборы численных данных. Традиционные типы диаграмм для бизнеса (секторные диаграммы и гистограммы) плохо справляются с представлением тысяч информационных точек. Поэтому инструменты Data Mining почти всегда поддерживают некую форму визуализации данных, способную отражать структуры и закономерности исследуемых наборов данных, в соответствии с тем аналитическим подходом, который используется в инструменте.
Помимо того, что визуализация поддерживает обработку структурированных данных, она также является ключевым средством представления схем так называемых неструктурированных данных, например текстовых документов, т.е. Text Mining.
Выводы. Как показывают многие исследования, визуализация является одним из наиболее перспективных направлений анализа данных, в т.ч. Data Mining. Однако в этом направлении можно выделить проблемы, такие как сложность ориентации среди огромного количества инструментов, предлагающих решения по визуализации, а также непризнание рядом специалистов методов визуализации как полноценных средств анализа и навязывание им вспомогательной роли при использовании других методов. Однако у визуализации есть неоспоримые преимущества: она может служить источником информации для пользователя, не требуя теоретических знаний и специальных навыков работы, может выступить тем языком, который объединит профессионалов из различных проблемных областей, может превратить исходный набор данных в изображение, благодаря которому у исследователя могут появиться абсолютно новые, неожиданные решения. Диаграммы "сущность-связь" (ERD) предназначены для графического представления моделей данных разрабатываемой программной системы и предлагают набор стандартных обозначений для определения данных и отношений между ними. С помощью этого вида диаграмм можно описать отдельные компоненты концептуальной модели данных и совокупность взаимосвязей между ними. Основными понятиями данной нотации являются понятия сущности и связи. При этом под сущностью (entity) понимается произвольное множество реальных или абстрактных объектов, каждый из которых обладает одинаковыми свойствами и характеристиками. В этом случае любой рассматриваемый объект может быть экземпляром одной и только одной сущности, должен иметь уникальное имя или идентификатор, а также отличаться от других экземпляров данной сущности.
Связь (relationship) определяется как отношение или ассоциация между отдельными сущностями. Примерами связей могут являться родственные отношения, в частности "отец-сын" или производственные - "начальник-подчиненный". Другой тип связей задается отношениями "иметь в собственности" или "обладать свойством". Различные типы связей графически изображаются в форме ромба с соответствующим именем данной связи. Графическая модель данных строится таким образом, чтобы связи между отдельными сущностями отражали не только семантический характер соответствующего отношения, но и дополнительные аспекты обязательности связей, а также кратность участвующих в данных отношениях экземпляров сущностей. Нотация диаграмм (ERD) реализована в различных программных средствах. Пример диаграммы ERD, разработанной с помощью средства моделирования бизнес-процессов ARIS®. Ограниченность диаграмм ERD проявляется при конкретизации концептуальной модели в более детальное представление моделируемой программной системы, которое кроме статических связей должно содержать информацию о поведении или функционировании отдельных ее компонентов.
2)Представления. Определение представления. SQL предложения CREATE VIEW и DROP VIEW. Особенности операций выборки и обновления для представлений. Использование представлений для разграничения доступа к данным.
Специальные операторы языка SQL позволяют определять так называемые представления БД, фактически являющиеся хранимыми в БД запросами (результатом любого запроса к реляционной БД является таблица) с именованными столбцами. Для пользователя представление является такой же таблицей, как любая базовая таблица, хранимая в БД, но с помощью представлений можно ограничить или наоборот расширить видимость БД для конкретного пользователя. Поддержание представлений производится также на языковом уровне.
Предложения Sql Определение Данных:CREATE VIEW – создать представление
CREATE VIEW view_name AS SELECT column_name(s) FROM table_name WHERE condition DROP VIEW – удалить представление
Представление – это та же самая таблица, которая реально не существует (сохраненный внутри СУБД SELECT, которому приписано соответствующее имя; усеченная таблица). Доступ пользователям к таблицам осуществляется через представление. Существует два подхода: храним все, что можно, храним все, что нельзя вычислить
Представление позволяет объединить оба подхода. Прежде, чем работать с таблицей она должна выполнить SELECT. При создании представления необходимо разграничить права. Использование: 1.Управление данными, когда надо свести несколько таблиц вместе хорошо использовать представление, т.е. объединить таблицы. 2.разграничение доступа. Безопасность. Пользователь видит только предоставленные ему данные.
Предложения Grant И Revoke
GRANT {привилегии} ON {объекты} TO {пользователи} [ WITH ADMIN OPTION]
Привилегии для таблиц и представлений: SELECT UPDATE (может относиться к конкретным столбцам) DELETE INSERT ALL PRIVILEGES – все привилегии
Только для базовых таблиц: ALTER INDEX
Можно отдать права администратора на таблицу. В большинстве СУБД можно добавить привилегии на столбец, но обычно это целая таблица.
grant select on table s to u1805; grant select, update (city, person) on table s to u1805, mary, bob; grant all priveleges on table s, p, sp to boss; grant select on table p to public; revoke {привилегии} [on объекты] from {пользователи}
revoke select on table s from u1805; Отмена привилегии UPDATE не может относиться к конкретным столбцам
3)Архитектура IBM zArchitecture и IBM eServer zSeries (System/390) –архитектуры для построения централиз хранилищ данных большой ёмкости с нулевым временем простоя. Особенности архитектуры. Подсистема ввода/вывода.
IBM System z (более ранне название IBM eServer zSeries) — бренд созданный компанией IBM, для обозначения линейки мейнфреймов. Буква Z происходит от «zero down time», означающее нулевое время простоя, что отражает одно из главных качеств сервера — высочайшую надежность, позволяющую непрерывно поддерживать работу сервера на заданном уровне производительности по схеме 24 × 7 × 365 то есть 24 часа в сутки × 7 дней в неделю × 365 дней в году.
История В 2000 году компания IBM сменила название IBM System/390 на IBM eServer zSeries и уже в октябре 2000 была выпущена первая модель этого семейства zSeries 900.
Мейнфре́йм (от англ. mainframe) —Большая универсальная ЭВМ — высокопроизводительный компьютер со значительным объёмом оперативной и внешней памяти, предназначенный для организации централизованных хранилищ данных большой ёмкости и выполнения интенсивных вычислительных работ. Компьютер c архитектурой IBM System/360, 370, 390, zSeries. Современные мейнфреймы перестали быть закрытой платформой: они способны поддерживать на одной машине сотни серверов с различными ОС. Среднее время наработки на отказ оценивается в 12—15 лет. Надежность мейнфреймов — это результат почти 60-летнего их совершенствования. Группа разработки VM/ESA затратила двадцать лет на удаление ошибок из операционной системы, и в результате была создана система, которую можно использовать в самых ответственных случаях. Повышенная устойчивость систем. Мейнфреймы могут изолировать и исправлять большинство аппаратных и программных ошибок за счет использования следующих принципов. Дублирование: два резервных процессора, запасные микросхемы памяти, альтернативные пути доступа к периферийным устройствам. Горячая замена всех элементов вплоть до каналов, плат памяти и центральных процессоров.
Целостность данных. В мейнфреймах используется память, исправляющая ошибки. Ошибки не приводят к разрушению данных в памяти, или данных, ожидающих устройства ввода-вывода. Дисковые подсистемы построенные на основе RAID-массивов с горячей заменой и встроенных средств резервного копирования защищают от потерь данных. Рабочая нагрузка мейнфреймов может составлять 80—95 % от их пиковой производительности.
Пропускная способность подсистемы ввода-вывода мейнфреймов разработана так, чтобы работать в среде с высочайшей рабочей нагрузкой на ввод-вывод. Масштабирование может быть как вертикальным так и горизонтальным. Вертикальное масштабирование обеспечивается линейкой процессоров с производительностью от 5 до 200 MIPS и наращиванием до 12 центральных процессоров в одном компьютере. Горизонтальное масштабирование реализуется объединением ЭВМ в Sysplex (System Complex) — многомашинный кластер, выглядящий с точки зрения пользователя единым компьютером. Всего в Sysplex можно объединить до 32 машин. Географически распределенный Sysplex называют GeoPlex.
Доступ к данным. Поскольку данные хранятся на одном сервере, требуется небольшое количество физических серверов и значительно более простое программное обеспечение. Все это, в совокупности, ведет к повышению скорости и эффективности обработки. Защита. Встроенные в аппаратуру возможности защиты, такие как криптографические устройства, и Logical Partition, и средства защиты операционных систем, дополненные программными продуктами RACF или VM:SECURE, обеспечивают совершенную защиту. Пользовательский интерфейс всегда оставался наиболее слабым местом мейнфреймов. Сейчас же стало возможно для прикладных программ мейнфреймов, в кратчайшие сроки и при минимальных затратах, обеспечить современный интернет-интерфейс.
Для архитектуры типа выделенная память требуются аппаратные средства и ОС. Причем, процесс архивирования требует обычно дополнительного специального программного и аппаратного обеспечения. Архитектура этого типа применяется сейчас практически везде. Простейшим примером является файловый сервер. При применении такой архитектуры существует несколько проблем. Первой из них является перегруженность серверов при доступе к данным (даже не при их обработке). Вторая проблема заключается в том, что в настоящее время на мировом рынке присутствует множество систем управления устройствами хранения данных, базирующихся на разных технологиях (но построенных в соответствии с архитектурой типа выделенная память). Такое многообразие не способствует унификации и приводит к необходимости отдельного развития каждой такой системы. В третьих, вследствие необходимости передачи транзитных данных между серверами в сетях их работа становится неэффективной. Выполнение процедуры дополнительной обработки данных значительно снижает эффективность работы сервера и производительность работы компьютерных сетей.
Подсистема ввода / вывода является "козырной картой" мэйнфреймов. Сложная иерархия каналов и подканалов различного типа и назначения обеспечивает компьютерам этого класса возможность поддержки параллельного обмена с большим количеством разнотипных внешних устройств. К сожалению, за высокую эффективность указанной подсистемы приходится расплачиваться затратами не только на дополнительное оборудование каналов, но и на содержание громоздких периферийных устройств (дисков, лент, АЦПУ и т. д.). (далеко не все задачи, решаемые на платформе System / 390, оправдывают такие расходы).
В системе P/ 390 предусмотрено два способа выполнения процедур ввода / вывода, заимствованных у платформ System /370 и System / 390. В первом случае собственные внешние устройства мэйнфрейма подключаются к карте параллельного канала, устанавливаемой в разъем шины MCA. Таким образом с P/ 390 могут быть состыкованы практически все "большие" периферийные устройства, за исключением дисков. Достоинства подобного способа организации ввода / вывода очевидны: пользователям обеспечивается доступ ко всему арсеналу периферийных устройств мэйнфреймов.
Однако эти обширные возможности, предоставляемые картой параллельного канала, являются всего лишь дополнением альтернативного способа организации ввода/вывода в среде MVS/VM/VSE - с помощью эмуляции средствами подсистемы PC Server. Механизм эмуляции функций ввода/вывода System /370 или System/390 основан на перехвате ПК-сервером прерываний, формируемых подсистемой S/390 по командам инициализации канальных процедур SIO/SSCH.
Такая достаточно естественная схема отличается двумя весьма примечательными особенностями. С одной стороны, существование промежуточных драйверов Device Manager, выполняющих роль стыковочного модуля между стандартными средствами ввода/вывода среды MVS/VM/VSE и системы OS/2, позволяет IBM и ее партнерам постоянно расширять ассортимент эмулируемых периферийных устройств и оптимизировать процедуры ввода/вывода. Кроме того, при необходимости пользователи могут самостоятельно разработать необходимые драйверы для эмуляции нестандартных внешних устройств. С другой стороны, обеспечивается функционирование устройств ввода/вывода.
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 17 - 2)Предложение SELECT языка SQL. Объединение UNION. Квантор существования EXIST и NOT EXIST.
Часть 18 - Триггеры в реляционных базах данных.
Часть 19 - Способы визуализации структур данных. ER-диаграммы.
Часть 20 - Общие понятия реляционного подхода к организации БД. Основные концепции и термины. Основные реляционные СУБД
Часть 21 - Понятие транзакции. Средства реализации транзакций. Предложения COMMIT и ROLLBACK.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
Триггеры в реляционных базах данных. |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 16 - Гипертекст. Навигация, как способ доступа к данным. Web-интерфейсы к базам данных. XML и Web-службы (Web-Services).
Часть 17 - 2)Предложение SELECT языка SQL. Объединение UNION. Квантор существования EXIST и NOT EXIST.
Часть 18 - Триггеры в реляционных базах данных.
Часть 19 - Способы визуализации структур данных. ER-диаграммы.
Часть 20 - Общие понятия реляционного подхода к организации БД. Основные концепции и термины. Основные реляционные СУБД
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|
2)Предложение SELECT языка SQL. Объединение UNION. Квантор существования EXIST и NOT EXIST. |
Серия сообщений "Базы данных":
Часть 1 - Файловые системы. Назначение файловых систем.
Часть 2 - Особенности орган хранения данных
...
Часть 15 - Права доступа к базам данных и таблицам. Предложения GRANT и REVOKE. Метки доступа. Способ организации меток доступа для
Часть 16 - Гипертекст. Навигация, как способ доступа к данным. Web-интерфейсы к базам данных. XML и Web-службы (Web-Services).
Часть 17 - 2)Предложение SELECT языка SQL. Объединение UNION. Квантор существования EXIST и NOT EXIST.
Часть 18 - Триггеры в реляционных базах данных.
Часть 19 - Способы визуализации структур данных. ER-диаграммы.
...
Часть 43 - Метод вспомогательной таблицы для случая произвольного графа. Отличия от случая моделирования иерархий
Часть 44 - Объектно-ориентированная модель и реляционная модель. Сходство и отличия.
Часть 45 - Использование «координатного» метода для моделирования иерархий и произвольных графов. Его достоинства и
|