Главная

Категории:

ДомЗдоровьеЗоологияИнформатикаИскусствоИскусствоКомпьютерыКулинарияМаркетингМатематикаМедицинаМенеджментОбразованиеПедагогикаПитомцыПрограммированиеПроизводствоПромышленностьПсихологияРазноеРелигияСоциологияСпортСтатистикаТранспортФизикаФилософияФинансыХимияХоббиЭкологияЭкономикаЭлектроника






Объектно-ориентированные базы данных


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

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

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

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

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

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

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

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

Объектно-реляционные базы данных

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

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

Объектно-реляционные СУБД объединяют в себе черты реляционной и объектной моделей. Реляционные БД хорошо работают со встроенными типами данных и гораздо хуже – с нестандартными.

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

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

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

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

3. Гибридные шлюзы. Еще одним решением может стать создание гибридных объектно-реляционных СУБД, которые могут хранить и традиционные табличные данные, и объекты. Многие аналитики считают, что будущее за такими гибридными БД. Ведущие поставщики реляционных СУБД начинают (или планируют) добавлять к своим продуктам объектно-ориентированные средства.

 

 

16+18+32. Схемы привилегий Mysql.Таблицы привелегий Mysql.Безопасность.

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

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

Пользовательские имена и пароли могут быть длиной до 16 символов. Пароль можно оставлять пустым. Это самый низкий уровень безопасности. Он допустим только тогда, когда доступ ограничивается по каким-то другим критериям, например, по адресу узла.

Перечень привилегий хранится в базе данных mysql. При инсталляции программы в этой базе создаются пять таблиц с описаниями привилегий:

· columns_priv – привилегии отдельных столбцов;

· tables_priv – привилегии отдельных таблиц;

· db – привилегии всей базы данных;

· host – привилегии всех пользователей того или иного узла;

· user – глобальные привилегии.

 

 

Глобальные привилегии

 

В таблице user (host, user, password, … привилегии) описываются глобальные права доступа и хранятся пользовательские пароли. Пароль можно создать с помощью функции PASSWORD() или путем прямого изменения таблицы user, но удобнее всего изменять содержимое таблицы с помощью инструкции GRANT.

При попытке подключения к серверу программа MySQL обращается к таблице user и проверяет, имеет ли пользователь право на подключение. Имя, пароль и адрес узла пользователя должны соответствовать как минимум одной записи таблицы. Если этого не происходит, программа отказывает пользователю в запросе.

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

Следует, правда, отметить, что любому зарегистрированному пользователю разрешено вводить инструкции вида SELECT <выражение>, где <выражение> содержит функции и константы и не связано с содержанием таблиц баз данных, например, SELECT NOW().

За каждым пользователем каждого узла в таблице user закреплен свой набор привилегий, заданных в виде перечислений со значениями 'Y'/'N'. В столбце Host содержится IP-адрес либо доменное имя компьютера. Для задания диапазона адресов можно использовать метасимволы “%” (процент) и “_” (подчеркивание).

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

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

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

Если комбинации адреса узла и пользовательского имени соответствует несколько записей таблицы user, программа выберет ту из них, в которой адресная спецификация является наиболее точной. В случае равенства выбирается запись с более точным именем пользователя.

 

 

Доступ к базам данных

 

Таблицы db (host, db, user, …привилегии) и host (host, db, …привилегии) совместно контролируют доступ к базам данных. В таблице db (здесь имена пользователей с метасимволами не допустимы) записи сортируются в таком порядке: имя узла, имя базы данных, имя пользователя. Записи таблицы host сортируются сначала по имени узла, потом – по имени базы данных.

 

 

Доступ к таблицам и колонкам

 

Таблицы columns_priv (host, db, user, table, column_name, привилегия) и tables_priv (host, db, user, table_name, grantor, table_priv, column_priv)допускают наличие метасимволов, но только в столбце Host. Поэтому, чтобы предоставить пользователю права доступа к трем столбцам таблицы, нужно задать три записи в таблице columns_priv.

Названия привилегий в большинстве своем соответствуют названиям инструкций SQL, поэтому по названию привилегии легко понять, какие права получает пользователь.

Привилегия File разрешает пользователям выполнять инструкцию LOAD DATA INFILE, а также инструкцию SELECT с предложением INTO OUTFILE. Она определяет лишь возможность чтения и записи файлов на сервере.

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

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

Программа MySQL проверяет привилегии для каждой инструкции, вводимой пользователем. Как только программа находит нужную привилегию, она прекращает дальнейший поиск. Последовательность проверки таблиц:

· Просматривается таблица user. Обычно у рядовых пользователей глобальных привилегий нет, поэтому дальше

· Просматриваются таблицы db и host. Каждая запись таблицы db описывает права доступа к заданной базе данных. Если поле Host таблицы db является пустым, соответствующая запись должна присутствовать в таблице host. Программа выбирает только те привилегии, которые определены в обеих таблицах.

· Если искомые привилегии в таблицах db и host отсутствуют, программа проверяет таблицу tables_priv, в которой определены привилегии доступа к отдельным таблицам.

· В последнюю очередь проверяется таблица columns_priv.

· Если и в последней таблице ничего не найдено, пользовательский запрос отклоняется.

Безопасность

В MySQL применяются списки управления доступом, традиционные для многих систем. На сервере хранятся таблицы пользовательских привилегий. Привилегии могут относиться к столбцам, таблицам, базам данных или быть глобальными.

Схемы привилегий

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

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

Пользовательские имена и пароли могут быть длиной до 16 символов. Пароль можно оставлять пустым. Это самый низкий уровень безопасности. Он допустим только тогда, когда доступ ограничивается по каким-то другим критериям, например, по адресу узла.

 

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

Появление теоретико-множественных моделей в системах баз данных было предопределено настоятельной потребностью пользователей в переходе от работы с элементами данных, как это делается в графовых моделях, к работе с некоторыми макрообъектами.

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

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

 

Рассмотрим основные положения реляционной модели.

1) Реляционная база данных состоит из таблиц.

2) Каждая таблица состоит из строк (записей) и столбцов (полей). В столбце хранятся соответствующие значения каждой строки; каких либо «пропусков» или коротких столбцов быть не может.

3) Запись является отдельной сущностью, а поля представляют собой атрибуты записей.

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

4) У каждого столбца есть название и тип.

Определение атрибута является строгим.

5) Все значения атрибута должны иметь один и тот же тип.

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

7) Таблицы не содержат дубликатов. Каждая запись уникальным образом идентифицируется совокупностью значений своих полей.

8) Порядок столбцов в таблице произволен.

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

Теоретической основой этой модели стала теория отношений, основу которой заложили два логика — американец Чарльз Содерс Пирс (1839-1914) и немец Эрнст Шредер (1841-1902). В руководствах по теории отношений было показано, что множество отношений замкнуто относительно некоторых специальных операций, то есть образует вместе с этими операциями абстрактную алгебру.

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

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

 

Основной структурой данных в модели является отношение, именно поэтому модель получила название реляционной (от английского слова relation ‑ отношение).

Положим, мы имеем несколько исходных множеств D1,D2, ..., Dn, в каждом из которых содержатся наборы допустимых значений той или иной характеристики, того или иного параметра.

19+48.Теоретико-множественные операции реляционной алгебры.Декартово произведение.

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

Объединение отношений

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

 

Пересечение отношений

 

Пересечением отношений называется отношение, которое содержит множество кортежей, принадлежащих одновременно и первому и второму отношениям. R1 и R2:

 

R4 = R1 Ç R2 ={r | rÎ R1 Ç r Î R2}

здесь Ç — операция логического умножения (логическое «И»).

Разность отношений

Разностью отношений R1 и R2 называется отношение, содержащее множество кортежей, принадлежащих R1 и не принадлежащих R2

 

Операции объединения, пересечения и разности применимы только к отношениям с эквивалентными схемами.

 

 



Последнее изменение этой страницы: 2016-06-09

headinsider.info. Все права принадлежат авторам данных материалов.