Базы данных. Часть 1.pptx
- Количество слайдов: 29
Базы данных и системы управления базами данных Преподаватель Бурко Светлана Валерьевна 1
БАЗЫ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ • Тема 1. Базы данных и системы управления базами данных, как структурные компоненты информационной системы 2
Основные понятия баз данных Понятие «базы данных» возникло в 60 -х годах, наиболее бурное развитие этого направления пришлось на 70 -е годы. Основу любой информационной системы составляет база данных, в которой хранятся сведения о большом количестве экземпляров взаимосвязанных классов объектов. Предметная область – часть реального мира, подлежащая изучению с целью организации и управления и, в конечном итоге, автоматизации. Каждый объект предметной области обладает определённым набором свойств (атрибутов), среди которых можно выделить существенные и малозначительные. ! Например: База данных деканата: атрибут Рост. Студента объекта Студент является малозначительным. База данных поликлиники: атрибут Рост. Пациента объекта Пациент является существенным. 3
Основные понятия баз данных База данных (БД) – это хранилище данных о некоторой предметной области, организованное в виде специальной структуры. Важно: § данные о некоторой области (не обо всем) § упорядоченные Система управления базой данных (СУБД) – это программное обеспечение для работы с БД. Функции: § поиск информации в БД § выполнение несложных расчетов § вывод отчетов на печать § редактирование БД ! Информационная система = БД + СУБД! 4
Структура базы данных Данные пользователя Методанные Индексы Методанные приложения Содержат данные пользователей в виде отношений (relation) Содержат описание собственной структуры, обычно в форме системных таблиц. Содержат дополнительные (избыточные) данные определенной структуры, позволяющие обрабатывать записи в различном порядке, но не требующие дублирования данных Содержат описание структуры и формата пользовательских форм, запросов, отчетов и других компонентов приложений. 5
БАЗЫ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ • Тема 2. Реляционная модель данных. Основные понятия реляционных баз данных 6
Основные понятия баз данных 1969 -1970 -е гг. Э. Кодд, англ. relation – отношение. Составные части реляционной модели данных: Ø структурная часть: описывает объекты реляционной модели данных; ! Единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения. Ø целостная часть: описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. ! Это целостность сущностей и целостность внешних ключей Ø манипуляционная часть: манипуляционная часть описывает два эквивалентных способа манипулирования реляционными данными – реляционную алгебру и реляционное исчисление. 7
Основные понятия баз данных Понятие тип данных в реляционной модели данных соответствует понятию типа данных в языках программирования. полностью База данных допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как «деньги» ), а также специальных данных (дата, время, временной интервал) Типы данных Простые: не обладают внутренней структурой (скаляры) Логический ! Строковый Численный Структурированные: для задания сложных структур Массивы Записи (структуры) Реляционная модель требует, чтобы типы простыми. Ссылочные: предназначен для обработки сложных изменяющихся структур, например деревьев, графов, рекурсивных структур Указатели используемых данных были 8
Домен отношения Домен можно рассматривать как подмножество значений некоторого типа данных имеющих определенный смысл. Свойства домена: ! Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл. Пример: домены «Вес детали» и «Имеющееся количество» можно одинаково описать как множество неотрицательных целых чисел, но смысл этих доменов будет различным, и это будут различные домены. üдомен имеет уникальное имя (в пределах базы данных); üдомен определен на некотором простом типе данных или на другом домене; üдомен может иметь некоторое логическое условие, позволяющее описать подмножество данных, допустимых для данного домена; üдомен несет определенную смысловую нагрузку. Пример: домен D, имеющий смысл «Возраст сотрудника» можно описать как следующее подмножество множества натуральных чисел: ! Домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат «истина» , то элемент данных является элементом домена. 9
Домен отношения Пример: описать все возможные домены отношения Зарплата Номер сотрудника 1 2 3 Фамилия Иваненко Петренко Сидоренко Зарплата 1000000 2000000 1500000 Номер отдела 1 2 2 D 1=Номер сотрудника={ n N: (n≥ 1 and n≤ 3)}, D 2=Фамилия={s String: s≠э, ю, ъ, ь and s≠n: n N} ! Не всегда очевидно, как задать логическое условие, ограничивающее возможные значения домена. В примере выше ясно, что домен «Фамилия» - это строки, являющиеся фамилиями и они не должны начинаться с цифр, служебных символов, с мягкого знака и т. д. Но вот является ли допустимой фамилия "Ггггггыыыыы"? 10
Атрибут отношения А есть пара вида <Имя_атрибута : Имя_домена>. ! Имена атрибутов должны быть уникальны в пределах отношения. ! Имена атрибутов отношения совпадают с именами соответствующих доменов. Пример: Номер сотрудника 1 2 3 Номер Сотрудника: D 1 Фамилия: D 2 Зарплата: D 3 Номер отдела: D 4 Фамилия Иваненко Петренко Сидоренко Зарплата 1000000 2000000 1500000 Номер отдела 1 2 2 11
Кортеж отношения А представляет собой множество пар вида <Имя_атрибута : Значение_атрибута>: таких, что значение атрибута принадлежит домену . Пример: дано отношение. Описать все кортежи в терминах реляционных баз данных Номер сотрудника 1 2 3 Фамилия Иваненко Петренко Сидоренко Зарплата 1000000 2000000 1500000 Номер отдела 1 2 2 Кортеж № 1: (Номер Сотрудника: 1, Фамилия: Иваненко, Зарплата: 1000000, Номер отдела: 1) Кортеж № 2: (Номер Сотрудника: 2, Фамилия: Петренко, Зарплата: 2000000, Номер отдела: 2) Кортеж № 3: (Номер Сотрудника: 3, Фамилия: Сидоренко, Зарплата: 1500000, Номер отдела: 2) 12
Отношение содержит заголовок и тело. Заголовок отношения содержит фиксированное количество атрибутов отношения: Тело отношения содержит множество кортежей отношения. Отношение обычно записывается в виде: или просто R. Число атрибутов в отношении называют степенью (или -арностью) отношения. Мощность множества кортежей отношения называют мощностью отношения. Пример: дано отношение. Записать отношение в терминах реляционных баз данных, определить его мощность и степень. R(ID_Stud, ФИО, Номер группы, Пол Дата рождения) Мощность отношения: 3, 13 Степень отношения: 5
Основные понятия баз данных Реляционной базой данных называется набор отношений. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных. Любое отношение можно изобразить в виде таблицы, но нужно четко ! понимать, что отношения НЕ являются таблицами. Соответствие реляционных и «табличных» терминов Реляционный термин База данных Схема база данных Отношение Заголовок отношения Тело отношения Атрибут отношения Кортеж отношения Соответствующий «табличный» термин Набор таблиц Набор заголовков таблиц Таблица Заголовок таблицы Тело таблицы Наименование столбца таблицы Строка таблицы Степень (-арность) отношения Мощность отношения Домены и типы данных Первичный ключ Количество столбцов таблицы Количество строк таблицы Типы данных в ячейках таблицы Одно или несколько наименований столбцов таблицы 14
Фундаментальные свойства отношений ! 1. В отношении нет ОДИНАКОВЫХ кортежей У каждого отношения есть первичный ключ – набора атрибутов, значения которых однозначно определяют кортеж отношения. Таблицы в отличие от отношений могут содержать одинаковые строки 2. Кортежи НЕ упорядочены (сверху вниз) Номер сотрудника 1 2 3 ! Фамилия Иваненко Петренко Сидоренко Зарплата 1000000 2000000 1500000 Номер отдела 1 2 2 нельзя сказать, что сотрудник Иваненко «предшествует» сотруднику Петренко Одно и то же отношение может быть изображено разными таблицами, в которых строки идут в различном порядке. 3. Атрибуты НЕ упорядочены (слева направо) Номер сотрудника 1 2 3 Зарплата 1000000 2000000 1500000 Зарплата Фамилия Иваненко Петренко Номер отдела 1 2 2 4. Атомарность значений атрибутов Номер сотрудника 1 2 3 Фамилия Иваненко Петренко Сидоренко Зарплата 1000000 2000000 1500000 Номер отдела 1 2 2 15
БАЗЫ ДАННЫХ И СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ • Тема 3. Этапы проектирования баз данных. ER–модель предметной области 16
Этапы проектирования баз данных 1. Инфологическое предметной области проектирование: строится инфологическая модель Инфологической моделью предметной области называется описание предметной области, выполненное с использованием специальных языковых средств, без ориентации на используемые в дальнейшем программные и технические средства. 2. Даталогическое проектирование: строится даталогическая модель Даталогическая модель представляет собой отображение логических связей между элементами данных в независимости от того, что представляют собой данные и какие технические средства будут использованы для хранения данных, но с учетом программных средств (СУБД). 3. Физическое проектирование: строится физическая модель данных Физическая модель определяет используемые запоминающие устройства и способы физической организации данных на них. 4. Проектирование внешних моделей: строится модель (или несколько моделей), описывающая логическую структуру БД с точки зрения конкретного пользователя (пользователей) ! Обычно процесс проектирования базы данных НЕ является строго линейным. На любом шаге проектирования возможно ВОЗМОЖНО ВОЗВРАШЕНИЕ К ПЕРДЫДУЩЕМУ ЭТАПУ и исправление ранее построенной модели. 17
Концептуальное проектирование Цель: создание концептуальной модели данных исходя из представлений пользователей о предметной области. 1. Определение сущностей и их документирование : üобъекты-сущности с осмысленными именами, понятными пользователям, например, УЧЕНИК, КЛАСС, ПРЕДМЕТ üсловарь данных (имена + описание сущностей) üопределение ожидаемого количества экземпляров каждой сущности Номер множества сущностей Е 1 Е 3 Имя множества сущностей Ученик Учитель Определение множества сущностей Ребенок в возрасте от 7 до 17 лет, обучающийся в школе Физическое лицо, имеющее высшее образование по соответствующей специальности Описание множества сущностей Как только в школу подается заявление о приеме нового ученика, формируется новый экземпляр данного множества сущностей Как только конкретный человек устраивается на работу в данную школу, формируется новый экземпляр данного множества сущностей Примеры выделенных сущностей: УЧЕНИК/E 1: Иванов Саша, 7 лет; Петров Петя, 13 лет. КЛАСС/E 2: 2 А, 7 Б. ПРЕДМЕТ/E 4: математика, информатика, рисование. 18
Концептуальное проектирование 2. Определение связей между сущностями и их документирование: üСвязи между сущностями üТипы связей между сущностями и их имена (выраженные глаголами) üКласс принадлежности каждой сущности üСловарь данных Пример: построение словаря данных для предметной области «Школа» Ном ер связи Номер 1 -ой сущности Номер 2 -ой сущности Имя связи Тип связи Определенная обязательная R 1 Е 2 родительская Е 1 Дочерняя Состоит из R 3 Е 2 Е 4 Изучает/ изучается Неопределенная Описание связи Каждый класс состоит из одного или более учеников. Каждый ученик включен в один и только один класс Каждый класс изучает один или более предметов. Каждый предмет может изучаться одним или более классами или не изучаться ни одним классом 19
Концептуальное проектирование 3. Создание ER-модели предметной области: построение ER-диаграммы Пример: построение ER-диаграммы для предметной области «Школа» 20
Концептуальное проектирование 4. Определение атрибутов и их документирование üимя атрибута и его описание; üтип и размерность значений; üзначение, принимаемое для атрибута по умолчанию (если такое имеется); üможет ли атрибут иметь Null-значения; üявляется ли атрибут составным, и если это так, то из каких простых атрибутов он состоит. Пример: определение атрибутов и их документирование для предметной области Множество «Школа» сущностей Учитель/Е 3 Ученик/Е 1 Имя атрибута Имя домена Личный номер учителя Фамилия Имя Отчество Группа Личный номер учителя Личный номер ученика Фамилия Имя Дата рождения Год обучения Группа Код предмета Номер Имя Имя Буква Номер Имя Дата Номер Буква Номер Признак обязательности Not null Not null Not null Not null Примечание PK AK 1. 1 AK 1. 2 AK 1. 3 PK 2 FK 1 PK AK 1. 1 AK 1. 2 AK 1/3 FK 1. 1 FK 1. 2 21 PK, FK 2
Концептуальное проектирование 5. Определение значений атрибутов и их документирование: определяется набор допустимых значений и ему присваивается имя Множество сущностей Предмет/Е 4 Имя атрибута Имя домена Код предмета Тип предмета Номер Тип Описание Название Признак обязательности Not null Null Not null Примечание PK Обязательный факультативный или AK Предмет может быть обязательным или факультативным 6. Определение первичных ключей для сущностей и их документирование: определение первичного ключа Первичный ключ (PK) Множество сущностей Предмет/Е 4 Имя атрибута Имя домена Код предмета Тип предмета Номер Тип Описание Название Признак обязательности Not null Null Not null Примечание PK Обязательный факультативный AK или 22
Концептуальное проектирование 7. Обсуждение концептуальной модели данных с конечными пользователями. Если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления. 23
Логическое проектирование Цель: преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физической реализации базы данных. 1. Выбор модели данных: реляционная модель данных (в связи с табличного представления данных и удобства работы с ними) 2. Определение набора таблиц исходя из ER-модели и их документирование. üсоздание отношения для каждой сущности ER-модели üимя сущности – имя отношения üформирование структуры отношений на основании определенных правил üопределение связи между таблицами посредством механизма первичных и внешних ключей 3. Нормализация таблиц: приведение каждого из отношений, ПО КРАЙНЕЙ МЕРЕ, к 3 НФ 4. Проверка логической модели данных на предмет возможности выполнения всех транзакций, предусмотренных пользователями. Транзакция – это набор действий, выполняемых отдельным пользователем или прикладной программой с целью изменения содержимого базы данных. 24
Логическое проектирование 5. Определение требований поддержки целостности данных и их документирование. Эти требования представляют собой ограничения, которые вводятся с целью предотвратить помещение в базу данных противоречивых данных. Типы ограничений: ü обязательные данные: есть ли атрибуты, которые не могут иметь Nullзначений; ü ограничения для значений атрибутов: определение допустимых значений для атрибутов; ü целостность сущностей: первичный ключ сущности не содержит Nullзначений; ü ссылочная целостность: значение внешнего ключа ДОЛЖНО ОБЯЗАТЕЛЬНО присутствовать в первичном ключе одной из строк таблицы для родительской сущности; ü ограничения, накладываемые бизнес-правилами. 6. Создание окончательного варианта логической модели данных и обсуждение его с пользователями. 25
Логическое проектирование 7. Обсуждение концептуальной модели данных с конечными пользователями. Если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления. 26
Физическое проектирование Цель: писание конкретной реализации базы данных, размещаемой во внешней памяти компьютера. При логическом проектировании отвечают на вопрос – ЧТО НАДО СДЕЛАТЬ, а при физическом – выбирается способ, КАК ЭТО СДЕЛАТЬ. 1. Проектирование таблиц базы данных средствами выбранной СУБД. üвыбор реляционной СУБД üпроектирование таблиц и схемы их связи в среде СУБД 2. Реализация бизнес-правил в среде выбранной СУБД. 3. Проектирование физической организации базы данных. ü выбор наилучшей файловой организация для таблиц ü выявление транзакции, которые будут выполняться в проектируемой базе данных, и выделяются наиболее важные из них ü анализ пропускной способности транзакций и время ответа ü оценка дискового объема памяти, необходимого для размещения создаваемой базы данных (объем памяти min) 4. Разработка стратегии защиты базы данных. 5. Организация мониторинга функционирования базы данных и ее настройка. 27
Проектирование внешних моделей Внешних моделей может быть столько, сколько имеется пользователей базы данных. Проектирование внешних моделей АНАЛОГИЧНО проектированию даталогической модели базы данных, но с учетом требований пользователей и их уровней доступа к информации. База данных Пользователь А Пользователь В Пользователь С Внешняя модель пользователя А (модель пользователя А) Внешняя модель пользователя В (модель пользователя В) Внешняя модель пользователя С(модель пользователя С) Подсхема данных пользователя А Подсхема данных пользователя В Подсхема данных пользователя С 28
Этапы проектирования баз данных После того как поставлена задача проектирования базы данных, первой строится инфологическая модель. Затем на ее основе строится даталогическая модель. Далее происходит проектирование физической и внешних моделей. Физическая и внешние модели могут строиться в любой последовательности, в том числе и параллельно. Внешние модели должны быть обязательно согласованы с соответствующими инфологической и даталогической моделями. Они ни в коем случае не дополняют соответствующие модели, а являются их частью (т. е. проекцией на уровень заинтересованности отдельного пользователя в информации). 29
Базы данных. Часть 1.pptx