выборки и обновления для представлений.
Специальные операторы языка 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 не может относиться к конкретным столбцам
2)Проектирование реляционных БД с использованием нормализации: нормальная форма Бойса-Кодда, четвертая нормальная форма.
Процесс нормализации это последовательное преобразование исходной БД к НФ, при этом каждая следующая НФ обязательно включает в себя предыдущую (что, собственно, и позволяет разбить процесс на этапы и производить его однократно, не возвращаясь к предыдущим этапам). Всего в реляционной теории насчитывается 6 НФ: Первая нормальная форма (обычно обозначается также 1НФ). Вторая нормальная форма. Третья нормальная форма. Нормальная форма Бойса-Кодда (НФБК). Четвёртая нормальная форма. Пятая нормальная форма, или нормальная форма проекции-соединения (5NF или PJ/NF).
Рассмотрим следующий пример схемы отношения: СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, СОТР_ИМЯ, ПРО_НОМЕР, СОТР_ЗАДАН) Возможные ключи: СОТР_НОМЕР, ПРО_НОМЕР; СОТР_ИМЯ, ПРО_НОМЕР Функциональные зависимости: СОТР_НОМЕР -> CОТР_ИМЯ; СОТР_НОМЕР -> ПРО_НОМЕР; СОТР_ИМЯ -> CОТР_НОМЕР; СОТР_ИМЯ -> ПРО_НОМЕР; СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН; СОТР_ИМЯ, ПРО_НОМЕР -> CОТР_ЗАДАН
В этом примере мы предполагаем, что личность сотрудника полностью определяется как его номером, так и именем. В соответствии с определением отношение СОТРУДНИКИ-ПРОЕКТЫ находится в 3NF. Однако тот факт, что имеются функциональные зависимости атрибутов отношения от атрибута, являющегося частью первичного ключа, приводит к аномалиям. Например, для того, чтобы изменить имя сотрудника с данным номером согласованным образом, нам потребуется модифицировать все кортежи, включающие его номер. Детерминант - любой атрибут, от которого полностью функционально зависит некоторый другой атрибут.
Нормальная форма Бойса-Кодда Отношение R находится в нормальной форме Бойса-Кодда (BCNF) в том и только в том случае, если каждый детерминант является возможным ключом. Очевидно, что это требование не выполнено для отношения СОТРУДНИКИ-ПРОЕКТЫ. Можно произвести его декомпозицию к отношениям СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ: СОТРУДНИКИ (СОТР_НОМЕР, СОТР_ИМЯ) Возможные ключи: СОТР_НОМЕР; СОТР_ИМЯ Функциональные зависимости: СОТР_НОМЕР -> CОТР_ИМЯ; СОТР_ИМЯ -> СОТР_НОМЕР; СОТРУДНИКИ-ПРОЕКТЫ (СОТР_НОМЕР, ПРО_НОМЕР, СОТР_ЗАДАН) Возможный ключ: СОТР_НОМЕР, ПРО_НОМЕР Функциональные зависимости: СОТР_НОМЕР, ПРО_НОМЕР -> CОТР_ЗАДАН
Возможна альтернативная декомпозиция, если выбрать за основу СОТР_ИМЯ. В обоих случаях получаемые отношения СОТРУДНИКИ и СОТРУДНИКИ-ПРОЕКТЫ находятся в BCNF, и им не свойственны отмеченные аномалии.
Рассмотрим пример следующей схемы отношения: ПРОЕКТЫ (ПРО_НОМЕР,ПРО_СОТР, ПРО_ЗАДАН)
Отношение ПРОЕКТЫ содержит номера проектов, для каждого проекта список сотрудников, которые могут выполнять проект, и список заданий, предусматриваемых проектом. Сотрудники могут участвовать в нескольких проектах, и разные проекты могут включать одинаковые задания. Каждый кортеж отношения связывает некоторый проект с сотрудником, участвующим в этом проекте, и заданием, который сотрудник выполняет в рамках данного проекта (мы предполагаем, что любой сотрудник, участвующий в проекте, выполняет все задания, предусмотренные этим проектом). По причине сформулированных выше условий единственным возможным ключом отношения является составной атрибут ПРО_НОМЕР, ПРО_СОТР, ПРО_ЗАДАН, и нет никаких других детерминантов. Следовательно, отношение ПРОЕКТЫ находится в BCNF. Но при этом оно обладает недостатками: если, например, некоторый сотрудник присоединяется к данному проекту, необходимо вставить в отношение ПРОЕКТЫ столько кортежей, сколько заданий в нем предусмотрено.
Многозначные зависимости В отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, если множество значений B, соответствующее паре значений A и C, зависит только от A и не зависит от С. В отношении ПРОЕКТЫ существуют следующие две многозначные зависимости: ПРО_НОМЕР -> -> ПРО_СОТР; ПРО_НОМЕР -> -> ПРО_ЗАДАН
Легко показать, что в общем случае в отношении R (A, B, C) существует многозначная зависимость R.A -> -> R.B в том и только в том случае, когда существует многозначная зависимость R.A -> -> R.C.
Четвертая нормальная форма
Отношение R находится в четвертой нормальной форме (4NF) в том и только в том случае, если в случае существования многозначной зависимости A -> -> B все остальные атрибуты R функционально зависят от A.
В нашем примере можно произвести декомпозицию отношения ПРОЕКТЫ в два отношения ПРОЕКТЫ-СОТРУДНИКИ и ПРОЕКТЫ-ЗАДАНИЯ:
ПРОЕКТЫ-СОТРУДНИКИ (ПРО_НОМЕР, ПРО_СОТР)
ПРОЕКТЫ-ЗАДАНИЯ (ПРО_НОМЕР, ПРО_ЗАДАН) Оба эти отношения находятся в 4NF и свободны от отмеченных аномалий.
Четвёртая нормальная форма запрещает существование многозначных зависимостей между столбцами. Если столбец вместо того, чтобы уникально идентифицировать другой столбец, ограничивает его значения некоторым предопределённым множеством значений – это означает, что между ними существует многозначная зависимость.
На практике, как правило, ограничиваются 3НФ, ее оказывается вполне достаточно для создания надежной схемы БД. НФ более высокого порядка представляют скорее академический интерес из-за их сложности. Более того, при реализации абстрактной схемы БД в виде реальной базы иногда разработчики вынуждены сделать шаг назад – провести денормализацию с целью повышения эффективности, т.к. идеальная, с точки зрения теории, структура может оказаться слишком накладной на практике.
3)Файловые системы. Назначение файловых систем. Классификации и типы файловых систем. Типы файлов. Иерархические файловые системы, файловые системы - наборы данных, записеориентированные и потокоориентированные файлы, файлы последовательного и прямого доступа.
Файловая система (file system) — 1. Регламент, определяющий способ организации, хранения и именования данных на носителях информации. 2. Часть операционной системы, обеспечивающая выполнение операций над файлами. 3. Файлы, каталоги и управляющая информация на внешнем носителе. Файловая система определяет формат физического хранения файлов, определяет размер имени файла, максимальный возможный размер файла, набор атрибутов файла. Некоторые файловые системы предоставляют сервисные возможности, например, разграничение доступа или шифрование файлов.Файловая система связывает носитель информации с одной стороны и средства для доступа к файлам — с другой. прикладная программа обращается к файлу, знает только имя файла, его размер и атрибуты. Эти данные она получает от драйвера файловой системы. Именно файловая система устанавливает, где и как будет записан файл на диске.
По предназначению файловые системы можно классифицировать на следующие категории: 1.для носителей с произвольным доступом (например, жесткий диск): FAT32, HPFS, EXT2 и др. В последнее время широкое распространение получили журналируемые файловые системы такие как EXT3, ReiserFS, JFS, NTFS, XFS и др. 2.для носителей с последовательным доступом (например, магнитные ленты): QIC и др. 3.для оптических носителей — CD и DVD: ISO9660, ISO9690, HFS, UDF и др. 4.виртуальные файловые системы: AEFS и др 5.Сетевые файловые системы: NFS, SMBFS и др. Одноуровневая файловая система. Для дисков с небольшим количеством файлов (до нескольких десятков) может использоваться одноуровневая файловая система, когда каталог (оглавление диска) представляет собой линейную последовательность имен файлов и соответствующих номеров начальных секторов. Многоуровневая иерархическая файловая система. Если на диске находятся сотни и тысячи файлов, то для удобства поиска они хранятся в многоуровневой иерархической файловой системе, представляющей собой систему вложенных папок. В каждой папке могут храниться папки нижнего уровня и файлы. В различных операционных системах и/или файловых системах могут быть реализованы различные типы файлов; так же может различаться реализация различных типов.«Обыкновенный файл» — файл, позволяющий операции чтения, записи, перемещения внутри файла Директория (англ. directory — алфавитный справочник, часто переводится как каталог) — файл, содержащий в себе записи о других файлах. Директории могут содержать записи о других директориях, образуя древовидную структуру. Жесткая ссылка (англ. hardlink, часто используется калька хардлинк) — в общем случае одна и та же область информации может иметь несколько имён, указывающих на одни и те же данные. В этом случае такие имена называют жесткими ссылками (хардлинками). В общем случае после создания хардлинка сказать кто «настоящий» файл а кто хардлинк невозможно, так как имена равноправны; а область данных существует до тех пор пока существует хотя бы одно из имён. Хардлинки возможны только на одном физическом носителе. Символьная ссылка (софтлинк) — файл, содержащий в себе ссылку на другой файл или директорию. Может ссылаться на любой элемент файловой системы, в том числе, и расположенный на другом физическом носителе.
«ЗАПИСЕОРИЕНТИРОВАННЫЕ» ФАЙЛЫ 1.Последовательная организация: записи располагаются в физическом порядке. 2.Индексно-последовательная: записи размещаются в логич порядке в соответствии со значениями ключей, содержащихся в каждой записи. 3.Прямая: доступ к записям осуществляется прямо по их физическим адресам. 4.Библиотечная: по сути это уже файл, состоящий из последовательных «подфайлов». 5.Логич записи отображаются на физические. 7.Быстрый доступ к данным на уровне аппаратуры. 8.Проблема фрагментации томов прямого доступа. Требуется процедура сжатия.
ПОТОКООРИЕНТИРОВАННЫЕ ФАЙЛЫ 1.Диск разбивается один раз, определ длины. Файл не делится. 2.Файл рассматривается как непрерывный поток бит. 3.Разбиение потока на записи зависит от програм обеспечения (догов-ность о последовател бит – разделителе логич записей). 4.Последовательный доступ к конкретным логическим записям. 5.Удобная организация дисковой памяти. 6.Простота реализации.
Достоинства: диск используется эффективней, и проще управляется. Недостаток: можно смотреть как на магнитную ленту, т.е. надо перемотать к концу от начала. Общие принципы построения файловых систем. Фиксированные записи. Мы знаем общее количество записей, отводим место, где храним данные о файле. Усложнение. Директория, индексные блоки, список всех записей. Отображение файлов. Имя файла и указатель на его положительный набор физических записей