Ответы на экзамен
.docx
13. Понятие модели представления данных. Сетевая модель данных. Хранимые в базе данные имеют определенную логическую структуру, которая описывается некоторой моделью представления данных или моделью данных, поддерживаемой СУБД Сетевая БД состоит из набора записей и набора соответствующих связей. На формирование связи особых ограничений не накладывается. Если в иерархических структурах запись-потомок могла иметь только одну запись-предка,то в сетевой модели данных запись-потомок может иметь произвольное число записей-предков (сводных родителей). Пример схемы простейшей сетевой БД показан на рис Типы связей здесь обозначены надписями на соединяющих типы записей линиях.
В различных СУБД сетевого типа для обозначения одинаковых по сути понятий зачастую используются различные термины. Например, такие как элементы и агрегаты данных, записи, наборы, области и т. д. (см. п. 1.1.3). Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах данных. К числу важнейших операций манипулирования данными баз сетевого типа можно отнести следующие: -поиск записи в БД; -переход от предка к первому потомку; -переход от потомка к предку; -создание новой записи; -удаление текущей записи; -обновление текущей записи; -включение записи в связь; -исключение записи из связи; -изменение связей и т. д. Достоинством сетевой модели данных является возможность эффективной реализации по показателям затрат памяти и оперативности. В сравнении с иерархической моделью сетевая модель предоставляет большие возможности в смысле допустимости образования произвольных связей. Недостатком сетевой модели данных является высокая сложность ижесткость схемы БД, построенной на ее основе, а также сложность для понимания и выполнения обработки информации в БД обычным пользователем. Кроме того, в сетевой модели данных ослаблен контрольцелостности связей вследствие допустимости установления произвольных связей между записями. 14. Понятие модели представления данных. Реляционная модель данных. Хранимые в базе данные имеют определенную логическую структуру, которая описывается некоторой моделью представления данных или моделью данных, поддерживаемой СУБД. Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии «отношение» (relation)=таблица=сущность. Отношение представляет собой множество наборов элементов, называемых кортежами. Подробно теоретическая основа реляционной модели данных рассматривается в следующем разделе. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица. Структура таблицы: строки (записи) столбцы (колонки). каждая строка (запись) таблицы имеет одинаковую структуру и состоит из полей. строкам таблицы соответствуют кортежи столбцам — атрибуты отношения (имена полей). С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество под объектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и образование. Поскольку в рамках одной таблицы не удается описать более сложные логические структуры данных из предметной области, применяют связывание таблиц. Физическое размещение данных в реляционных базах На внешних носителях легко осуществляется с помощью обычных файлов. Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми. Основными недостатками реляционной модели являются:отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Таблица – соответствие элементов
18. Типология моделей Ключевым этапом при разработке любой информационной системы является проведение системного анализа: формализация предметной области и представление системы как совокупности компонент. Системный анализ позволяет, с одной стороны, лучше понять «что надо делать» и «кому надо делать» (аналитику, разработчику, руководителю, пользователю), а с другой – отслеживать во времени изменения рассматриваемой модели и обновлять проект. Декомпозиция как основа системного анализа может быть функциональной (построение иерархий функций) или объектной. Однако в большинстве систем, если говорить, например, о базах данных, типы данных являются более статичным элементом, чем способы их обработки. Поэтому получили интенсивное развитие такие методы системного анализа, как диаграммы потоков данных (Data Flow Diagram). Развитие реляционных баз данных в свою очередь стимулировало развитие методик построения моделей данных, и в частности, ER-диаграмм. Однако и функциональная декомпозиция и диаграммы потоков данных дают только некоторый срез исследуемой предметной области, но не позволяют получить представление системы в целом. Различаются и методы отображения, используемые на этапе построения даталогических моделей, отражающих способ идентификации элементов и связей, но, что особенно важно – в контексте их будущего представления в одномерном пространстве памяти вычислительной машины. Модели подразделяются на фактографические – ориентированные на представление хорошо структурированной информации, и документальные – представляющие наиболее распространенный способ отражения слабоструктурированной информации. Если в первом случае говорят о реляционной, иерархической или сетевой моделях данных, то во втором – о семантических сетях и документальных моделях. При проектировании информационных систем свойства объектов (их характеристики) называются атрибутами. Именно значения атрибутов позволяют выделить как в предметной области различные объекты (типы объектов), так и среди объектов одного типа – их различные экземпляры. Представление атрибутов удобнее всего моделируется теоретико-множественными отношениями. Отношение наглядно представляется как таблица, где каждая строка – кортеж отношения, а каждый столбец (домен) представляет множество значений атрибута. Список имен атрибутов отношения образует схему отношения, а совокупность схем отношений, используемых для представления БД, в свою очередь образует схему базы данных. Представление схем БД в виде схем отношений упрощает процедуру проектирования БД. Этим объясняется создание систем, в которых проектирование БД ведется в терминах реляционной модели данных, а работа с БД поддерживается СУБД одного из упомянутых ранее типов.
15. Понятие модели представления данных. Постреляционная модель данных. Хранимые в базе данные имеют определенную логическую структуру, которая описывается некоторой моделью представления данных или моделью данных, поддерживаемой СУБД. Реляционные системы ограничены в структурах представления данных, так как все данные хранятся в них в виде отношений, состоящих из простых атрибутов. Классическая реляционная модель предполагает неделимость данных, хранящихся в полях таблицы, то есть информация в таблице должна быть представлена в первой нормальной форме. Однако на практике иногда возникают ситуации, когда такое ограничение снижает эффективность работы с базой. Данные в реляционной системе пассивны, и для описания их поведения требуется создавать прикладные программы. Возможности реляционных баз данных недостаточны в тех случаях, когда объекты данных сложны, например: географические информационные системы, мультимедийные базы, базы с проектной документацией и др. Все эти требования можно реализовать с помощью реляционных методов, но в результате получается не очень естественное представление требований пользователя. Постреляционная модель является расширением реляционной модели. Она снимает ограничение неделимости данных, допуская многозначные поля, значения которых состоят из подзначений, и набор значений воспринимается как самостоятельная таблица, встроенная в главную таблицу. Сопоставим реляционную и постреляционную модели данных на примере. В таблицах 7 и 8 отражена поставка товара в реляционной базе, а в таблице 9 – в постреляционной. Как видно из приведенного примера, в постреляционной базе данные хранятся более компактно, и не требуется выполнять операции связи двух таблиц. Такое хранение обеспечивает высокую наглядность представления данных и повышение эффективности их обработки.
Спецификой постреляционной модели является то, что она поддерживает множественные группы, называемые ассоциированными множественными полями, а совокупность объединенных множественных полей называется ассоциацией, например, в постреляционной модели может присутствовать множественное поле Выпуск, состоящее из полей, указывающих выпуск по кварталам года. В постреляционной модели не накладываются требования на длину и количество полей в записях, что делает структуру таблиц более наглядной. Достоинством постреляционной модели является возможность представления совокупности связанных таблиц одной постреляционной таблицей. Это обеспечивает высокую наглядность представления информации и повышение эффективности ее обработки. Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных. 20. Проектирование реляционной базы данных. Разработка эффективной базы данных состоит из нескольких этапов. Процесс разработки БД начинается с анализа требований. Проектировщик на этом этапе разработки должен найти ответы на следующие вопросы: какие элементы данных должны храниться, кто и как будет к ним обращаться. На втором этапе создается логическая структура БД. Для этого определяют, как данные будут сгруппированы логически. Структура БД на этом этапе выражается в терминах прикладных объектов и отношений между ними. На заключительном (третьем) этапе логическая структура БД преобразуется в физическую с учетом аспектов производительности. Элементы данных на этом этапе получают атрибуты и определяются как столбцы в таблицах выбранной для реализации БД СУБД. Проектирование баз данных информационных систем является достаточно трудоемкой задачей. Оно осуществляется на основе формализации структуры и процессов предметной области, сведения о которой предполагается хранить в БД. Различают концептуальное и схемно-структурное проектирование. Требования: 1 БД состоит из набора связанных таблиц, обеспечивает хранение информации и быстрый доступ к данным. 2 БД представляет собой совокупность данных различного характера, т.е. данные имеют различную физическую природу. 3 Информация в БД должна быть: - не противоречивой(устранение избыточности, контроль над ней) - не избыточной(исключение одного и того же элемента информации, полностью исключить избыточность информации невозможно) - целостной(корректность и непротиворечивость хранимых данных) Методы контроля целостности: 1)при вводе новых данных 2)при модификации записей 3)при удалении записей Важнейшие ограничения целостности данных: 1)категориальная целостность, т.е никакой атрибут первичного ключа не может быть пустым 2)ссылочная целостность(необходимое качество реляционной базы данных, заключающееся в отсутствии в любом её отношении внешних ключей, ссылающихся на несуществующие кортежи) Элементы реляционной моделиФормы представления отношениетаблица схема отношенийстрока заголовков столбцов таблицы кортежстрока таблицы атрибутзаголовок столбцов таблицы доменмножество допустимых значений атрибутов значение атрибутазначение поля записи первичный ключодин или несколько атрибутов тип данныхтип значений элементов таблицы Таблица должна иметь хотя бы одно поле и включать в себя следующие понятия: -описание ключевых полей -описание других, т.е. неключевых полей -индексы -ограничения ссылочной целостности между таблицами -организация защиты данных
21. Связывание таблиц в реляционной БД После создания различных таблиц, содержащих данные, относящиеся к различным аспектам базы данных, необходимо обеспечить целостность базы данных. Связывание таблиц обеспечивает: - Контроль целостности (повышает достоверность информации); - Обеспечение доступа к данным. Основные виды связи:
При связывании таблиц определяют основную и дополнительную (подчиненную). Логическая связь обеспечивается с помощью ключа связи. В состав ключа связи может быть одно поле и сост, которое называют полями связи. Существует четыре типа связей: Один к одному (1:1); Один ко многим (1: M); Многие ко многим (M:N). Один к одному: Связь один-к-одному предполагает, что одному атрибуту первой таблицы соответствует только один атрибут второй таблицы и наоборот. Пример: паспорт выдается одному лицу. Данный тип связи применяется достаточно редко, т к подобно хранимую информацию можно объединить в одну таблицу, которая занимает меньше информации в ЭВМ. Один ко многим: Самый распространенный тип связи в БД. Связь один-ко-многим предполагает, что одному атрибуту первой таблицы соответствует несколько атрибутов второй таблицы. Многие ко многим: Связь многие-ко-многим предполагает, что одному атрибуту первой таблицы соответствует несколько атрибутов второй таблицы и наоборот. Пример: В стоматологической клинике работает много врачей. Каждый из них могут оказывать много услуг. Связи с отношениями "один ко многим" и "многие к одному" отличаются только тем, какая таблица является главной. Одному сотруднику в таблице "Персональные мероприятия" может соответствовать несколько записей. Поэтому между таблицей "Сотрудники" и таблицей "Персональные мероприятия" нужно установить связь с отношением "один ко многим". Создание связи между таблицами "Сотрудники" и "Персональные мероприятия" позволит использовать запросы, формы и отчеты, в которых выводятся данные из нескольких таблиц сразу. Связанные поля не обязательно должны иметь одинаковые имена, однако, они должны иметь одинаковые типы данных. Кроме того, связываемые поля типа "Числовой" должны иметь одинаковые значения свойства "Размер поля". Например, нельзя создать связь между полями типа "Счетчик" и "Байт" или "Целое" и "Денежный". Исключением из этого правила является поле счетчика с последовательной нумерацией, которое может связываться с числовыми полями размера "Длинное целое". В нашем примере связь между таблицами осуществляется по полям с типами данных "Счетчик" и "Длинное целое". 22. Понятие нормализации БД Проектирование БД – один из жизненных этапов цикла. Основная задача, решаемая в процессе проектирования БД – задача нормализации ее отношений. Классический метод проектирования РБД – это метод нормальных форм. Он основан на функциональном в теории реляционной БД понятии зависимости между атрибутами отношений (функциональные, транзитивные, многозначные). Нормализация – это процесс сокращения, повторений в БД. Цель нормализации: разработка хорошо организованной и логической модели БД до начала ее физической реализации.
Для 1 НФ характерно отсутствие повторяющихся групп или множеств столбцов значений. Для 2 НФ характерна ситуация, когда неключевое поле зависит от первичного ключа. Для № НФ характерна ситуация, когда ставится условие того, что неключевое поле не может зависеть от одного неключевого поля. Нормализация таблиц БД осуществляется для уменьшения избыточности информации. Процесс проектирования БД с использованием метода нормальных форм явл. итерационным. Итерациональный заключается в последовательном переводе отношений из 1 НФ в нормальные формы более высоких порядков по определенным правилам. Каждая следующая нормальная форма ограничивает определенный тип функциональных зависимостей, устраняет соответствующие аномалии при выполнении операции над отношениями БД и сохраняет свойства предшествующих нормальных форм. Преимущества нормализации:
Недостаток:
27. Даталогическое проектирование Задачей следующей стадии проектирования системы базы данных является выбор подходящей СУБД и отображение в ее среду (структуру данных) спецификаций инфологической модели предметной области. Другими словами, модель предметной области разрабатываемой системы должна быть представлена в терминах модели данных концептуального уровня выбранной конкретной СУБД. Эту стадию называют логическим (или даталогическим) проектированием базы данных, а ее результатом является концептуальная схема базы данных, включающая определение всех информационных элементов (единиц) и связей, в том числе задание типов, характеристик и имен. Хотя даталогическое проектирование оперирует не физическими записями, а логическими понятиями, связанными со структурой базы данных, тем не менее особенности представления данных, правила и языки агрегирования и манипулирования данными имеют определяющее влияние. Не все виды связей, например, «многие ко многим», могут быть непосредственно отображены в логической модели. Рассмотрим по шагам общий подход к построению реляционной базы данных, представленной ER-диаграммой. Получение реляционной схемы из ER диаграммы 1. Каждая простая сущность превращается в таблицу (отношение). Имя сущности становится именем таблицы. 2.Каждый атрибут становится возможным столбцом с тем же именем. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут. Если атрибут является множественным, то для него строится отдельное отношение. 3.Компоненты уникального идентификатора сущности превращаются в первичный ключ. Если имеется несколько возможных уникальных идентификаторов, выбирается наиболее используемый. Если в состав уникального идентификатора входят связи, то к числу столбцов первичного ключа добавляется копия уникального идентификатора сущности, находящейся на дальнем конце связи (этот процесс может продолжаться рекурсивно). Для именования этих столбцов используются имена концов связей и/или имена сущностей. 4.Связи «многие к одному» и «один к одному» становятся внешними ключами. Т.е. создается копия уникального идентификатора с конца связи «один», и соответствующие столбцы составляют внешний ключ. 5.Индексы создаются для первичною ключа (уникальный индекс), а также внешних ключей и тех атрибутов, которые будут часто использоваться в запросах. 6.Если в концептуальной схеме присутствуют подтипы, то возможны два варианта. Все подтипы хранятся в одной таблице, которая создается для самою внешнего супертипа, а для подтипов создаются представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА, и он становится частью первичного ключа. Во втором случае для каждого подтипа создается отдельная таблица (для более нижних — представления) и для каждого подтипа первого уровня супертип воссоздается с помощью представления UNION (из всех таблиц подтипов выбираются общие столбцы — столбцы супертипа). 7 Если остающиеся внешние ключи все принадлежат одному домену, т. е. имеют общий формат, то создаются два столбца: идентификатор связи и идентификатор сущности. Столбец идентификатора связи используется для различения связей. Столбец идентификатора сущности используется для хранения значений уникального идентификатора сущности на дальнем конце соответствующей связи. Если результирующие внешние ключи не относятся к одному домену, то для каждой связи, покрываемой дугой исключения, создаются явные столбцы внешних ключей. 28. Объектно-реляционные базы данных Объектно-реляционная база данных (ОРБД) позволяет программистам, которые работают с языками третьего поколения, интерпретировать все свои информационные сущности как объекты, хранящиеся в оперативной памяти. Дополнительный интерфейсный уровень абстракции обеспечивает перехват запросов, обращающихся к тем частям базы данных, которые находятся в постоянном хранилище на диске. Изменения, вносимые в объекты, оптимальным образом переносятся из памяти на диск. Преимуществом ОРБД является упрощенный код. Приложения получают возможность интерпретировать данные в контексте того языка программирования, на котором они написаны. Реляционная база данных возвращает значения всех полей в текстовом виде, а затем они приводятся к локальным типам данных. В ООБД этот этап ликвидирован. Методы манипулирования данными всегда остаются одинаковыми независимо от того, находятся данные на диске или в памяти. Данные в ОРБД способны принять вид любой структуры, которую можно выразить на используемом языке программирования. Отношения между сущностями также могут быть произвольно сложными. ОРБД управляет кэш-буфером объектов, перемещая объекты между буфером и дисковым хранилищем по мере необходимости. С помощью ОРБД решаются две проблемы. Во-первых, сложные информационные структуры выражаются в них лучше, чем в реляционных базах данных, а во-вторых, устраняется необходимость транслировать данные из того формата, который поддерживается в СУБД. Например, в реляционной СУБД размерность целых чисел может составлять 11 цифр, а в используемом языке программирования — 16. Программисту придется учитывать эту ситуацию. Объектно-ориентированные СУБД выполняют много дополнительных функций. Это окупается сполна, если отношения между данными очень сложны. В таком случае производительность ОРБД оказывается выше, чем у реляционных СУБД. Если же данные менее сложны, дополнительные функции оказываются избыточными. В объектной модели данных поддерживаются нерегламентированные запросы, но языком их составления не обязательно является SQL. Логическое представление данных может не соответствовать реляционной модели, поэтому применение языка SQL станет бессмысленным. Зачастую удобнее обрабатывать объекты в памяти, выполняя соответствующие виды поиска. Большим недостатком объектно-ориентированных баз данных является их тесная связь с применяемым языком программирования. К данным, хранящимся в реляционной СУБД, могут обращаться любые приложения, тогда как, к примеру, Java-объект, помещенный в ОРБД, будет представлять интерес лишь для приложений, написанных на Java. Основная идея объектно-реляционного подхода - это допущение использовать в качестве атрибутов не только простые, атомарные типы данных, но и составные, абстрактные типы данных, что противоречит классической концепции реляционных СУБД.
29. Сравнительная характеристика объектно-реляционных БД Не существует общепринятой объектно-реляционной модели. Основная идея объектно-реляционного подхода - это допущение использовать в качестве атрибутов не только простые, атомарные типы данных, но и составные, абстрактные типы данных, что противоречит классической концепции реляционных СУБД. Oracle Database или Oracle RDBMS Особенности: -Многоверсионность данных для управления параллельными транзакциями. -Автономные транзакции. -Набор инструментов, предназначенных для управления и мониторинга СУБД Oracle и серверов, на которых они установлены. -Поддержка последовательностей. -Аналитические функции в SQL. -Data Guard — технология, позволяющая создать резервный сервер -Automatic Database Diagnostic Monitoring — автоматический мониторинг и диагностика баз для выявления проблем производительности DB2 от IBM Главная особенность DB2 Universal Database - расширяемость ее типов. Под расширяемостью в данном случае подразумевается способность хранить и оперировать не только традиционными реляционными таблицами с символами и числами, но и мультимедийными данными, комплексными объектами (документы, изображения, аудио, видео, пространственные данные, временные ряды и т.д.). Особенности: -возможность работы на мультипроцессорных платформах; -поддержка кластеров; -64-битную архитектура памяти; -распараллеливание запросов; -наличие средств для гетерогенного администрирования и обработки данных; -поддержка выполнения распределенных транзакций. Преимущества объектно-реляционного подхода: 1.Гибкое логическое представление исследуемой предметной области. 2.Объектно-реляционные отношения помогают избежать операции соединения по внешнему ключу при выполнении запросов, если каждое объектно-реляционное отношение декомпозировано на несколько реляционных. 3.Возможности ОРСУБД по интегрированному управлению мультимедиа, традиционными структурированными данными и шаблонами для динамической генерации страниц. 4.Типы, операторы и методы доступа, определяемые пользователем. 5.Поддержка сложных объектов, представляющих собой наборы других объектов. 6.Создание функций, определяемых пользователем. 7.Динамическое (т.е. без прерывания работы СУБД) добавление новых типов данных, операторов, функций и методов доступа. Описание всех этих возможностей создается на языке C и компилируется в объектный файл, который может динамически загружаться сервером СУБД. 8.Наследование данных и функций. Использование массивов как значений полей кортежей. 30. Назначение и основные характеристики не реляционных (NoSQL) БД NoSQL (англ. not only SQL, не только SQL) – термин, обозначающий ряд подходов, направленных на реализацию хранилищ баз данных, имеющих существенные отличия от моделей, используемых в традиционных реляционных СУБД с доступом к данным средствами языка SQL. Применяется к базам данных, в которых делается попытка решить проблемы масштабируемости и доступности (availability) за счёт атомарности и согласованности данных Характерные черты NoSQL-решений
В распределённых системах управления данными используются два основных приёма (практически всегда применяемых совместно): -Разделение данных – подход, при котором каждый узел системы содержит свою часть данных и выполняет операции над ними. Этот метод является основным средством обеспечения горизонтальной масштабируемости. -Репликация – подход, при котором одни и те же данные хранятся на нескольких узлах в сети. Этот метод помогает повысить надежность системы и справляться как со сбоями отдельных узлов, так и с потерей целого кластера. 31. Приемы работы с NoSQL БД. Системы «ключ-значение» Project Voldemort – система управления данными типа «ключ-значение» с открытым исходным кодом, реализованная на Java:
DynamoDB – облачный сервис:
Redis – система управления данными типа «ключ-значение» с открытым исходным кодом, написанная на C:
Riak – мощная система управления данными типа «ключ-значение» с открытым исходным кодом, написанная на Erlang:
Документные СУБД MongoDB – это система управления базами данных, которая значительно отличается от MySQL. Основная разница заключается в том, что в MySQL запросы пишутся на языке SQL, а в MongoDB на BSON (бинарный JSON).
работать с данной системой можно на многих языках программирования, таких как C/C++, Python, PHP, Rubym Perl, .NET и даже Node.js. Системы типа BigTable HBase – проект с открытым исходным кодом на Java, разрабатываемый Apache Software Foundation.
Cassandra – проект с открытым исходным кодом (на Java), поддерживаемым Apache Software Foundation
34.Ведение в технологию хранилищ данных. Предпосылки появления ХД Главное требование к OLTP-системам — быстрое обслуживание относительно простых запросов большого числа пользователей, при этом время ожидания выполнения типового запроса не должно превышать несколько секунд. Со временем в таких системах начали аккумулироваться большие объемы данных — документы, сведения о банковских операциях, информация о клиентах, заключенных сделках, оказанных услугах и т.д. Постепенно возникло понимание того, что сбор данных не самоцель. Собранная информация может оказаться весьма полезной в процессе управления организацией, поиска путей совершенствования деятельности и получения посредством этого конкурентных преимуществ. Но для этого нужны системы, которые позволяли бы выполнять не только простейшие действия над данными: подсчитывать суммы, средние, максимальные и минимальные значения. Появилась потребность в информационных системах, которые позволяли бы проводить глубокую аналитическую обработку, для чего необходимо решать такие задачи, как поиск скрытых структур и закономерностей в массивах данных, вывод из них правил, которым подчиняется данная предметная область, стратегическое и оперативное планирование, формирование нерегламентированных запросов, принятие решений и прогнозирование их последствий. Понимание преимуществ, которые способен дать интеллектуальный анализ, привело к появлению нового класса систем — информационных систем поддержки принятия решений (информационных СППР), ориентированных на аналитическую обработку данных с целью получения знаний, необходимых для разработки решений в области управления. Дополнительным стимулом совершенствования этих систем стали такие факторы, как снижение стоимости высокопроизводительных компьютеров и расходов на хранение больших объемов информации, появление возможности обработки больших массивов данных и развитие соответствующих математических методов Основные особенности концепции ХД В настоящее время однозначного определения ХД не существует, из-за того что разработано большое количество различных архитектур и технологий ХД, а сами хранилища используются для решения самых разнообразных задач. Каждый автор вкладывает в это понятие свое видение вопроса. Обобщая требования, предъявляемые к СППР, можно дать следующее определение ХД, которое не претендует на полноту и однозначность, но позволяет понять основную идею. Определение Хранилище данных — разновидность систем хранения, ориентированная на поддержку процесса анализа данных, обеспечивающая целостность, непротиворечивость и хронологию данных, а также высокую скорость выполнения аналитических запросов. Важнейшим элементом ХД является семантический слой — механизм, позволяющий аналитику оперировать данными посредством бизнес-терминов предметной области. Семантический слой дает пользователю возможность сосредоточиться на анализе и не задумываться о механизмах получения данных. Типичное ХД существенно отличается от обычных систем хранения данных. Главным отличием являются цели использования. Например, регистрация продаж и выписка соответствующих документов — задача уровня OLTP-систем, использующих обычные реляционные СУБД. Анализ динамики продаж и спроса за несколько лет, позволяющий выработать стратегию развития фирмы и спланировать работу с поставщиками и клиентами, удобнее всего выполнять при поддержке ХД. Другое важное отличие заключается в динамике изменения данных. Базы данных в OLTP-системах характеризуются очень высокой динамикой изменения записей из-за повседневной работы большого числа пользователей (откуда, кстати, велика вероятность появления противоречий, ошибок, нарушения целостности данных и т.д.). Что касается ХД, то данные из него не удаляются, а пополнение происходит в соответствии с определенным регламентом (раз в час, день, неделю, в определенное время). |
16. Многомерные модели данных Многомерные СУБД являются узкоспециализированными СУБД, предназначенными для интерактивной аналитической обработки информации.Oсновные понятия, используемые в этих СУБД: агрегируемость,историчность и прогнозируемость данных. Агрегируемостъ данных означает рассмотрение информации на различных уровнях ее обобщения. В информационных системах степень детальности представления информации для пользователя зависит от его уровня:аналитик, пользователь-оператор, управляющий, руководитель, Историчность данных предполагает обеспечение высокого уровня статичности (неизменности) собственно данных и их взаимосвязей, а также обязательность привязки данных ко времени. Статичность данных позволяет использовать при их обработке специализированные методы загрузки, хранения, индексации и выборки. Временная привязка данных необходима для частого выполнения запросов, имеющих значения времени и даты в составе выборки. Необходимость упорядочения данных по времени в процессе обработки и представления данных пользователю накладывает требования на механизмы хранения и доступа к информации. Так, для уменьшения времени обработки запросов желательно, чтобы данные всегда были отсортированы в томпорядке, в котором они наиболее часто запрашиваются. Прогнозируемость данных подразумевает задание функций прогнозирования и применение их к различным временным интервалам. Многомерность модели данных означает не многомерность визуализации цифровых данных, а многомерное логическое представление структуры информации при описании и в операциях манипулирования данными. По сравнению с реляционной моделью многомерная организация данных обладает более высокой наглядностью и информативностью. Для иллюстрации на рис. 2.6 приведены реляционное (а) и многомерное(б) представления одних и тех же данных об объемах продаж автомобилей. Реляционное представление данных
Многомерное представление данных
Основные понятия многомерных моделей данных: измерение и ячейка. Измерение – это множество однотипных данных, образующих одну из граней гиперкуба. В многомерной модели измерения играют роль индексов, служащих для идентификации конкретных значений в ячейках гиперкуба. Ячейка – это поле, значение которого однозначно определяется фиксированным набором измерений. Тип поля чаще всего определен как цифровой. В зависимости от того, как формируются значения некоторой ячейки, она может быть переменной (значения изменяются и могут быть загружены из внешнего источника данных или сформированы программно) либо формулой (значения, подобно формульным ячейкам электронных таблиц, вычисляются по заранее заданным формулам). Достоинством многомерной модели является удобство и эффективность анализа больших объемов данных, имеющих временную связь, а также быстрота реализации сложных нерегламентированных запросов. Недостаток этой модели в громоздкости в случае ее использования для решения стандартных задач оперативной обработки. Она, по сравнению с реляционными, не эффективно использует память, так как в ней резервируется место для всех значений, даже если некоторые из них будут отсутствовать. 17. Объектно-ориентированные модели данных В объектно-ориентированной модели (ООМ) при представлении данных имеется возможность идентифицировать отдельные записи базы. Между записями базы данных и функциями их обработки устанавливаются взаимосвязи с помощью механизмов, подобных соответствующим средствам в объектно-ориентированных языках программирования. Пример логической структуры ООБД библиотечного дела приведен на рис Здесь объект типа БИБЛИОТЕКА является родительским для объектов-экземпляров классов АБОНЕНТ, КАТАЛОГ и ВЫДАЧА. Различные объекты типа КНИГА могут иметь одного или разных родителей. Объекты типа КНИГА, имеющие одного и того же родителя, должны различаться по крайней мере инвентарным номером (уникален для каждого экземпляра книги), но имеют одинаковые значения свойств isbn, удк, название и автор.
Логическая структура ОО БД внешне похожа на структуру иерархической БД. Основное отличие между ними состоит в методах манипулирования данными. Для выполнения действий над данными в ООМ БД применяются логические операции, усиленные объектно-ориентированными механизмами инкапсуляции, наследования и полиморфизма. Ограниченно могут применяться операции, подобные командам SQL (например, для создания БД). Поиск в ООБД состоит в выяснении сходства между объектом, задаваемым пользователем, и объектами, хранящимися в БД. Определяемый пользователем объект, называемый объектом-целью (свойство объекта имеет тип goal), в общем случае может представлять собой подмножество всей хранимой в БД иерархии объектов. Объект-цель, а также результат выполнения запроса могут храниться в самой базе. Пример запроса о номерах читательских билетов и именах абонентов, получавших в библиотеке хотя бы одну книгу показан на рис. 2.9.
Рис. 2.9. Фрагмент БД с объектом-целью Основным достоинством ООМД в сравнении с реляционной является возможность отображения информации о сложных взаимосвязях объектов. ООМД позволяет идентифицировать отдельную запись базы данных и определять функции их обработки. Основными недостатками ООМД являются высокая понятийная сложность, неудобство обработки данных и низкая скорость выполнения запросов. 19. Фактографические модели данных. Фактографические модели данных – это набор признаков, которому соответствует представление информации в виде определенных структур данных (дерево, сеть, таблица). Фактографические модели данных оперируют с фактическими сведениями, над которыми выполняются задачи обработки. Под обработкой данных понимается специальный класс задач, связанных с вводом, хранением, сортировкой, отбором и группировкой записей данных однородной структуры. В большинстве случаев эти задачи предусматривают предоставление пользователям различных отчетов. Среди фактографических информационных систем выделяют два класса: - системы операционной обработки данных; - системы, ориентированные на анализ данных и поддержку принятия решения. I. Системы операционной обработки данных Такие системы рассчитаны на обслуживание относительно простых запросов большого числа пользователей. Логической единицей функционирования таких систем является – транзакция, которая представляет собой неделимую последовательность операций манипулирования данными (чтение, удаление, вставка и изменение). Неделимость определяет факт фиксирования изменений, произведенных над данными, если все операции, входящие в транзакцию выполнены успешно. Если же хотя бы одна из операций не выполнена, то ни одно из изменений е отражается на состоянии данных. II. Системы, ориентированные на анализ данных Они ориентированы на анализ данных и обеспечивают получение информации, необходимой для разработки решений в сфере управления. К системам можно отнести: Систему поддержки приятия решений – человеко-машинный вычислительный комплекс, ориентированный на анализ данных и обеспечивающий получение информации, необходимой для разработки решений в сфере управления. К числу задач, решаемых такими системами, относят: оценка альтернатив решения, прогнозирование, классификация, выявление ассоциаций и др. Основой построения такой системы является концепция хранилища данных, которое обеспечивает возможность анализа накопленных данных и представляется собой интегрированные наборы данных, собранных из различных источников (например: систем оперативного доступа к данным, электронных архивов и др.)
23. Классический метод проектирования реляционных БД Пусть создана таблица Студент, содержащая следуещие поля: № группы, ФИО, № зачетки, дата рождения, шазвание специальности, название факультета. Такая организация хранения информации будет иметь ряд недостатков:
Нормализация таблиц предназначена для устранения этих недостатков. Имеется три нормальные формы отношений. Плюс нормальная форма Бойса-Кода (БКНФ), 4 НФ, 5 НФ. Первая нормальная форма. Признаки 1 НФ: Цель – разделение исходных данных на логические составляющие (таблица).
Реляционная таблица приведена к первой нормальной форме тогда и только тогда, когда ни одна из ее строк не содержит в любом своем поле более одного значения и ни одно из ее ключевых полей не пусто. Так, если из таблицы Студент требуется получать сведения по имени студента, то поле ФИО следует разбить на части Фамилия, Имя, Отчество. Вторая нормальная форма. Признаки 2 НФ: Цель – помещение в отдельную таблицу данных, которые частично зависят от первичного ключа. Если таблица находится в 1 НФ, а первичный ключ состоит из 1 столбца, то она фактически находится в 1 НФ. -Те же что и для 1 НФ; -Любое неключевое поле должно однозначно идентифицироваться ключевым полем. Реляционная таблица задана во второй нормальной форме, если она удовлетворяет требованиям первой нормальной формы и все ее поля, не входящие в первичный ключ, связаны полной функциональной зависимостью с первичным ключом. Чтобы привести таблицу ко второй нормальной форме, необходимо определить функциональную зависимость полей. Функциональная зависимость полей — это зависимость, при крторой в экземпляре информационного объекта определенному значению ключевого реквизита соответствует только одно значение описательного реквизита. Третья нормальная форма. Признаки 3 НФ:
Отношение находится в 3 НФ, если все неключевые атрибуты взаимно независимы и полностью зависят от первичного ключа. При переходе в 3 НФ выявляют транзитивную зависимость атрибутов (функциональная зависимость между неключевыми атрибутами отношения), которое порождает избыточность дублирования информации в отношении. Таблица находится в третьей нормальной форме, если она удовлетворяет требованиям второй нормальной формы, ни одно из ее неключевых полей не зависит функционально от любого другого неключевого поля. Например, в таблице Студент (№ группы, ФИО, № зачетной книжки, Дата рождения, Староста) три поля — № зачетной книжки, № группы, Староста находятся в транзитивной зависимости. № группы зависит от № зачетной книжки, а Староста зависит от № группы. Для устранения транзитивной зависимости необходимо часть полей таблицы Студент перенести в другую таблицу Группа. Таблицы примут следующий вид: Студент (№ группы, ФИО, № зачетной книжки, Дата рождения), Группа (№ группы, Староста). 24. Рекомендации по разработке структур данных в реляционной СУБД: создание отношений (таблиц); организация связи сущностей; обеспечение целостности и уникальности данных. Ключи Поля, формирующие связь между таблицами, называются ключами. Ключ обычно состоит из одного поля, однако может включать и несколько. Есть два вида ключей. Первичный ключ В таблице может быть только один первичный ключ. Он состоит из одного или нескольких полей, однозначно определяющих каждую запись в этой таблице. Например, в таблице с данными о людях в качестве первичного ключа можно использовать сочетание фамилии, имени и даты рождения. Внешний ключ. В таблице также может быть один или несколько внешних ключей. Внешний ключ содержит значения, соответствующие значениям первичного ключа другой таблицы. Например, в таблице "Заказы" каждый заказ может включать код клиента, соответствующий определенной записи в таблице "Клиенты". Поле "Код клиента" является внешним ключом таблицы "Заказы". Основное правило при создании таблиц сущностей - это «каждой сущности - отдельную таблицу» (как в популярном лозунге: «каждой семье - отдельную квартиру»). Обычно достаточно определения простого ключа, реже - вводят составной ключ. Таблицей с составным ключом может быть, например, таблица хранения списка сотрудников (фамилия, имя и отчество), в котором встречаются однофамильцы. В некоторых СУБД пользователям предлагается определить автоматически создаваемое ключевое поле нумерации, которое упрощает решение проблемы уникальности записей таблицы. Иногда в таблицах сущностей имеются поля описания свойств или характеристик объектов. Если в таблице есть значительное число повторений по этим полям и эта информация имеет существенный объем, то лучше их выделить в отдельную таблицу (придерживаясь правила: «каждой сущности - отдельную таблицу»). Тем более, следует образовать дополнительную таблицу, если свойства взаимосвязаны. В более общем виде последние рекомендации можно сформулировать так: информацию о сущностях следует представить таким образом, чтобы неключевые поля в таблицах были взаимно независимыми и полностью зависели от ключа (см. определение третьей нормальной формы). Обеспечение целостности Под целостностью понимают свойство базы данных, означающее, что она содержит полную, непротиворечивую и адекватно отражающую предметную область информацию. Различают физическую и алогическую целостность. Физическая целостность означает наличие физического доступа к данным и то, что данные не утрачены. Логическая целостность означает отсутствие логических ошибок в базе данных, к которым относятся нарушение структуры БД или ее объектов, удаление или изменение установленных связей между объектами и т. д. В дальнейшем речь будем вести о логической целостности. Поддержание целостности БД включает проверку (контроль) целостности и ее восстановление в случае обнаружения противоречий в базе. Целостное состояние БД задается с помощью ограничений целостности в виде условий, которым должны удовлетворять хранимые в базе данные. Структурные ограничения определяют требования целостности сушностей и целостности ссылок. Каждому экземпляру сущности, представленному в отношении, соответствует только один его кортеж. Требование целостности сущностей состоит в том, что любой кортеж отношения должен быть отличим от любого другого кортежа этого отношения, т. е., иными словами, любое отношение должно обладать первичным ключом.
25. Введение в язык SQL. Элементы языка SQL В общих терминах, «SQL база данных» является общим названием для реляционной системы управления базами данных (РСУБД). Для некоторых систем, «база данных» также относится к группе таблиц, данных, конфигурационной информации, которые являются неотъемлемо отдельной частью от других, подобных конструкций. В этом случае, каждая инсталляция SQL базы данных может состоять из нескольких баз данных. В других системах, они упомянуты как таблицы. Таблица – конструкция базы данных, которая состоит из столбцов, содержащих строки данных. Обычно таблицы созданы для того, чтобы содержать связанную информацию. В пределах той же самой базы данных могут быть созданы несколько таблиц. Каждый столбец представляет собой атрибут или совокупность атрибутов объектов, например идентификационные номера служащих, рост, цвет машин и т.п. Часто в отношении столбца используется термин поле с указанием имени, например «в поле Name». Поле строки является минимальным элементом таблицы. Каждый столбец в таблице имеет определенное имя, тип данных и размер. Имена столбцов должны быть уникальны в пределах таблицы. Каждая строка (или запись) представляет собой совокупность атрибутов конкретного объекта, например, в строке может содержаться идентификационный номер служащего, размер его зарплаты, год его рождения и т.д. Строки таблиц не имеют названий. Чтобы обратиться к конкретной строке, пользователю необходимо указать какой-то атрибут (или набор атрибутов), уникально ее идентифицирующий. Методы использования встроенного SQL: Статистический (включается в тело программы на этапе ее разработки в процессе функционирования системы изменяться не может); Динамический (формируется или изменяется во время работы пользователя с системой). Операции: -Формирование состава полей для выходного набора данных; -Включение в выходной набор данных (полей, записей из различных БД; -Отбирать записи по сложным критериям (функции, логические операторы, знаки); -Сотрировка набора данных по любому полю, даже неиндексированному; -Осущ. Поиск данных по частичному совпадению созначением поля (в том случае, если например не знаешь как пишется фамилия) Функции: -Определение данных ( создание, удаление таблиц, создание, удаление, редактирование полей и т. д.); -Обработка данных (сортировка, поиск, редактирование данных и т.д.); -Управление привилегиями (защита данных, разграничение доступа пользователей); -Управлениетранзакциями. Реализация SQL запросов: -Интерактивный подход (мастер, конструктор запросов в БД); -Программный подход. Операторы языка SQL можо разделить на 2 подъязыка: -Язык определения данных DDL (операторы, входящие в создание таблиц); -Язык манипулирования данными DML (оераторы SELECT, INSERT, UPDATE, DELETE (SELECT – выбрать строки из таблиц; INSERT – добавить строки в таблицу; UPDATE – изменить строки в таблице; DELETE – удалить строки в таблице). Каждый из этих запросов имеет различные операторы и функции, которые используются для того, чтобы произвести какие-то действия с данными. Запрос SELECT имеет самое большое количество опций. Существуют также дополнительные типы запросов, используемых вместе с SELECT, типа JOIN и UNION. Запрос INSERT используется для создания новой строки данных. Для обновления уже существующих данных или пустых полей строки нужно использовать запрос UPDATE. UPDATE используется для того, чтобы изменить существующие значения или освободить поле в строке, поэтому новые значения должны соответствовать существующему типу данных и обеспечивать приемлемые значения. Если вы не хотите изменить значения во всех строках, то нужно использовать условие WHERE. Запрос DELETE полность удаляет строку из базы данных. Если вы хотите удалить одно единственное поле, то нужно использовать запрос UPDATE и установить для этого поля значение, которое будет являться аналогом NULL в вашей программе. Будьте внимательны, и ограничивайте ваш запрос DELETE условием WHERE, иначе вы можете потерять все содержимое таблицы. SQL – язык баз данных, и мы рассмотрели наиболее важные и базовые команды, используемые в запросах данных. Множество основных концепций не были затронуты (SUM и COUNT например), но те немногие команды, которые удалось перечислить выше, должны побудить вас к активным действиям и более глубокому изучению замечательного языка запросов под именем SQL. 26. Концептуальное (инфологическое) проектирование. Модель «сущность-связь» Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Цель инфологического этапа проектирования состоит в получении семантических (концептуальных) моделей, отражающих предметную область и информационные потребности пользователей. В качестве инструмента для построения семантических моделей данных на этапе инфологического проектирования является неформальная модель "Сущность-Связь" (ER-модель -). Моделирование предметной области базируется на использовании графических диаграмм, включающих небольшое число разнородных компонентов. Основными понятиями ER-модели являются сущность, связь и атрибут. Сущность (объект) - это реальный или представляемый объект предметной области, информация о котором должна сохраняться и быть доступна. Различают такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных предметов, событий, личностей, выступающих как единое целое. Экземпляр сущности относится к конкретной вещи в наборе. В диаграммах ER-модели сущность представляется в виде прямоугольника (в нотации Баркера), содержащего имя сущности. Атрибут - поименованная характеристика сущности, определяющая его свойства и принимающая значения из некоторого множества значений. Каждый атрибут обеспечивается именем, уникальным в пределах сущности. Связь - это поименованная графически изображаемая ассоциация, устанавливаемая между сущностями и представляющая собой абстракцию набора отношений, которые систематически возникают между различными видами предметов в реальном мире. Большинство связей относятся к категории бинарных и имеют место между двумя сущностями. Модель «сущность-связь». Одной из наиболее популярных средств формализованного представления предметной области систем, ориентированных на обработку фактографической информации, является модель «сущность — связь», которая положена в основу значительного количества коммерческих СASE-продуктов, поддерживающих полный цикл разработки систем баз данных или отдельные его стадии. При этом многие из них не только поддерживают стадию концептуального проектирования предметной области разрабатываемой системы, но и позволяют осуществить на основе построенной их средствами модели стадию логического проектирования путем автоматической генерации концептуальной схемы базы данных для выбранной СУБД, например, схемы базы данных для какого-либо SQL-сервера или объектной СУБД. 32. Концепции защиты данных в БД. В современных СУБД поддерживается один из двух наиболее общих подходов к вопросу обеспечения безопасности данных: избирательный подход и обязательный подход. В обоих подходах единицей данных или «объектом данных», для которых должна быть создана система безопасности, может быть как вся база данных целиком, так и любой объект внутри базы данных. Эти два подхода отличаются следующими свойствами: ---В случае избирательного управления некоторый пользователь обладает различными правами (привилегиями или полномочиями) при работе с данными объектами. Разные пользователи могут обладать разными правами доступа к одному и тому же объекту. Избирательные права характеризуются значительной гибкостью. ---В случае избирательного управления, наоборот, каждому объекту данных присваивается некоторый классификационный уровень, а каждый пользователь обладает некоторым уровнем допуска. При таком подходе доступом к определенному объекту данных обладают только пользователи с соответствующим уровнем допуска. ---Для реализации избирательного принципа предусмотрены следующие методы. В базу данных вводится новый тип объектов БД — это пользователи. Каждому пользователю в БД присваивается уникальный идентификатор. Для дополнительной защиты каждый пользователь кроме уникального идентификатора снабжается уникальным паролем, причем если идентификаторы пользователей в системе доступны системному администратору, то пароли пользователей хранятся чаще всего в специальном кодированном виде и известны только самим пользователям. ---Пользователи могут быть объединены в специальные группы пользователей. Один пользователь может входить в несколько групп. В стандарте вводится понятие группы PUBLIC, для которой должен быть определен минимальный стандартный набор прав. По умолчанию предполагается, что каждый вновь создаваемый пользователь, если специально не указано иное, относится к группе PUBLIC. -Привилегии или полномочия пользователей или групп — это набор действий (операций), которые они могут выполнять над объектами БД. -В последних версиях ряда коммерческих СУБД появилось понятие «роли». Роль — это поименованный набор полномочий. Существует ряд стандартных ролей, которые определены в момент установки сервера баз данных. И имеется возможность создавать новые роли, группируя в них произвольные полномочия. Введение ролей позволяет упростить управление привилегиями пользователей, структурировать этот процесс. Кроме того, введение ролей не связано с конкретными пользователями, поэтому роли могут быть определены и сконфигурированы до того, как определены пользователи системы. -Пользователю может быть назначена одна или несколько ролей. -Объектами БД, которые подлежат защите, являются все объекты, хранимые в БД: таблицы, представления, хранимые процедуры и триггеры. Для каждого типа объектов есть свои действия, поэтому для каждого типа объектов могут быть определены разные права доступа. На самом элементарном уровне концепции обеспечения безопасности баз данных исключительно просты. Необходимо поддерживать два фундаментальных принципа: проверку полномочий и проверку подлинности (аутентификацию). Проверка полномочий основана на том, что каждому пользователю или процессу информационной системы соответствует набор действий, которые он может выполнять по отношению к определенным объектам. Проверка подлинности означает достоверное подтверждение того, что пользователь или процесс, пытающийся выполнить санкционированное действие, действительно тот, за кого он себя выдает.
33.Основные методы защиты БД. В настоящее время объём информации в мире настолько велик, что самым оптимальным методом работы с ней является база данных (БД). База данных – это представленная в объективной форме совокупность материалов, систематизированных так, чтобы эти материалы могли быть найдены и обработаны с помощью компьютера. Её защита является одной из самых сложных задач на сегодняшний день. Угрозы потери конфиденциальной информации стали обычным явлением, и если в системе защиты есть недостатки, то ценные данные могут оказаться в руках третьих лиц. Каждый сбой работы БД может парализовать работу целых корпораций, фирм, что приведет к весомым материальным потерям. Методы защиты баз данных в различных СУБД условно делятся на две группы (анализ современных фирм Borland и Microsoft): основные и дополнительные. К основным средствам защиты относится: - защита паролем; - шифрование; - разделение прав доступа к объектам БД; - защита полей и записей таблиц БД. Защита паролем – это самый простой способ защиты БД от несанкционированного доступа. Пароли устанавливаются пользователями или администраторами. Их учет и хранение выполняется системой управления базой данных (СУБД). Пароли хранятся в специальных файлах СУБД в шифрованном виде. После ввода пароля пользователю предоставляется доступ к требуемой информации. Более мощным средством защиты данных является шифрование. Шифрование – это процесс перевода информации по определенному алгоритму в вид непригодный для чтения, в целях защиты от несанкционированного просмотра или использования. Шифрование обеспечивает три состояния безопасности информации: - конфиденциальность. - целостность. - идентифицируемость. В целях контроля использования основных ресурсов СУБД во многих системах имеются средства установления прав доступа к объектам БД. Права доступа определяют возможные действия над объектами. Владелец объекта, а также администратор БД имеют все права. Остальные пользователи имеют те права и уровни доступа к объектам, которыми их наделили. Разрешение на доступ к конкретным объектам базы данных сохраняется в файле рабочей группы. Файл рабочей группы содержит данные о пользователях группы и считывается во время запуска. Файл содержит следующую информацию: имена учетных записей пользователей, пароли пользователей, имена групп, в которые входят пользователи. К дополнительным средствам защиты БД можно отнести следующие средства: - встроенные средства контроля значений данных в соответствии с типами: - повышение достоверности вводимых данных: - обеспечения целостности связей таблиц: - организации совместного использования объектов БД в сети. Описанные выше методы и способы являются основополагающими, однако их использование не гарантирует полной сохранности данных. Для повышения уровня безопасности информации в БД рекомендуется использование комплексных мер. 35. Варианты организации хранилища данных. Хранилище данных — предметно-ориентированная информационнаябаза данных, специально разработанная и предназначенная для подготовки отчётов и бизнес-анализа с целью поддержки принятия решений в организации. Строится на базесистем управления базами данныхисистем поддержки принятия решений. Данные, поступающие в хранилище данных, как правило, доступны только для чтения. Данные изOLTP-системы копируются в хранилище данных таким образом, чтобы построение отчётов иOLAP-анализ не использовал ресурсы транзакционной системы и не нарушал её стабильность. Как правило, данные загружаются в хранилище с определённой периодичностью, поэтому актуальность данных может несколько отставать от OLTP-системы. Принципы организации хранилища 1Проблемно-предметная ориентация. Данные объединяются в категории и хранятся в соответствии с областями, которые они описывают, а не с приложениями, которые они используют. 2Интегрированность. Данные объединены так, чтобы они удовлетворяли всем требованиям предприятия в целом, а не единственной функции бизнеса. 3Некорректируемость. Данные в хранилище данных не создаются: т.е. поступают из внешних источников, не корректируются и не удаляются. 4Зависимость от времени. Данные в хранилище точны и корректны только в том случае, когда они привязаны к некоторому промежутку или моменту времени.
Создание хранилищ данных не должно противоречить действующим системам сбора и обработки информации. Специальные компоненты словарей должны обеспечивать своевременное извлечение из словарей и обеспечить преобразование к единому формату на основе словаря метаданных. Логическая структура данных хранилища данных отличается от структуры данных источников данных. Для разработки эффективного процесса преобразования необходима хорошо проработанная модель корпоративных данных и модель технологии принятия решений. Данные для пользователя удобно представлять в многоразмерных БД, где в качестве размерности могут выступать время, цена или географический регион. Кроме извлечения данных из БД, принятия решений важен процесс извлечения знаний, в соответствии с информационными потребностями пользователя. С точки зрения пользователя в процессе извлечения знаний из БД должны решаться след. преобразования: данные -> информация -> знания -> полученные решения.
36. Функции администратора БД и БнД. Основной функцией АБД является обеспечение структур данных и взаимосвязь между ними, эффективных для обслуживания именно всего коллектива пользователей. Это функция администрирования БД. БнД отличаются тем, что их внедрение и последующая эксплуатация занимает довольно продолжительное время. Поэтому функции АБД являются долгосрочными и направлены на координацию всех этапов проектирования, реализации и ведения БД. На стадии проектирования АБД выступает основным идеологом, руководит всеми работами по разработке или приобретению ПО, обучение обслуживающего персонала и т.п. На стадии эксплуатации отвечает за нормальную эксплуатацию и функционирование БнД, управляет режимом работы, отвечает за сохранность данных. Администраторы банка данных. Это группа пользователей, которая на начальной стадии разработки банка данных отвечает за его оптимальную организацию с точки зрения одновременной работы множества конечных пользователей, на стадии эксплуатации отвечает за корректность работы данного банка информации в многопользовательском режиме. На стадии развития и реорганизации эта группа пользователей отвечает за возможность корректной реорганизации банка без изменения или прекращения его текущей эксплуатации. Администратор банка данных (БнД) (а => и БД) - лицо, отвечающее за выработку требований к БД, ее проектирование, реализацию, эффективное использование и сопровождение. А также use ресурсы БнД для выполнения своих ф-ций. В составе группы администраторов БнД м. выделить различ подгруппы в зав-ти от выполняемых ими ф-ций. Численность группы администрации и выполняемые ими ф-ции будут в некотор степени зависеть от масштаба БнД, специфики хранимой в нем инфы, типа БнД, особенностей используемых программных средств и некотор др факторов. В составе администрации БнД д.б. системные аналитики, проектировщики структур данных и внешнего по отнош-ю к БнД информац обеспеч-я, проектировщики технологич процессов обработки данных, системные и прикладные программисты, операторы, специалисты по технич обслуживанию. Если речь идет о коммерческом БнД, то важную роль здесь будут играть специалисты по маркетингу. 1.Анализ предмет обл-ти: описание предмет обл-ти, выявление ограничений целостности, опред-е статуса инфы, потребностей и статуса пользователей, соответствия «данные − пользователь», объемно-временных хар-к обработки данных. 2. Проектирование структуры БД: опред-е состава и структуры файлов БД, связей между ними, выбор методов упорядочения данных и методов доступа к инфе, описание структуры БД на ЯОД(языке описания данных). 3. Задание ограничений целостности при описании структуры и процедур обработки БД: задание ограничений целостности, присущих предмет обл-ти; опред-е ограничений целостности, вызванных структурой БД; разработка процедур обеспеч-я целостности БД при вводе и корректировке данных; обеспеч-е ограничений целостности при || работе пользователей в многопользовательском режиме. 4. Первоначальная загрузка и ведение БД: разработка технологии первоначальной загрузки и ведения (изменения, добавления, удаления записей) БД, проектирование форм ввода, создание программных модулей, подготовка исходных данных, ввод и контроль ввода. 5.Защита данных: -Обеспеч-е парольного входа в сис-му: регистрация пользователей, назначение и изменение паролей. -Обеспеч-е защиты конкретных данных: опред-е прав доступа групп и отдельных пользователей, опред-е допустимых операций над данными для отдельных пользователей, выбор/создание программно-технологич средств защиты данных. -Тестирование средств защиты данных. -Фиксация попыток несанкционированного доступа к инфе. -Исследование возникающих случаев нарушения защиты данных и проведение мероприятий по их предотвращению. 6.Обеспеч-е восстановления БД: разработка программно-технологич средств восстановления БД, организация ведения системных журналов. 7.Анализ обращений пользователей к БД: сбор статистики обращений пользователей к БД, ее хранение и анализ (кто из пользователей, к какой инфе, как часто обращался, какие, выполнял операции, время выполнения запросов, анализ причин безуспешных (в том числе и аварийных) обращений к БД). 8. Анализ эффективности ф-ционирования БнД и развитие сис-мы: анализ показателей ф-ционирования сис-мы (время обработки, объем памяти, стоимостные показатели), реорганизация и реструктуризация БД, изменение состава БД, развитие программных и технич средств. 9.Работа с пользователями: сбор инфы об изменениях в ПО, об оценке пользователями работы БнД, опред-е регламента работы пользователей с БнД, обучение и консультирование пользователей. 10.Подготовка и поддержание системных программных средств: сбор и анализ инфы о СУБД, приобретение программных средств, их установка, проверка работоспособности, поддержание системных библиотек, развитие программных средств. 11.Организационно-методич работа: выбор или создание методики проектирования БД, опред-е целей и направлений развития сис-мы, планирование этапов развития БнД, разработка и выпуск организационно-методических материалов.
|
Пример
схемы сетевой БД
Основные
понятия реляционной модели
Логическая
структура БД библиотечного дела