Базы данных

Get Started. It's Free
or sign up with your email address
Базы данных by Mind Map: Базы данных

1. Вопросы к экзаменам

1.1. 1. Основные определения теории баз данных

1.1.1. БД - совокупность данных, отображающих состояние объектов в рассматриваемой предметной области.

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

1.1.3. Объект - нечто существующее и различимое.

1.1.4. Атрибут - столбец.

1.1.5. Домен - совокупность атрибутов.

1.1.6. Связь - показывает как экземпляры сущности взаимодействуют между собой.

1.1.7. Теорию БД в 2-х словах не опишешь (см. в гугле database theory).

1.2. 2. Классификация баз данных

1.2.1. По технологии:

1.2.1.1. 1. Централизованная (один ПК - все в 1 файле).

1.2.1.2. 2. Распределенная (2+ ПК)

1.2.2. По способу доступа:

1.2.2.1. 1. Файл-сервер - файл хранится на сервере и выдается без обработки.

1.2.2.2. 2. Клиент-сервер - обработка данных производится на сервере.

1.3. 3. Основные свойства СУБД и баз данных

1.3.1. СУБД - совокупность языковых и программных средств, предназначенных для создания, ведения и использования БД.

1.3.2. БД делятся:

1.3.2.1. По модели:

1.3.2.1.1. Иерархические

1.3.2.1.2. Реляционные

1.3.2.1.3. Сетевые

1.3.2.1.4. Объектно-ориентированные

1.3.2.2. По содержимому

1.3.2.3. По объему

1.4. 4. Иерархическая модель данных

1.4.1. Представление БД в виде древовидной структуры, состоящей из объектов (данных) различных уровней.

1.4.1.1. Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня.

1.4.1.2. Обязателен один предок, не более.

1.4.2. Недостатки:

1.4.2.1. Неэффективна.

1.4.2.2. Громоздкость.

1.4.3. Деревья бывают:

1.4.3.1. Сбалансированными.

1.4.3.2. Несбалансированными.

1.4.3.3. Двоичными (не более 2-х ветвей для одного узла.

1.5. 5. Сетевая модель данных

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

1.5.1.1. Пример.

1.5.2. Преимущества:

1.5.2.1. Быстродействие по сравнению с иерарх. бд.

1.5.2.2. Гибкость - множество связей.

1.5.3. Недостатки:

1.5.3.1. Жесткость - поменяешь одну связь, придется перестраивать всю бд.

1.5.3.2. Сложность - сложная структура памяти.

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

1.6.1. Логическая модель данных, прикладная теория построения баз данных. «Реляционный» означает, что теория основана на математическом понятии отношение (relation). На реляционной модели данных строятся реляционные базы данных.

1.6.2. Основные понятия реляционной БД:

1.6.2.1. Домен - совокупность допустимых значений.

1.6.2.2. Кортеж - таблица, строки.

1.6.2.3. Кардинальность - количество строк в таблице.

1.6.2.4. Атрибут - поле, столбец таблицы.

1.6.2.5. Степень отношения - количество полей.

1.7. 7. Объектно-ориентированная модель данных

1.7.1. БД, в которой данные моделируются в виде объектов, их атрибутов, методов и классов.

1.7.1.1. Используются тогда, когда требуется высокопроизводительная обработка данных, имеющих сложную структуру.

1.7.2. В БД хранятся объекты, а не голые данные как в реляционных БД.

1.7.3. В настоящее время для ООБД нет стандартизированного языка запросов и нет математического аппарата, как в реляц. БД (реляц. отношения).

1.8. 8. Анализ предметной области при проектировании баз данных

1.8.1. При проектирование БД решаются 2 основные проблемы:

1.8.1.1. Отображение объектов предметной области в абстрактные объекты модели данных таким образом, чтобы это отображение не противоречило семантике предметной области, и было по возможности лучшим (эффективным, удобным и т.д.).

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

1.8.2. Проблема проектирования реляционной базы данных состоит в обоснованном принятии решений о том, из каких отношений (таблиц) должна состоять БД и какие атрибуты (характеристики и свойства) должны быть у этих отношений.

1.8.3. В ходе анализа предметной области необходимо:

1.8.3.1. Уяснить и указать назначение базы данных;

1.8.3.2. Определить и выделить первоначальный набор сущностей и атрибутов предметной области.

1.9. 9. Модель данных сущность-связь, ER-диаграмма

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

1.9.2. Моделирование предметной области в этом случае базируется на использовании графических диаграмм - ER диаграмм.

1.9.2.1. Во время проектирования баз данных происходит преобразование ER-модели в конкретную схему базы данных на основе выбранной модели данных (реляционной, объектной, сетевой или др.).

1.9.3. ER модель должна определить объекты и взаимосвязи между ними, т.е. установить связи следующих 2х видов:

1.9.3.1. Связи между объектами и наборами свойств, и таким образом определить сами объекты.

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

1.9.4. Существует 3 основных понятия.

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

1.9.4.2. Связь - показывает как экземпляры сущности взаимодействуют между собой.

1.9.4.3. Атрибут - наименование столбца, единичный домен

1.10. 10. Виды связей модели данных сущность-связь

1.10.1. Связь - показывает как экземпляры сущности взаимодействуют между собой.

1.10.1.1. Существует 3 вида связей:

1.10.1.1.1. 1. Один к одному - каждому экземпляру сущности A соответствует один экземпляр сущности B.

1.10.1.1.2. 2. Один ко многим - 1A ко многим B.

1.10.1.1.3. 3. Многие ко многим - много A, много B, все дела.

1.11. 11. Ключевые атрибуты

1.11.1. В БД среди множества атрибутов должна быть такая совокупность, которая отличает один экземпляр сущности от другого, такая совокупность называется ключом.

1.11.1.1. Ключ - минимальный набор атрибутов однозначно идентифицирующий набор сущностей.

1.11.1.1.1. Если ключ содержит 1 атрибут - он называется атомарным или элементарным, если несколько то составным.

1.11.1.1.2. Сущность может иметь несколько ключей, их называют возможными. Среди возможных выбирают 1 - первичный.

1.12. 12. Отношения и их свойства

1.12.1. В учебнике на стр. 98+ может быть что-то полезное по этому вопросу.

1.12.2. Ранг (арность отношений) - число столбцов в таблице.

1.12.3. Операции над отношениями:

1.12.3.1. 1. Объединение.

1.12.3.2. 2. Пересечение

1.12.3.3. 3. Разность

1.12.3.4. 4. Декартово произведение

1.12.3.5. 5. Деление

1.12.3.6. 6. Проекция

1.12.3.7. 7. Селекция

1.12.3.8. 8. Соединение

1.12.3.9. 9. Естественное соединение

1.13. 13. Операция объединения отношений

1.13.1. Бинарная операция для выполнения которой отношения A и B должны иметь одинаковый перечень атрибутов.

1.13.1.1. Возвращает отношение, содержащее все кортежи, которые принадлежат либо одному отношению, либо обоим.

1.13.1.2. Проще говоря, соединяются 2 таблицы. Повторяющиеся элементы в результате объединяются и не повторяются.

1.14. 14. Операция пересечения отношений

1.14.1. Бинарная операция для выполнения которой отношения А и В должны иметь одинаковый перечень атрибутов.

1.14.1.1. Результатом является отношение с теми же атрибутами что А и В, которое содержит кортежи принадлежащие и А и В.

1.14.1.2. В результате в отношении будут только повторяющиеся кортежи (строки)

1.15. 15. Операция разность отношений

1.15.1. Бинарная операция для выполнения которой отношения А и В должны иметь один перечень атрибутов.

1.15.1.1. Возвращает отношение, содержащее все кортежи, которые принадлежат 1-ому из 2-ух заданных отношений и не принадлежат 2-ому.

1.15.1.2. Напр., в отношении А\В возвращаем кортежи, которые есть в А, но нет В.

1.16. 16. Декартово произведение отношений

1.16.1. Бинарная операция для произвольных отношений А и В. Т.е. с разным количеством атрибутов и кортежей (столбцов и строк)

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

1.16.1.2. Например, отношение А содержит 2 атрибута (столбца) и 4 кортежа (строки). Отношение В - 3 атрибута и 3 кортежа. Результатом АхВ будет отношение имеющее 5 атрибутов и 12 кортежей.

1.17. 17. Деление отношений

1.17.1. Деление для 2-ух заданных унарных отношений и 1-го бинарного.

1.17.1.1. Возвращает отношение, содержащее все кортежи из первого унарного отношения, которые содержатся также в бинарном отношении и соответствуют всем кортежам во втором унарном отношении.

1.17.1.2. Например, делим основную таблицу на какой-то определенный атрибут (или несколько атрибутов) и получаем тиблицу с перечисленными кортежами.

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

1.17.1.3. Хороший пример по ссылке

1.18. 18. Операция проекции

1.18.1. Унарная операция, т.е. требуется только одно отношение.

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

1.18.1.2. Например, отношение имеющее 5 атрибутов 4 кортежа. Из него исключаются 2 атрибута. В итоге получается отношение с 3 атрибутами и теми же 4 кортежами.

1.18.1.3. Фактически, мы выкидываем некоторые столбцы.

1.19. 19. Операция селекции

1.19.1. Унарная операция, т.е. требуется только одно отношение.

1.19.1.1. Возвращает отношение, содержащее все кортежи из заданного отношения, которые удовлетворяют указанным условиям.

1.19.1.2. Обычный запрос.

1.20. 20. Операция соединения отношений

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

1.20.2. Сначала просто "складываем" 2 таблицы в одну, как при умножении. После должна следовать выборка по одному атрибуту.

1.20.3. Обязательно должны присутствовать одинаковые записи в обоих отношениях.

1.20.4. Пример: http://migku.wikidot.com/gos-db-16#toc14

1.21. 21. Операция естественного соединения отношений

1.21.1. Естественным соединением называется соединение по эквивалентности двух отношений R и S, выполненное по всем общим атрибутам, из результатов которого исключается по одному экземпляру каждого общего атрибута.

1.21.2. Складываем 2 отношения по одному схожему атрибуту.

1.21.3. Обязательно должны присутствовать одинаковые атрибуты.

1.22. 22. Функциональные зависимости между атрибутами

1.22.1. Зависимость атрибутов между собой в отношениях.

1.22.2. http://www.intuit.ru/department/database/rdbdev/5/

1.23. 23. Аксиомы Армстронга

1.23.1. Фактически являются правилами вывода.

1.23.1.1. 1. Аксиома рефлексивности. Если B является подмножеством A, то B функционально зависит от A. Её доказывать не надо, это настолько элементарно, что доказывать не следует.

1.23.1.2. 2. Аксиома пополнения. Если есть функц. зав B от A, то существует функциональность зависим AC от BC.

1.23.1.3. 3.Аксиома транзитивности. Если есть зависимость B от A и C от B, то существует функц. зав C от A.

1.24. 24. Нормализация схем отношений (общие положения)

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

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

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

1.24.1.3. В целом суть этих ограничений весьма проста: каждый факт, хранимый в БД, должен храниться один-единственный раз, поскольку дублирование может привести к несогласованности между копиями одной и той же информации. Следует избегать любых неоднозначностей, а также избыточности хранимой информации.

1.25. 25. Нормальные формы

1.25.1. Первая нормальная форма – любое поле любой записи хранит только одно значение.

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

1.25.2. Вторая нормальная форма – БД находится в первой нормальной форме и любое неключевое поле полностью зависит от ключа.

1.25.2.1. Например, у нас есть запись с полями (Идентификатор, Название CD-Диска, Название группы), где ключом является поле «Идентификатор». При этом, очевидно, что поле «Название группы» зависит не только от «Идентификатора» но и от поля «Название CD-Диска». Поэтому такая БД не находится во второй нормальной форме.

1.25.3. Третья нормальная форма – БД находится во второй нормальной форме и нет неключевых полей зависящих от значения других неключевых полей.

1.25.3.1. Например, у нас в записи хранятся код региона и его название (помимо самих полей с информацией о CD-диске). Понятно, что название региона зависит от кода, и наоборот, поэтому такая БД не будет находиться в третьей нормальной фоме.

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

1.25.4.1. Например, у нас есть список записей, в которых помимо прочих полей, есть поля «Идентификатор фирмы» и «Название фирмы» являющиеся составным ключом. Понятно, что они зависят друг от друга. Поэтому данная зависимость является показателем того, что БД не находится в форме Бойса-Кодда.

1.25.5. Четвёртая нормальная форма – БД находится в нормальной форме Бойса-Кодда и ни одна таблица не содержит повторяющихся независимых групп данных.

1.25.5.1. Например, у нас есть таблица, в которой хранится информация о закупках оборудования – идентификатор записи, название поставщика и название поставляемого оборудования. Поскольку разные поставщики могут поставлять одинаковое оборудование, и наоборот – одно и то же оборудование может поставляться разными поставщиками, то мы имеем две группы независимых данных – поставщики и оборудование. Они повторяющиеся и независимые. Следовательно такая таблица не находится в четвёртой нормальной форме

1.25.6. Пятая нормальная форма – если БД находится в четвертой нормальной форме, избыточность данных полностью не устранена и разбивка таблицы если и возможна, то только на 3 и более частей. Надо заметить, что реальная необходимость в приведении к пятой форме возникает чрезвычайно редко.

1.26. 26. Декомпозиция схем отношений

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

1.26.2. Декомпозиция отношений проводится, чтобы исключить избыточное дублирование в отношениях. Выделяют два типа декомпозиций отношений:

1.26.2.1. Без потерь

1.26.2.2. С потерями

1.26.3. Т.е. в моём понимании декомпозиции это разбиение одного отношения на более мелкие в ходе нормализации.

1.27. 27. Общие положения об SQL. Типы данных SQL.

1.27.1. Изначально создавался как инструмент для выборки.

1.27.1.1. Сейчас используется для:

1.27.1.1.1. Организации данных - определение и изменение структуры представления данных; установка отношений.

1.27.1.1.2. Обработки данных - добавление/удаление/обновление данных.

1.27.1.1.3. Управления доступом - ограничения возможностей пользователя; координирование совместного использования.

1.27.1.1.4. Ну, и конечно же про выборку не забываем.

1.27.2. SQL является единственным стандартным языком для работы с реляционными БД.

1.27.3. Типы данных:

1.27.3.1. 1. Целые числа (INT).

1.27.3.2. 2. Дробные:

1.27.3.2.1. 1. Десятичные числа (NUMERIC, DECIMAL).

1.27.3.2.2. 2. Числа с плавающей запятой (FLOAT).

1.27.3.3. 4. Строки (TEXT, CHAR).

1.27.3.4. 5. Денежные величины (MONEY, CURRENCY).

1.27.3.5. 6. Дата, время (DATE, TIME).

1.27.3.6. 7. Булевы величины (BIT, YESNO).

1.28. 28. SQL. Создание и удаление таблиц.

1.28.1. CREATE TABLE <название таблицы> ( <имя поля1> <тип данных>, <имя поля2> <тип данных>);

1.28.2. DROP TABLE <название таблицы>;

1.28.2.1. Таблица с находящимися в ней строками, не может быть удалена.

1.28.2.2. Удалить все строки из таблицы можно следующим способом:

1.28.2.2.1. DELETE FROM <название таблицы>;

1.29. 29. SQL. Изменение структуры таблицы

1.29.1. Изменения производятся с помощью команды ALTER TABLE.

1.29.1.1. Основные режимы:

1.29.1.1.1. 1. Добавление столбца

1.29.1.1.2. 2. Удаление столбца

1.29.1.1.3. 3. Модификация столбца

1.29.1.1.4. 4. Изменение, добавление и удаление ключей.

1.30. 30. SQL. Создание и удаление индексов

1.30.1. CREATE INDEX <имя> ON <имя таблицы> (<имя поля>); WITH {тип индекса};

1.30.1.1. Типы индекса

1.30.1.1.1. PRIMARY - первичный ключ

1.30.1.1.2. DISALLOW NULL - запрет заполнения индекса нулевым значением

1.30.1.1.3. IGNORE NULL - возможность заполнения индекса нулевым значением.

1.30.2. DROP INDEX <имя> ON <имя таблицы> // возможно удаление только тогда, когда индекс является обычным

1.30.3. Для удаления первичных ключей и уникальных индексов используется ALTER TABLE с предложением DROP CONSTRAINT: ALTER TABLE <имя таблицы> DROP CONSTRAINT <имя индекса>

1.31. 31. SQL. Установление связей между таблицами

1.31.1. ALTER TABLE <имя подчинённой таблицы> ADD CONSTRAINT <имя взаимосвязи> FOREIGN KEY (имя поля из подчинённой таблицы) REFERENCES <имя главной таблицы> (имя поля из главной таблицы)

1.32. 32. SQL. Запросы на выборку

1.32.1. Запрос на выборку из одной таблицы: SELECT <названия_нужных_полей> FROM <название_таблицы> WHERE <условие_выборки>

1.32.2. Запрос на выборку из нескольких таблиц: SELECT * FROM <перечисление таблиц необходимые для выполнения запроса> WHERE <условие выборки>

1.33. 33. SQL. Запросы на удаление

1.33.1. DELETE <имя таблицы> WHERE <условие отбора>

1.33.1.1. Без WHERE удалятся все строки в таблице.

1.34. 34. SQL. Запросы на изменение

1.34.1. UPDATE <имя таблицы> SET <имя столбца> = <выражение> WHERE <условие отбора>

1.35. 35. SQL. Запросы на добавление

1.35.1. INSERT <имя таблицы> VALUES (<список значений>)

1.35.1.1. Т.е. если VALUES (4, 5, qwe), то 4 запишется в первый столбец, 5 - во второй, qwe - в третий.

1.35.2. INSERT INTO <имя таблицы> (<столбец1>, <столбец2>) VALUES (<значение для столбца1>, <значение для столбца2>)

1.36. 36. SQL. Группировка и упорядочивание данных

1.36.1. SELECT <имя столбца> FROM <имя таблицы> GROUP BY <название столбца для группировки>

1.36.2. SELECT * FROM <имя таблицы> ORDER BY <имя упорядочиваемого столбца>

1.36.2.1. По возрастанию:

1.36.2.1.1. ... ORDER BY <имя упорядочиваемого столбца> ASC

1.36.2.2. По убыванию:

1.36.2.2.1. ... ORDER BY <имя упорядочиваемого столбца> DESK

1.37. 37. SQL. Сортировка данных

1.37.1. SELECT * FROM <имя таблицы> WHERE <условие отбора> ORDER BY <имя упорядочиваемого столбца>

1.38. 38. Понятие о триггерах

1.38.1. Триггер - особый тип процедуры, который автоматически выполняется при изменении таблицы с помощью операторов UPDATE, INSERT или DELETE. Триггеры применяются для обеспечения целостности данных и реализации сложной бизнес-логики.

1.38.1.1. // Для понимания - Бизнес-логика — в разработке информационных систем — совокупность правил, принципов, зависимостей поведения объектов предметной области (области человеческой деятельности, которую система поддерживает).

1.38.1.2. Соответственно существует три вида триггеров:

1.38.1.2.1. UPDATE

1.38.1.2.2. INSERT

1.38.1.2.3. DELETE

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

1.38.2.1. // Транзакция — минимальная логически осмысленная операция, которая имеет смысл и может быть совершена только полностью.

1.38.3. CREATE TRIGGER <имя триггера> ON <имя таблицы> FOR [INSERT],[UPDATE],[DELETE] AS <SQL-операторы>