Введение в Базы Данных PDF

Document Details

Uploaded by Deleted User

Tags

Базы данных Система управления базами данных реляционная модель информационные системы

Summary

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

Full Transcript

1_Введение в Базы Данных База данных База данных (БД) - это данные, организованные в виде набора записей определенной структуры и хранящиеся в файлах, где, помимо самих данных, содержится описание их структуры. Oracle (Россия и СНГ) База данных — это упорядоченный набор структурированной информации...

1_Введение в Базы Данных База данных База данных (БД) - это данные, организованные в виде набора записей определенной структуры и хранящиеся в файлах, где, помимо самих данных, содержится описание их структуры. Oracle (Россия и СНГ) База данных — это упорядоченный набор структурированной информации или данных, которые обычно хранятся в электронном виде в компьютерной системе. База данных обычно управляется системой управления базами данных (СУБД). Данные вместе с СУБД, а также приложения, которые с ними связаны, называются системой баз данных, или, для краткости, просто базой данных. База данных— это совокупность взаимосвязанных, хранящихся вместе данных, которые можно обрабатывать другими программами, дополнять, модифицировать и обновлять с помощью специальных средств управления базой данных (СУБД). Ниже то, что мне показалось не нужным но на всякий: (это совокупность взаимосвязанных хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом. Данные запоминаются так, чтобы они были независимы от программ, их использующих. Для добавления новых и модификации существующих данных применяется общий управляемый способ. ) –говно как будто — представленная в объективной форме совокупность самостоятельных материалов (статей, расчётов, нормативных актов, судебных решений и иных подобных материалов), систематизированных таким образом, чтобы эти материалы могли быть найдены и обработаны с помощью электронной вычислительной машины Информационно-вычислительная система ИВС – совокупность взаимосвязанных и согласованно действующих ЭВМ или процессов и других устройств, обеспечивающих автоматизацию процессов приема, обработки и выдачи информации потребителям. Информационная система Организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы [1, ст. 2] [п. 3.1.7 ГОСТ Р 54089-2010]. Информационная система немыслима без персонала, взаимодействующего с компьютерами и телекоммуникациями. Информационная система с технической точки зрения — это взаимосвязанная совокупность средств, методов и персонала, используемых для хранения, обработки и выдачи информации в интересах достижения поставленной цели. Классификация ИВС По области применения: производство, образование, здравоохранение, торговля и т.д. По целевой функции: управляющие, информационно-справочные, поддержки принятия решений Классификация по охватываемой территории WAN, wide area network ГВС, глобальная ВС MAN, metropolitan area network РВС, региональная (городская) ВС LAN, local area network ЛВС, локальная ВС Банк данных(про это вроде не должно быть вопросов но на всякий) БнД – разновидность ИВС, в которой реализованы функции централизованного хранения и накопления обрабатываемой информации, организованной в одну или несколько баз данных. (из другого определения)В состав Б. д. входят одна или неск. баз данных, справочник баз данных, система управления базами данных, библиотеки запросов и прикладных программ, а иногда технич. и организационные средства. (БРЭ) Состав банка данных(про это вроде не должно быть вопросов но на всякий) База(ы) данных Система управления базами данных Словарь данных Администратор Вычислительная система Обслуживающий персонал Требования к БД 1. Многократное использование данных 2. Сохранение затрат умственного труда 3. Небольшие затраты на разработку 4. Уменьшение избыточности данных 5. Легкость использования 6. Простота внесения изменений 7. Достоверность 8. Конфиденциальность (секретность) 9. Защита от уничтожения и искажения 10. Готовность Целостность свойство БД, означающее, что в ней содержится полная, непротиворечивая и полностью отражающая предметную область информация. Различают целостность: Физическую (означает наличие физического доступа к данным и что данные не утрачены) Логическую (означает отсутствие логических ошибок в базе данных, к которым относятся нарушение структуры данных, ее объектов, удаление или изменение установленных связей между объектами и т.п.) Транзакция Последовательность операций над БД, рассматриваемая СУБД как единое целое. При выполнении транзакция может быть либо успешно завершена (СУБД зафиксирует изменения во внешней памяти), либо ни одно изменение не отразится в БД. Свойства транзакции: атомарность; ( Транзакция рассматривается как единая, неделимая единица работы. Это означает, что либо все операции в транзакции завершаются успешно, либо ни одна из них не применяется к базе данных) сериализуемость (отсутствует взаимное влияние)( это свойство транзакции, при котором отсутствует взаимное влияние выполняемых в одно и то же время транзакций); согласованность ( В результате выполнения транзакции база данных не будет содержать несогласованных данных. Иными словами, выполняемые транзакцией трансформации данных переводят базу данных из одного согласованного состояния в другое); долговечность (Обеспечивает сохраняемость данных. Иными словами, эффект транзакции должен оставаться действенным даже в случае системной ошибки. ). СУБД Система управления базами данных – это комплекс программных средств, предназначенных для создания, ведения и совместного использования БД многими пользователями. Программно-логический аппарат, организующий систему хранения данных, а также обеспечивающий средства занесения, обновления и выборки данных. В состав СУБД входят языки: Описания данных Манипулирования данными Структурированных запросов - SQL –Structured Query Language Запросов по образцу – QBE –Query By Example Пользователи СУБД(картинкой потому что тут важность) Доп инфа: В обязанности администратора данных входит: принимать решение, какие данные необходимо вносить в базу данных в первую очередь, а также обеспечивать поддержание порядка при обслуживании данных и использовании их после занесения в базу данных. Например, он должен указывать, кто, при каких условиях, над какими данными и какие операции может выполнять. Другими словами, он должен обеспечивать безопасность данных. Итак, администратор базы данных, в отличие от администратора данных, должен быть профессиональным специалистом в области информационных технологий. Работа АБД заключается в создании самих баз данных и техническом контроле, необходимом для осуществления решений администратора данных. АБД также несет ответственность за обеспечение необходимого быстродействия системы и ее технического обслуживания Прикладные программисты. Они отвечают за создание программ, использующих базу данных. Конечные пользователи базы данных. Работают с ней непосредственно через терминал или рабочую станцию. Как правило, имеют строго ограниченный набор привилегий манипулирования данными. Основные типы данных СУБД числовые символьные логические даты временные и дата-временные символьные переменной длины двоичные (мультимедиа данные) гиперссылки данные в xml формате Современные СУБД: Oracle MySQL MicrosoftSQL сервер PostgreSQL MongoDB31 Те которые щас не особо используются(вроде как): MariaDB DB2 SAP HANA ЛИНТЕР РЕД База Данных Модели представления данных Иерархическая Сетевая Реляционная Постреляционная Многомерная Картотека Объектно-ориентированная Типы NoSQL СУБД 1. Хранилище «ключ-значение» — в нём есть большая хеш-таблица, содержащая ключи и значения. Примеры: Riak, Amazon DynamoDB; 2. Документоориентированное хранилище — хранит документы, состоящие из тегированных элементов. Пример: CouchDB, MongoDB; 3. Колоночное хранилище — в каждом блоке хранятся данные только из одной колонки. Примеры: HBase, ApacheCassandra, Google BigTable; 4. Хранилище на основе графов — сетевая база данных, которая использует узлы и рёбра для отображения и хранения данных. Пример: Amazon Neptune, Neo4J, InfoGridи Infinite Graph. Картотека Картотека – упорядоченное собрание данных, как правило на карточках малого формата и представляет собой каталог какой-либо базы данных. Для упорядочения выбирается один какой-либо фактор. Картотека может быть внесена в электронную базу данных. Картотека, как правило, состоит из идентичных по структуре карт. Электронный аналог картотеки – таблица. Одна карта – одна строка таблицы. Реляционная модель данных Все данные, доступные пользователю, организованны в виде таблиц, а все операции над данными сводятся к операциям над этими таблицами. Свойства двумерной таблицы: каждый элемент таблицы - один элемент данных, повторяющиеся группы отсутствуют; все столбцы в таблице однородные; столбцам присваиваются однозначные имена; в таблице нет двух одинаковых строк; при выполнении операций с таблицей ее строки и столбцы можно обрабатывать в любом порядке безотносительно к их информационному содержанию. Сущность Сущность – это важная вещь или объект, информацию о котором нужно сохранить. Сущность – объект любой природы, данные о котором хранятся в базе данных Строка таблицы – экземпляр сущности. Элементы реляционной БД и их формы представления Элемент реляционной модели Форма представления Отношение Таблица Схема отношения Строка заголовков таблицы Кортеж Строка таблицы Сущность Описание свойств объекта Атрибут Заголовок столбца таблицы Первичный ключ Один или несколько атрибутов Тип данных Тип значений элементов таблицы Логическое проектирование Определение числа и структуры таблицы Формирование запросов к БД Определение типов отчетных документов Разработка алгоритмов обработки информации Создание форм для ввода и редактирования данных И т.п. Связывание таблиц (отношений) 1:1 1: М М:1 М:М 2_История развития баз данных Этапы развития баз данных Период становления – начало 60-х - начало 70-х гг. Период развития – 70-е годы. Период зрелости – 80-е годы. Постреляционный период – с начала 90-х гг. Предпосылки Избыточность данных Несогласованность данных Зависимость данных от прикладных программ Появление СУБД 1968 – первая промышленная СУБД – система IMS фирмы IBM. июнь 1970 года - «Relational Model of Data for Large Shared Data Banks» опубликована в журнале Communications of the ACM (Association for Computing Machinery) 1973 - System R 1975 – первый стандарт ассоциации по языкам систем обработки данных Conference of Data System Languages (CODASYL) Эдгар Франк Кодд E. F. Codd Инет: (британский учёный, работы которого заложили основы теории реляционных баз данных. Работая в компании IBM, он создал реляционную модель данных. В 1970 издал работу «A Relational Model of Data for Large Shared Data Banks», которая считается первой работой по реляционной модели данных. Кодд ввёл в оборот термин OLAP и написал 12 законов аналитической обработки данных. Он также занимался клеточными автоматами.) Лекция: 1970 - «Реляционная модель данных для больших, совместно используемых банков данных» 1973 - System R (запускает IBM, первая промышленная СУБДS QL/DS, выпущенная в 1981 году) 1976 - почетное звание «Человек IBM» 1981 – премия Тьюринга за создание реляционной модели и реляционной алгебры 1985 - «12 правил» 1993 – «12 принципов» и термин OLAP 2002 – реляционная модель данных, по версии «Форбс», включена в список наиважнейших инноваций за последние 85 лет. Кристофер Дейт Инет: (Один из крупнейших специалистов в области баз данных, в особенности в реляционной модели данных, независимый автор, лектор и консультант. Кристофер Дейт — автор классического учебника «Введение в системы баз данных», который как стандартный текст по системам баз данных используется во многих университетах мира. Работал над развитием реляционных СУБД совместно с Эдгаром Коддом) Лекция: Введение в системы баз данных 8-ое издание. — М.: Вильямс, 2005, C.J. Date Introduction to Database Systems — 1328 с. Этапы развития баз данных 1. На больших ЭВМ 2. Настольные СУБД (эпоха ПК) 3. Распределенные БД (интеграция, транзакции, поддержка структурной целостности, многоплатформенная архитектура, начало работ по созданию ООБД, разработка стандартов языков) 4. Интранет Особенности первого этапа Все СУБД базируются на мощных мультипрограммных операционных системах (MVS, SVM, RTE, OSRV, RSX, UNIX), поэтому в основном поддерживается работа с централизованной базой данных в режиме распределенного доступа. Функции управления распределением ресурсов в основном осуществляются операционной системой (ОС). Поддерживаются языки низкого уровня манипулирования данными, ориентированные на навигационные методы доступа к данным. Значительная роль отводится администрированию данных. Проводятся серьезные работы по обоснованию и формализации реляционной модели данных, и была созданная первая система (System R), ориентированная идеологию реляционной модели данных. Проводятся теоретические работы по оптимизации запросов и управлению распределенным доступом к централизованной БД, было введено понятие транзакции. Результаты научных исследований открыто обсуждаются в печати, идет мощный поток общедоступных публикаций, касающихся всех аспектов теории и практики баз данных, и результаты теоретических исследований активно внедряются в коммерческие СУБД. Особенности второго этапа Все СУБД были рассчитаны на создание БД в основном с монопольным доступом. И это понятно. Компьютер персональный, он не был подсоединен к сети, и база данных на нем создавалась для работы одного пользователя. В редких случаях предполагалась последовательная работа нескольких пользователей, например, сначала оператор, который вводил бухгалтерские документы, а потом главбух, который определял проводки, соответствующие первичным документам. Большинство СУБД имели развитый и удобный пользовательский интерфейс, В большинстве существовал интерактивный режим работы с БД, как в рамках описания БД, так и в рамках проектирования запросов. Кроме того, большинство СУБД предлагали развитый и удобный инструментарии для разработки готовых приложений без программирования. Инструментальная среда состояла из готовых элементов приложения в виде шаблонов экранных форм, отчетов, этикеток (Labels), графический редактор, которые действительно просто могли быть собраны в единый комплекс. Во всех настольных СУБД поддерживался только внешний уровень представления реляционной модели, то есть только внешний табличный вид структур данных. При наличии высокоуровневых языков манипулирования данными типа реляционной алгебры и SQL в настольных СУБД поддерживались низкоуровневые языки манипулирования данными на уровне отдельных строк таблиц. В настольных СУБД отсутствовали средства поддержки ссылочной и структурной целостности базы данных. Эти функции должны были выполнять приложения, однако скудость средств разработки приложений иногда не позволяла это сделать, и в этом случае эти функции должны были выполняться пользователем, требуя от него дополнительного контроля при вводе и изменении информации, хранящейся в БД. Наличие монопольного режима работы фактически привело к вырождению функций администрирования БД и в связи с этим к отсутствию инструментальных средств администрирования БД. И, наконец, последняя и в настоящий момент весьма положительная особенность -- это сравнительно скромные требования к аппаратному обеспечению со стороны настольных СУБД. Вполне работоспособные приложения, разработанные, например, на Clipper, работали на PC 286. Особенности третьего этапа Практически все современные СУБД обеспечивают поддержку полной реляционной модели, а именно: структурной целостности - допустимыми являются только данные, представленные в виде отношений реляционной модели; языковой целостности, то есть языков манипулирования данными высокого уровня (с использованием SQL); ссылочной целостности - контроля за соблюдением ссылочной целостности в течение всего времени функционирования системы, и гарантий невозможности со стороны СУБД нарушить эти ограничения. Большинство современных СУБД рассчитаны на многоплатформенную архитектуру, то есть они могут работать на компьютерах с разной архитектурой и под разными операционными системами, при этом для пользователей доступ к данным, управляемым СУБД, на разных платформах практически неразличим. Необходимость поддержки многопользовательской работы с базой данных и возможностьn децентрализованного хранения данных потребовали развития средств администрирования БД с реализацией общей концепции средств защиты данных. Потребность в новых реализациях вызвала создание серьезных теоретических трудов по оптимизации реализации распределенных БД и работе с распределенными транзакциями и запросами с внедрением полученных результатов в коммерческие СУБД. Для того чтобы не потерять клиентов, которые ранее работали на настольных СУБД, практически все современные СУБД имеют средства подключения клиентских приложений, разработанных с использованием настольных СУБД, и средства экспорта данных из форматов настольных Особенности четвертого этапа Этот этап характеризуется появлением новой технологии доступа к данным- интранет. Основное отличие этого подхода от технологии клиент-сервер состоит в том, что отпадает необходимость использования специализированного клиентского программного обеспечения. Для работы с удаленной базой данных используется стандартный браузер Internet, например Microsoft Internet Explorer, и для конечного пользователя процесс обращения к данным происходит аналогично использованию Internet. При этом встроенный в загружаемые пользователем HTML- страницы код, написанный обычно на языках Java, Java-script, Perl и других, отслеживает все действия пользователя и транслирует их в низкоуровневые SQL-запросы к базе данных, выполняя, таким образом, ту работу, которой в технологии клиент-сервер занимается клиентская программа. 3_РЕЛЯЦИОННАЯ АЛГЕБРА. Теоретико-множественные операторы Алгебра - множество объектов с заданной на нем совокупностью операций, замкнутых относительно этого множества, называемого основным множеством. Основным множеством в реляционной алгебре является множество отношений. Основная идея реляционной алгебры Поскольку отношения являются множествами, средства манипулирования отношениями могут базироваться на традиционных теоретико-множественных операциях, дополненных специальными операциями, специфичными для реляционных баз данных. Операции над отношениями Операции над множествами: объединение, пересечение, разность, деление, декартово произведение Специальные операции: проекция, соединение, выбор 2 группы языков На основе реляционной алгебры - процедурный, операнды и результаты являются отношениями; На основе реляционного исчисления – непроцедурный, описательный, запрос к БД содержит информацию о желаемом результате, для записи запросов определены правила. Операции Кодда Объединение Разность (вычитание) Пересечение Произведение Выборка (селекция, ограничение, фильтрация, горизонтальный выбор) Проекция (вертикальный выбор) Деление Соединение (сцепление, конкатенация) Совместимость структур При выполнении бинарной операции участвующие в операциях отношения должны быть совместимы по структуре Совместимость структур отношений означает совместимость имен атрибутов и типов соответствующих доменов Базовые теоретико-множественные операции Объединение Разность (вычитание) Пересечение Произведение Объединение Объединением двух совместимых отношений R1 и R2 одинаковой размерности (R1 UNION R2) является отношение R, содержащее все элементы исходных отношений за исключением повторений Вычитание Вычитание двух совместимых отношений R1 и R2 одинаковой размерности (R1 MINUS R2) есть отношение R, состоящее из множества кортежей, принадлежащих R1, но не принадлежащих R2 Пересечение Пересечение двух совместимых отношений R1 и R2 одинаковой размерности (R1 INTERSECT R2) порождает отношение R, содержащее кортежи, одновременно принадлежащие обоим подмножествам Произведение Произведение отношения R1 степени k1 и отношения R2 степени k2 (R1 TIMES R2), которые не имеют одинаковых имен атрибутов, есть такое отношение R степени (k1 + k2), заголовок которого представляет собой сцепление заголовков отношений R1 и R2, а тело имеет кортежи такие, что первые k1 элементов кортежей принадлежат множеству R1, а последние k2 элементов – множеству R2. Специальные реляционные операции Выборка (селекция, ограничение, фильтрация, горизонтальный выбор) Проекция (операция вертикального выбора) Деление Соединение (сцепление, конкатенация) Выборка Выборка (R WHERE f) представляет собой новое отношение с тем же заголовком и телом, состоящим из таких кортежей отношения R, которые удовлетворяют истинности логического выражения, заданного формулой f. Проекция Проекция отношения А на атрибуты X,Y,…,Z (A[X,Y,…,Z]), где множество {X,Y,…,Z} является подмножеством полного списка атрибутов заголовка отношения А, представляет собой отношение с заголовком X,Y,…,Z и телом, содержащим кортежи отношения А, за исключением повторяющихся кортежей Дополнительные варианты записей: Отсутствие списка атрибутов подразумевает указание всех атрибутов (тождественная проекция) R[] – пустая проекция, результат – пустое множество Операция проекции может применяться к произвольному отношению, в т.ч. и к результату выборки Деление Результатом деления отношения R1 с атрибутами А и В на отношение R2 с атрибутом В (R1 DIVIDEBY R2) , где А и В простые или составные атрибуты, причем В – атрибут общий, определенный на одном и том же домене, является отношение R с заголовком А и телом, состоящим из кортежей r таких, что в отношении R1 имеются кортежи (r,s), причем множество значений s включает множество значений атрибута В отношения R2. Соединение Общая операция соединения ϴ – соединение (тета) Эквисоединение Естественное соединение Внешнее соединение Соединение C(R1,R2) отношений R1 и R2 по условию, заданному формулой f представляет собой отношение R, которое можно получить путем декартова произведения отношений R1 и R2 с последующим применением к результату операции выборки по формуле f (R1 TIMES R2) WHERE f. ϴ – соединение Формула f имеет произвольный вид (R1 TIMES R2) WHERE A знак B JOIN Эквисоединение F задает равенство операндов, т.е. возвращаются только те записи, для которых значения указанных полей совпадают. Естественное соединение Частный случай эквисоединения Основано на операторе равенства Участвуют все общие поля В результирующий набор записей включен только один набор общих полей Обладает свойством ассоциативности Внешнее соединение OUTER JOINS Возвращает все записи, участвующие в соединении, которые возвращает внутреннее соединение плюс все записи из одного или обоих наборов данных, участвующих в соединении Левое (один из «один ко многим») Правое (все из «многих к одному») Полное (все записи) Операции Дейта Переименование (имя атрибута) Расширение (добавление нового атрибута) Подведение итогов (вертикальные вычисления) Присвоение (замена предыдущего значения отношения на новое) Вставка Обновление Удаление Реляционное сравнение Переименование RENAME AS RENAME S Город_П AS Город_размещ Расширение EXTEND ADD AS EXTEND (PJOIN SP) ADD (Вес*Кол-во) AS Общий_вес Подведение итогов SUMMARIZE BY () ADD AS SUMMARIZE SP BY (П#) ADD COUNT AS Количество_поставок Присвоение Выражение_цель ::= Выражение_источник S::= S UNION {{, , ,}} Вставка INSERT INTO INSERT (S WHERE Город П='Москва') INTO Temp Обновление UPDATE UPDATE P WHERE Тип='каленый' Город Д='Сочи' Удаление DELETE S DELETE S Where Статус надмножество Правила записи выражений Необходимо учитывать приоритет операций, который должен быть определен Существуют тождественные преобразования, позволяющие записать одно и то же выражение поразному Нужно обеспечивать совместимость участвующих в выражении отношений Реляционное исчисление Для получения результата необходимо указать свойства искомого отношения без конкретизации его получения Запрос Получить номера и города поставщиков, выпускающих деталь Р2 Реляционная алгебра Образовать естественное соединение отношений S и SP по атрибуту П# Выбрать из результата этого соединения кортежи с деталью Р2 Спроецировать результат предыдущей операции на атрибуты П# и Город_П Реляционное исчисление Получить атрибуты П# и Город_П для таких поставщиков, для которых существует поставка в отношении SP с тем же значением атрибута П# и со значением Р2 атрибута Д# Варианты исчислений Исчисление кортежей Исчисление доменов Исчисление кортежей RANGE of IS Кортежные переменные При использовании кортежных переменных в формулах можно ссылаться на значение атрибута переменной. Например, для того, чтобы сослаться на значение атрибута Имя переменной ПОСТАВЩИК, нужно употребить конструкцию ПОСТАВЩИК.Имя. Использование кванторов Правильно построенные формулы служат для выражения условий, накладываемых на кортежные переменные. Их основой являются простые сравнения. Более сложные варианты формул строятся с помощью логических связок NOT, AND, OR и IF... THEN. Допускается построение формул с помощью кванторов (существования EXISTS и всеобщности FORALL). Свободные переменные Все переменные, входящие в формулу, при построении которой не использовались кванторы, являются свободными. Т.е. если для какого-то набора значений свободных кортежных переменных при вычислении формулы получено значение true, то эти значения кортежных переменных могут входить в результирующее отношение. Связанные переменные Если имя переменной использовано сразу после квантора при построении формулы вида EXISTS var (form) или FORALL var (form), то в этой формуле и во всех формулах, построенных с ее участием, var - это связанная переменная. Такая переменная не видна за пределами минимальной формулы, связавшей эту переменную. При вычислении значения такой формулы используется не одно значение связанной переменной, а вся ее область определения. Исчисление доменов Дополнительная форма условия – условие принадлежности Лакроикс и Пироттс 4_Проектирование БД Модель представления данных - логическая структура хранимых в базе данных Основные принципы разработки: 1. Независимость данных - означает возможность изменения логической или физической структуры БД без влияния на приложения, которые с ней работают. Это разделение на логический и физический уровни позволяет минимизировать затраты на обслуживание и обновление базы данных 2. Формирование и поддержка связей между данными Использование первичных и внешних ключей помогает установить четкие ассоциации между таблицами 3. Неизбыточность данных Минимизация избыточности снижает объем хранимой информации и вероятность возникновения аномалий при обновлении, удалении или добавлении данных. Это достигается через нормализацию и корректное проектирование отношений между таблицами 4. Защита и сохранность данных Защита данных включает контроль доступа, аутентификацию и шифрование для предотвращения несанкционированного доступа 5. Прямой доступ к данным Прямой доступ позволяет приложениям эффективно извлекать данные из БД без сложных посредников, что улучшает производительность системы. 12 принципов Кодда: 1. Информация логически представлена в виде таблиц. 2. Логический доступ к данным должен осуществляться по таблице, первичному ключу и столбцу. 3. Пустые значения нужно всегда рассматривать как «отсутствие информации», а не как пустые строки, пробелы или нули. 4. Метаданные (данные о базе данных) должны храниться в базе данных, как и все прочие данные 5. Для определения данных, представлений, ограничений по целостности, авторизации, транзакций и манипуляций должен использоваться один язык. 6. В представлениях должны отображаться обновления, вносимые в таблицы базы и наоборот. 7. Каждое из приведенных действий должно осуществляться при помощи одной отдельной операции: извлечение данных, вставка данных, обновление данных и удаление данных. 8. Пакетные операции и операции конечных пользователей логически отделены от физических методов хранения и доступа. 9. Пакетные операции и операции конечных пользователей могут изменять схему базы данных без необходимости повторного создания базы и приложений, построенных на ее основе. 10. Ограничения, обеспечивающие целостность данных, должны храниться в метаданных, а не в прикладной программе. 11. Язык манипулирования данными реляционной системы не должен учитывать, где и как распределены данные физически, и не должен требовать внесения изменений в зависимости от того, являются данные централизованными или распределенными. 12. Любой процесс обработки строк в системе должен подчиняться правилам обеспечения целостности данных и ограничениям, которым подчиняются процессы обработки наборов данных. Элементы реляционной БД: Записано в виде: Элемент реляционной модели - Форма представления Отношение - Таблица Схема отношения - Строка заголовков таблицы Кортеж - Строка таблицы Сущность - Заголовок таблицы Атрибут - Заголовок столбца таблицы Первичный ключ - Один или несколько атрибутов Тип данных - Тип значений элементов таблицы Логическое проектирование: Определение числа и структуры таблицы Формирование запросов к БД Определение типов отчетных документов Разработка алгоритмов обработки информации Создание форм для ввода и редактирования данных Подходы при проектировании структур данных: Сбор информации в рамках одной таблицы и последующая ее декомпозиция (процесс разбиения одной таблицы на несколько связанных между собой таблиц с целью устранения избыточности данных) на основе процедуры нормализации отношений Формулирование знаний о системе и требований к обработке данных в ней, полученные с помощью Case-систем (программные инструменты для автоматизации процессов анализа, проектирования баз данных: построение ER-диаграмм, автоматическая генерация SQL-кода для создания таблиц) Структурирование информации для проведения системного анализа на основе совокупности правил и рекомендаций Зависимости между атрибутами: Функциональные o В функционально зависит от А, если каждому А в точности соответствует одно В) А->В o Функциональная взаимозависимость АВ o Частичная зависимость – зависимость атрибута от части составного ключа Составной ключ - это первичный ключ таблицы, который состоит из двух или более атрибутов, вместе образующих уникальную идентификацию каждой строки. Представьте, что в одном магазине может быть одна продажа за день, тогда: o Полная зависимость – неключевого атрибута от всего составного ключа Транзитивные o A->B->C (Фио->Должность->Оклад) Если "ФИО сотрудника" определяет "Должность", а "Должность" определяет "Оклад", то "Оклад" зависит от "ФИО" через "Должность" o Проблемы: - Избыточное (явное и неявное) дублирование - таблица содержит повторяющиеся значения, например, одна и та же информация о названии продукта хранится в каждой строке продаж - Неизбыточное дублирование - повторения сведены к минимуму через разбиение данных на связанные таблицы - Аномалии (ситуация в таблицах БД, которая приводит к противоречиям): модификации, удаления и добавлении Многозначные: o A=>B - каждому значению A может соответствовать несколько значений B Если A - "Студент", а B - "Курс", то одному студенту могут быть назначены несколько курсов o A Y), если в любом экземпляре схемы R каждому значению атрибута X (левая часть зависимости) в каждый момент времени соответствует точно одно значение Y (правая часть зависимости) Выявление зависимости между атрибутами: Основной способ – анализ семантики атрибутов (процесс изучения значений и взаимосвязей атрибутов таблицы для понимания их роли в предметной области и определения зависимостей между ними) Если в некотором отношении существует одна или несколько функциональных зависимостей, то можно вывести другие функциональные зависимости в этом отношении Метод «сущность связь»: Метод «ER-диаграмм» Essence – сущность Relation – связь Основные понятия метода: Сущность - это объект или элемент, который хранит данные в базе (например, «Магазин», «Товар») Атрибут сущности - атрибут описывает свойства сущности и представляет отдельное поле данных (например, атрибуты сущности «Товар»: «Название», «Цена», «Код») Ключ сущности - уникальный идентификатор, который позволяет однозначно идентифицировать каждый экземпляр сущности («Код товара») Связь между сущностями - связь указывает на отношения между двумя или более сущностями (например, «Покупатель заказывает Товар») Степень связи - определяет количество сущностей, участвующих в отношении («Клиент» оформляет «Заказ» - степень 2, «Продавец» поставляет «Товар» на «Склад» - степень 3) Класс принадлежности экземпляров сущности - указывает, обязательны ли экземпляры сущности для участия в связи (обязательная/необязательная) - Обязательная: связь: «Клиент оформляет Заказ». Каждый клиент должен оформить хотя бы один заказ. - Необязательная: связь: «Клиент участвует в Промо-акции». Здесь не обязательно, чтобы каждый клиент участвовал в промо-акции. Диаграммы ER-экземпляров - диаграммы, на которых показаны конкретные экземпляры сущностей и связей (например, клиент Иванов связан с заказом №123) Диаграммы ER-типа - обобщённые диаграммы, описывающие типы сущностей, их атрибуты и связи между ними, без привязки к конкретным данным Этапы проектирования: Выделение сущностей и связей между ними Построение диаграмм ER-типа Формирование набора предварительных отношений Добавление неключевых атрибутов в отношения Приведение предварительных отношений к нормальной форме Пересмотр ER-диаграмм Правила формирования отношений: Связь 1:1 o Правило 1. Если класс принадлежности сущностей О:О, то формируется одно отношение Пример: Сущности: "Паспорт" и "Гражданин". Каждый гражданин должен иметь один паспорт, и каждый паспорт должен быть выдан одному гражданину o Правило 2. Если класс принадлежности сущностей О:Н, то под каждую из сущностей формируется отношение. Далее к отношению с обязательным КП (класс принадлежности) добавляется ключ сущности с необязательным КП Пример: Сущности: "Клиент" и "Лояльная программа". Каждый клиент должен иметь связь с программой лояльности, но не все клиенты обязательно участвуют в программе лояльности. Два отношения: одно для клиентов (обязательное участие), второе для программы лояльности с дополнительным атрибутом, указывающим, принимает ли конкретный клиент участие в программе (необязательная связь) o Правило 3. Если класс принадлежности сущностей Н:Н, то необходимо использовать 3 отношения Связь 1:М o Правило 4. Если класс принадлежности М-связной сущности О, то формируются два отношения. Ключ односвязной сущности добавляется как атрибут в отношение. Пример: Сущности: "Заказ" и "Клиент". Каждый заказ принадлежит одному клиенту, но один клиент может сделать несколько заказов. Два отношения: одно для клиентов, другое для заказов, где в таблице заказов будет ключ клиента o Правило 5. Если класс принадлежности М-связной сущности Н, то необходимо формирование трех сущностей Пример: Сущности: "Отдел" и "Сотрудник". Каждый отдел имеет несколько сотрудников. Каждый сотрудник работает только в одном отделе, но он может не иметь обязательной привязки к отделу. Три сущности: таблица "Отделы", таблица "Сотрудники", связующая таблица Связь М:М o Правило 6. Независимо от класса принадлежности необходимо использовать 3 отношения Пример: Сущности: "Студент" и "Курс". Студенты могут записываться на несколько курсов, а каждый курс может быть посещен несколькими студентами. Три отношения: одно для студентов, одно для курсов, связь между ними (указывает, какие студенты записаны на какие курсы) Вторичный индекс Строится по полям таблицы Не уникален Не обязателен Повышает производительность при поиске и сортировке данных Замедляет модификацию и увеличивает размер таблицы Уникальный идентификатор (Первичный ключ) это поле для однозначной идентификации записи Ключ должен быть уникальным Ключ должен иметь значение отличное от нуля В течение всего времени существования экземпляра его ключ не меняется Первичный ключ обеспечивает: o Однозначную идентификацию полей таблицы o Предотвращение повторений значений ключей o Ускорение выполнения запросов к БД o Установление связи между таблицами БД o Использование ограничений ссылочной целостности Связи: Связь описывает бинарное состояние между двумя сущностями Связь бывает рекурсивной (внутри одной сущности) У каждой стороны связи есть имя Связывание таблиц o 1:1 o 1: М o М:1 o М:М Разрешение связи М:М : - Сделать новую сущность (Сущность-связку) - Связать сущность с двумя исходными - Ввести уникальный идентификатор (можно объединив пару) Методология логического проектирования данных: 1. Выявить и смоделировать сущности 2. Выявить с смоделировать связи между сущностями 3. Выявить и смоделировать атрибуты 4. Указать уникальный идентификатор для каждой сущности 5. Провести нормализацию Проектирование физической базы данных: Объекты становятся таблицами Атрибуты становятся колонками, для них подбирается тип данных Уникальные идентификаторы становятся первичными ключами Отношения моделируются в виде внешних ключей Аксиомы вывода функциональных зависимостей (1): Рефлексивность: Эта аксиома утверждает, что любой набор атрибутов функционально зависит сам от себя. Например, если есть набор атрибутов, то этот набор всегда будет функционально зависеть от самого себя. Это свойство гарантирует, что каждый атрибут или группа атрибутов могут быть уникально определены самими собой. Пополнение: Если существует функциональная зависимость между двумя наборами атрибутов, то добавление новых атрибутов к обеим сторонам зависимости не нарушит этой зависимости. Таким образом, зависимость сохраняется, даже если мы расширим наборы атрибутов с обеих сторон. Это свойство позволяет добавлять дополнительные атрибуты, не меняя сущность зависимости. Транзитивность: Если один набор атрибутов функционально зависит от другого, а этот второй набор, в свою очередь, функционально зависит от третьего набора, то первый набор также будет функционально зависеть от третьего. Это означает, что если один атрибут определяет другой, а тот, в свою очередь, определяет третий, то первый атрибут будет определять третий. Расширение: Если существует функциональная зависимость между двумя наборами атрибутов, то добавление одинаковых атрибутов с обеих сторон не изменяет зависимость. Это свойство позволяет "расширять" зависимость, добавляя новые атрибуты, не нарушая существующую логику. Продолжение: Если один набор атрибутов функционально зависит от другого набора, а тот, в свою очередь, зависит от третьего, то можно распространить зависимость на дополнительные атрибуты. Например, если первый набор атрибутов зависит от второго, а второй от третьего, то можно утверждать, что первый набор также зависит от третьего, добавив дополнительные атрибуты. Псевдотранзитивность: Это разновидность транзитивности, в которой зависимость между атрибутами сохраняется, даже если добавляются дополнительные атрибуты в обе стороны. Эта аксиома аналогична транзитивности, но она допускает использование дополнительных атрибутов при продолжении зависимости, что делает зависимость более гибкой. Объединение: Если один набор атрибутов функционально зависит от двух разных наборов атрибутов, то можно объединить эти зависимости в одну, при этом зависимость будет охватывать все атрибуты. Это свойство позволяет уменьшить количество зависимостей, объединив несколько зависимостей в одну, более общую. Декомпозиция: Если один набор атрибутов функционально зависит от нескольких атрибутов, то эту зависимость можно разделить на несколько зависимостей, каждая из которых будет зависеть от отдельного атрибута. Это свойство позволяет разбить сложные зависимости на более простые, чтобы лучше управлять ими в процессе нормализации базы данных. Проектирование баз данных методом нормальных форм (НФ): 1 НФ Отношение находится в 1НФ, если все его атрибуты являются простыми (имеют единственное значение) В данном случае поле "Курсы" не является атомарным, так как оно содержит несколько значений. Чтобы привести таблицу в 1НФ, нужно разделить курс на отдельные строки. 2 НФ Отношение находится в 2НФ, если оно находится в 1НФ и каждый неключевой атрибут функционально полно зависит от первичного ключа В этой таблице "Название товара" зависит только от "Код товара", а не от всего первичного ключа (Код продажи, Код товара). Это частичная зависимость, и таблица не находится во 2НФ. Для приведения к 2НФ нужно создать отдельную таблицу для товаров (код товара, название товара) 3 НФ Отношение находится в 3НФ, если оно находится в 2НФ и ни один неидентифицирующий атрибут не зависит от каких-либо других неидентифицирующих атрибутов (нет транзитивных зависимостей) В таблице "Сумма" зависит от "Цена товара" и "Количество", то есть, существует транзитивная зависимость между атрибутами. Создать таблицу продажи (код прод, код товара, кол-во), таблица товара (код товара, цена), таблица сумма (код прод, сумма) 3-ая усиленная НФ Отношение находится в БКНФ (3-ей усиленной НФ), если оно находится в 3НФ и в нем отсутствуют зависимости ключей от неключевых атрибутов 4 НФ Отношение находится в 4НФ в том и только том случае, когда существует многозначная зависимость А=> В, а все остальные атрибуты отношения функционально зависят от А Здесь "Товары" и "Поставщики" зависят от "Код магазина", но их зависимости независимы. Для 4НФ нужно разделить таблицу на несколько, чтобы избежать таких зависимостей. 5 НФ Отношение находится в 5НФ (или нормальной форме проекции соединения) в том и только том случае, когда любая зависимость соединения в R следует из существования некоторого возможного ключа в R Пример 5НФ: Если у вас есть таблица, которая хранит информацию о продавцах, клиентах и товарах, то это может привести к ненужному дублированию данных, если таблица будет иметь слишком много соединений. 5НФ устраняет такие избыточности, разбивая таблицу на более мелкие связи. Теорема Фейджинга Отношение R (A,B,C) можно спроецировать без потерь в отношении R1 (A,B) и R2 (A,C) в том и только том случае, когда существует зависимость A =>B|C. теорема Фейджинга утверждает, что при наличии такой зависимости A⇒B∣C, можно безопасно разделить таблицу на два отношения без потерь информации. Целостность - свойство БД, означающее, что в ней содержится полная, непротиворечивая и полностью отражающая предметную область информация. Логическая и физическая целостность Ограничения целостности: Ограничения значений атрибутов отношений (недопустимость пустых или повторяющихся отношений) Структурные ограничения на кортежи отношений (любой кортеж отношений должен быть отличим от другого кортежа этого отношения) Внешний ключ -> первичный ключ 7_SQL SQL SQL (Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных. Является информационно-логическим языком, а не языком программирования. Основан на реляционном исчислении ИСТОРИЯ В начале 1970-х годов в компании IBM была разработана экспериментальная СУБД «System R» на основе языка SEQUEL (Structured English Query Language — структурированный английский язык запросов). В 1981 году IBM объявила о своём первом основанном на SQL программном продукте — SQL/DS. в 1986 году первый стандарт языка SQL был принят ANSI (American National Standards Institute) в 1987 году первый стандарт языка SQL был принят ISO (Международной организацией по стандартизации) в (SQL level 1) и уточнён в 1989 году (SQL level 2). 1992 г. - новый расширенный стандарт (ANSI SQL-92 или SQL-2). 1999 г. - следующий стандарт SQL-99 2003 г. - SQL-3 2008 г. - действует в настоящее время ПРЕИМУЩЕСТВА Независимость от конкретной СУБД Наличие стандартов Полноценность как языка для управления данными НЕДОСТАТКИ Нереляционность Сложность Отступления от стандартов Сложность работы с иерархическими структурами ЯЗЫК SQL ДЕЛИТСЯ НА ТРИ ЧАСТИ: операторы определения данных (Data Definition Language, DDL) операторы манипуляции данными (Data Manipulation Language, DML) операторы определения доступа к данным (Data Control Language, DCL) МЕТОДЫ ИСПОЛЬЗОВАНИЯ SQL Статический (в тексте программы имеются вызовы функций языка SQL, которые жестко включаются в выполняемый модуль после компиляции) Динамический (динамическое построение вызовов SQL-функций и интерпретация этих вызовов) ПРЕДСТАВЛЕНИЕ - таблица, формируемая в результате выполнения запроса. КУРСОР указатель, используемый для перемещения по наборам записей при их обработке. В описательной части – связывание переменной типа CURSOR с оператором SQL; в выполняемой – открытие курсора (OPEN), перемещение (FETCH), сопровождение обработкой и закрытие (CLOSE). КОМАНДЫ ЯЗЫКА DDL CREATE TABLE, ALTER TABLE, DROP TABLE, CREATE INDEX, ALTER INDEX, DROP INDEX. CREATE TABLE, CREATE VIEW, CREATE PROCEDURE, CREATE TRIGGER, CREATE USER, CREATE ROLE… КОМАНДЫ ЯЗЫКА DML INSERT, UPDATE, DELETE. КОМАНДЫ ЯЗЫКА DСL GRANT REVOKE SET ROLE SELECT Выборка данных (DQL) КОМАНДЫ УПРАВЛЕНИЯ ТРАНЗАКЦИЯМИ COMMIT, ROLLBACK, SAVEPOINT, SET TRANSACTION. ЗАПИСЬ SQL-ОПЕРАТОРОВ ::= {|}[...n] идентификатор может иметь длину до 128 символов; идентификатор должен начинаться с буквы; идентификатор не может содержать пробелы. 10_SQL Индексы Индекс – это набор ссылок, упорядоченных по определенному столбцу таблицы, который в данном случае будет называться индексированным столбцом. Хотя индекс и связан с конкретным столбцом (или столбцами) таблицы, все же он является самостоятельным объектом базы данных. Физически индекс –всего лишь упорядоченный набор значений из индексированного столбца с указателями на места физического размещения исходных строк в структуре базы данных. типы индексов кластерные индексы; некластерные индексы; уникальные индексы. Некластерные индексы – наиболее типичные представители семейства индексов, они не перестраивают физическую структуру таблицы, а лишь организуют ссылки на соответствующие строки. Кластерный индекс При его определении в таблице физическое расположение данных перестраивается в соответствии со структурой индекса. Логическая структура таблицы в этом случае представляет собой скорее словарь, чем индекс. Данные в словаре физически упорядочены, например по алфавиту. Уникальный индекс является своеобразной надстройкой и может быть реализован как для кластерного, так и для некластерного индекса. В одной таблице может существовать один уникальный кластерный и множество уникальных некластерных индексов. Способы определения индекса ⁃ автоматическое создание индекса при создании первичного ключа; ⁃ автоматическое создание индекса при определении ограничения целостности UNIQUE; ⁃ создание индекса с помощью команды CREATE INDEX. Создать уникальный кластерный индекс для таблицы Клиент по столбцу Фамилия в первичной группе файлов. CREATE UNIQUE CLUSTERED INDEX index_klient1 ON Клиент (Фамилия) WITH DROP_EXISTING ON PRIMARY 11_(SQL)Безопасность SQL(ОСНОВНЫЕ МЕТОДЫ ЗАЩИТЫ ДАННЫХ) СИСТЕМА УПРАВЛЕНИЯ ПОЛЬЗОВАТЕЛЯМИ - обязательное условие безопасности данных, хранящихся в любой реляционной СУБД. СОЗДАНИЕ ПОЛЬЗОВАТЕЛЕЙ(после проектирования логической структуры базы данных, связей между таблицами, ограничений целостности) o УРОВНИ ДОСТУПА 1. на первом уровне необходимо создать учетную запись пользователя (login) 2. на втором уровне для каждой базы данных SQL-сервера на основании учетной записи необходимо создать запись пользователя (user). Пример: в SQL Server(в 2 этапа) В MySQL учетная запись пользователя создается с помощью команды CREATE USER. В отличие от SQL Server, в MySQL учетная запись сразу включает как уровень сервера, так и доступ к базам данных.(т.е 2 в 1) o РОЛЬ ( Дополнительный объект базы данных, который определяет уровень доступа к объектам баз данных или базам данных) Больше ничего не написано, но там ссылка на сайт – осн.информация с ссылки про SQL Server там 1. Существует два типа ролей уровня базы данных: предопределенные роли базы данных, предопределенные в базе данных и определяемые пользователем роли базы данных, которые можно создать. 2. Фиксированные роли базы данных определяются на уровне базы данных и существуют в каждой базе данных. ссылка : Роли уровня базы данных - SQL Server | Microsoft Learn НА УРОВНЕ СЕРВЕРА : Аутентификация (и идентификация); учетная запись; встроенные роли сервера. НА УРОВНЕ БАЗЫ ДАННЫХ: пользователь базы данных; фиксированная роль базы данных; пользовательская роль базы данных Создание пользователей и ролей: Команды: sp_addlogin, sp_adduser, sp_addrole, sp_addrolemember. Определение привилегий через GRANT. Привилегии: ПРИВИЛЕГИЯМИ или правами, называются действия, которые пользователь имеет право выполнять в отношении данной таблицы базы данных или представления. GRANT (для предоставления пользователям или ролям определенных прав доступа к объектам базы данных.) REVOKE(для отзыва прав доступа, которые ранее были предоставлены с помощью команды GRANT) Если Вы даете привилегии пользователю, который не существует, он будет автоматически создан Основные: SELECT – право выбирать данные из таблицы; o INSERT – право вставлять в таблицу новые строки; o UPDATE – право изменять данные в таблице; o DELETE – право удалять строки из таблицы; o REFERENCES – право ссылаться на столбцы указанной таблицы в описаниях требований поддержки целостности данных; o USAGE – право использовать домены, проверки и наборы символов. Конфликты разрешений решаются с учетом явных запретов (DENY). SQL Server возможна ситуация, когда пользователь одновременно получает разрешение и запрет на одно и то же действие с объектом, но от разных ролей или групп. Такой сценарий называется конфликтом доступа. Пример конфликта доступа: 1. Наследование прав от ролей/групп: o Пользователь User1 является членом двух ролей: ▪ RoleA — предоставляет разрешение GRANT SELECT на таблицу Sales. RoleB — имеет явное запрещение DENY SELECT на ту же таблицу. ▪ 2. Возникновение конфликта: o User1 наследует разрешение от RoleA, но также наследует запрет от RoleB. o В итоге возникает конфликт между GRANT и DENY. 3. Как SQL Server разрешает конфликт: o DENY имеет приоритет над GRANT. Это означает, что если где-либо задано DENY, пользователь потеряет доступ, даже если у него есть разрешение через другую роль или группу. УРОВНИ ПРИВИЛЕГИЙ o Глобальный уровень (Global level) Глобальные привилегии обращаются ко всем базам данных на данном сервере. Таблица mysql.user o Уровень баз данных (Database level) Привилегии баз данных обращаются ко всем таблицам в данной базе данных. Таблицы mysql.db и mysql.host. o Уровень таблиц (Table level) Привилегии таблиц обращаются ко всем столбцам в данной таблице. Таблица mysql.tables_priv. Уровень столбцов (Column level) Привилегии столбцов обращаются к одиночным столбцам в данной таблице. Таблица mysql.columns_priv. ОБЩИЕ ПРИНЦИПЫ ЗАЩИТЫ: 1. НИКТО И НИКОГДА (кроме пользователя MySQL ROOT) НЕ ДОЛЖЕН ИМЕТЬ ДОСТУП К ТАБЛИЦЕ user В БАЗЕ ДАННЫХ mysql! 2. Изучите систему привилегий доступа MySQL. Команды GRANT и REVOKE используются для управления доступом к MySQL. Не предоставляйте большие привилегии, чем необходимо. Попробуйте mysql -u root. Если Вы способны соединиться успешно с сервером без запроса о пароле, Вы имеете проблемы. Любой может полными привилегиями! 3. Поставьте пароль пользователя 4. Используйте команду SHOW GRANTS и проверьте, кто имеет доступ к какой базе данных. Удалите те привилегии, которые не являются необходимыми, с помощью команды REVOKE. 5. Не храните никакие пароли открытым текстом в Вашей базе данных. Взамен используйте MD5() или другую одностороннюю хеш-функцию. 6. Выбирайте хорошие пароли. (pupsik и 12345) 7. Поставьте firewall. Он защищает Вас от, по крайней мере, 50% всех типов дырок в любом программном обеспечении. Поместите MySQL за firewall или в демилитаризированной зоне (DMZ). 8. Не доверяйте никаким данным, введенным Вашими пользователями. 9. Также не забудьте проверять числовые данные. Иногда помогает заключить все числовые значения в апострофы. 10. Не передавайте нешифрованные данные через Internet 11. Используйте пароли для всех пользователей MySQL. 12_SQL(Курсоры) SQL (РАЗНОЕ) Курсор в SQL Курсор — это область памяти базы данных, предназначенная для хранения последнего SQL-оператора. Используется для работы с выборкой данных построчно. курсоры сервера действуют на сервере и реализуют программный интерфейс приложений для ODBC, OLE DB, DB_Library; Основные действия при работе с курсором Создание и объявление (DECLARE). Открытие ,т.е. наполнение его данными, которые сохраняются в многоуровневой памяти (OPEN). Выборка данных и изменение с его помощью строк данных; (FETCH). Закрытие ,после чего он становится недоступным для пользовательских программ; (CLOSE). Освобождение курсора, т.е. удаление курсора как объекта, поскольку его закрытие необязательно освобождает ассоциированную с ним память. (DEALLOCATE). Категории курсоров Последовательные и прокручиваемые. Статические, динамические, управляемые ключами. Команды для управления курсором DECLARE — объявление курсора. OPEN — открытие курсора. FETCH — выборка данных из курсора. CLOSE — закрытие курсора. DEALLOCATE — освобождение курсора. Хранимые процедуры Хранимая процедура — это набор SQL-команд, сохраняемых в БД в откомпилированном виде. Виды процедур: системные, пользовательские, временные. Этапы создания хранимой процедуры Определение типа процедуры. Планирование прав доступа. Определение параметров. Разработка кода процедуры. Пример создания хранимой процедуры CREATE PROC my_proc AS UPDATE Товар SET Цена = Цена * 0.9 WHERE Сорт = 'Первый'. Триггеры в SQL Триггер – это откомпилированная SQL-процедура, исполнение которой обусловлено наступлением определенных событий внутри реляционной базы данных. Используются для поддержания целостности данных. каждый триггер привязывается к конкретной таблице. ЦЕЛИ, ДОСТИГАЕМЫЕ С ПОМОЩЬЮ ТРИГГЕРОВ: проверка корректности введенных данных и выполнение сложных ограничений целостности данных; выдача предупреждений, напоминающих о необходимости выполнения некоторых действий при обновлении таблицы; накопление аудиторской информации посредством фиксации сведений о внесенных изменениях и тех лицах, которые их выполнили; поддержка репликации. Типы триггеров INSERT TRIGGER — пр?

Use Quizgecko on...
Browser
Browser