3. Языки запросов субд. Sql: Команда select. Общая структура команды (блоки from, where и т.П.) Манипулирование данными в субд.

SQL является наиболее мощным и популярным языком манипулирования данными реляционных систем управления базами данных (СУБД)

Минимальный синтаксис инструкции Select: Select поля from таблица

Выбор всех столбцов: Select * from <таблица>

Выбор конкретных столбцов: Select фамилия, имя [дата рождения] from таблица

Использование псевдонимов: Select fam as [фамилия], name as [имя], dr as [дата рождения] from таблица

Выборка данных: Select поля from таблица where условия отбора

Примечания:

1. Символьные строки заключаются в апострофы “ ”.

2. Даты заключаются в решетки #.

3. Псевдонимы не могут использоваться в предложении Where.

4. Обновление баз данных. Sql: Управление данными: добавление, удаление записей. Реструктуризация баз данных. Понятие целостности баз данных. Безопасность баз данных.

• Удаление: Delete <имя таблицы> where <условия отбора>

• Изменение: Update <имя таблицы> Set <имя колонки>={<выражение>|Default|Null} from <имя исходной таблицы> where <условия отбора>

• Добавление: INSERT INTO <имя таблицы> (<имя колонки>) values(<тип данных>)

Реструктуризация баз данных

Реструктуризацией (Далее Р.) называется процесс изменения структуры БД и соответсвующих ему изменения описания БД и самой хранимой БД. Р. может заключаться в изменении как логической так и физической структуры БД. Иногда к Р. Относят и такие изменения как восстановление или изменение условий проверки непротиворечивости данных.

Операции по Р. Зависят от предоставляемых СУБД возможностей выбора параметров структур данных, а так же от особенностей поддерживаемых ими структур.

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

Среди логической Р. Можно выделить: изменение имени, введение новых типов элементов БД или изменение имеющихся, перегруппировки имеющихся в исходной БД элементов (различные варианты разбиения информационной совокупности на несколько и, наоборот, объединение нескольких информационных совокупностей в одну), изменение взаимного расположения элементов БД, изменения поля упорядочения, введение дополнительной индексации или аннулировании индексов.

Главная объективная причина необходимости Р. Заключается в том, что отображаемая в Бд предметная область является динамической и изменения происходящие в ней, могут потребовать изменения структуры БД. Другая причина возникает из-за появления новых запросов к БД, расширения и развития АИС в процессе ее функционирования.

Целесообразность Р. Выявляется и в процессе управления эффективностью функционирования АИС.

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

В составе СУБД обычно имеются утилиты, позволяющие выполнять те или иные операции по Р. БД. Физическая Р. не может производиться без перезагрузки БД. Логическая Р. для большинства СУБД также влечет за собой необходимость перезагрузки всей БД или ее части.

В большинстве случаев Р. выполняется путем создания новой схемы БД, выгрузкой старой БД (в линейные файлы) и загрузки ее в соответствие с новой схемой. Некоторые СУБД ползволяют осуществлять перезагрузку без промежуточных файлов, т.е. в режиме «Исходная БД -> Целевая БД».

С понятием Р. тесно связано понятие Реорганизация(далее РО.), которое имеет два толкования: широкое - как любое изменение в организации данных, включая Р., и узкое – как изменение физического размещения данных, без изменения структуры данных. Примером последнего является РО. индексно-последовательного файла, с целью физического удаления аннулированных записей и приведения в соответствие логического и физического порядка следования записей за счет перенесения записей из областей переполнения в основную область. В дальнейшем, чтобы различать эти два вида преобразования данных будет использоваться понятие РО. в узком смысле.

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

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

Другие способы организации данных, напротив, не чувствительны к корректировке и не требуют выполнения реорганизации в процессе эксплуатации. В некоторых системах выполнение отдельных операций корректировки сопровождается частичной РО. (например, при организации данных в виде хешированного файла удаление записей из цепочки синонимов может вызвать перемещение последней записи из цепочки на место удаленной). Большинство способов организации данных требует переодического проведения РО.

Частота проведения РО. зависит от многих факторов: размера БД, интенсивности и характера предшествующих корректировок, интенсивности последующих обращений к БД, предполагаемого срока жизни БД, характеристик процедуры РО. данных.

Целостность данных на уровне таблицы:

Обеспечение целостности данных гарантирует качество данных в таблице. Например если служащий вводится со значением столбца employee_id, равным 123, то база данных не должна позволять другим служащим иметь такое же значение идентификатора. Если существует столбец employee_rating, в котором диапазон значений должен составлять от 1 до 5, то база данных не должна сохранять в нем значение 6. Если в таблице есть столбец dept_id, в котором хранятся номера отделов для служащих, то база данных должна воспринимать только те значения, которые допустимы в качестве номеров отделов компании.

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

• Сущностная целостность

• Доменная целостность

• Ссылочная целостность

• Пользовательская целостность

Сущностная целостность

Сущностная целостность определяет строку как уникальную сущность в конкретной таблице. Она обеспечивает целостность столбцов идентификаторов или первичного ключа таблицы с помощью индексов, ограничений UNIQUE, ограничений PRIMARY KEY или свойств IDENTITY.

Доменная целостность - это достоверность записей в конкретном столбце. Она включает ограничения типа данных, ограничения формата при помощи ограничений CHECK и правил, а также ограничения диапазона возможных значений при помощи ограничений FOREIGN KEY, CHECK, DEFAULT, определений NOT NULL и правил.

Ссылочная целостность

Ссылочная целостность сохраняет определенные связи между таблицами при вводе или удалении записей. В SQL Server 2000 ссылочная целостность основана на связи первичных и внешних ключей (либо внешних и уникальных ключей) и обеспечивается с помощью ограничений FOREIGN KEY и CHECK. Ссылочная целостность гарантирует согласованность значений ключей во всех таблицах. Этот вид целостности требует отсутствия ссылок на несуществующие значения, а также обеспечивает согласованное изменение ссылок во всей базе данных при изменении значения ключа.

При обеспечении ссылочной целостности SQL Server не допускает следующих действий пользователей.

Добавления или изменения записей в связанной таблице, если в первичной таблице нет соответствующей записи.

Изменения значений в первичной таблице, которое приводит к появлению потерянных записей в связанной таблице.

Удаления записей из первичной таблицы, если имеются совпадающие с ней записи в других таблицах.

Пользовательская целостность

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

Принудительное обеспечение целостности данных

Планирование и создание таблиц требует указания допустимых значений для столбцов и определения способов принудительного обеспечения целостности данных в них. SQL Server 2005 предоставляет следующие механизмы для принудительного обеспечения целостности данных в столбце:

• Ограничения PRIMARY KEY

• Ограничения FOREIGN KEY

• Ограничения UNIQUE

• Ограничения CHECK

• Определения DEFAULT

• Разрешение значений NULL

Безопасность баз данных.

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

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

Хищение информации из баз данных: местные особенности России или отражение мировых тенденций?

Долгое время защита баз данных ассоциировалась с защитой локальной сети предприятия от внешних атак хакеров, борьбой с вирусами и т. п. Последние аналитические отчеты консалтинговых компаний выявили другие, более важные направления защиты информационных ресурсов компаний. Исследования убедительно показали, что от утечки информации со стороны персонала и злонамеренных действий «всесильных» администраторов баз данных не спасают ни межсетевые экраны, ни VPN, ни даже «навороченные» системы обнаружения атак и анализа защищенности. Неавторизованный доступ к данным и кража конфиденциальной информации являются главными составляющими потерь предприятий после ущерба, наносимого вирусами (рис. 1).

Один из основных выводов отчета CSI/FBI – значительно возросший ущерб от такой угрозы, как кража конфиденциальных данных. Каждая американская компания в среднем потеряла 355,5 тыс. долл. только из-за утечек конфиденциальных данных за прошедшие 12 месяцев. Средний размер потерь от действий инсайдеров составил 300 тыс. долл. (максимальный – 1,5 млн долл.). Решение вопросов персонифицированного доступа к конфиденциальным данным позволяет выявлять злоумышленника с помощью информации, неопровержимо доказывающей его вину. Это, в свою очередь, невозможно без применения самых современных способов аутентификации и управления доступом.

 Можно ли остановить хищение информации из баз данных?

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

Итак, имеются следующие исходные данные:

- многие не догадываются о том, что их базы данных крадут;

- кража и причиненный ущерб имеют латентный характер;

- если факт кражи данных установлен, большинство компаний замалчивают причиненный ущерб. Одна из причин этого – отсутствие реальных механизмов сбора доказательной базы по факту кражи конкретным пользователем ресурсов;

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

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

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