Понятие СУБД. Архитектура СУБД

Физическое проектирование, цель, процедуры

Логическое проектирование, цель, процедуры

Концептуальное проектирование, его цель, процедуры

Нормализация таблиц,ее цель.1я нормальная форма, 2НФ, 3НФ

Типы связи, их представление на ER-диаграмме. Класс принадлежности сущности его представление на ER-диаграмме.

Связь – некот.ассоциация м/у 2-я сущностями. Сущность может быть связана с др.сущностью или сама с собой. Связи позволяют по одной сущности находить др.,связанную с ней. В ER-диаграмме связь отображается линией,соединяющей 2 сущности. Между сущностями устанавливаются связи. Связи делают сущности более информативными, чем они являются по отдельности.Они позволяют минимизировать избыточность данных БД.

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

Важной характеристикой связи явл-ся тип связи(кардинальность).Связь существует 4-х типов:

1)один-к-одному (1:1)

2)один-ко-многим (1:М)

3)многие-ко-многим (М:М)

Важной характеристикой связи является тип связи (кардинальность).

Так как менеджер управляет только одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 1 имеет тип "один-к-одному" (1:1). В случае связи 1:1 одному значению первичного ключа соответствует одно и только одно значение вторичного ключа.так как филиал обрабатывает несколько счетов, а счет обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности СЧЕТ, а каждый экземпляр сущности СЧЕТ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 2 имеет тип "один-ко-многим" (1:М). В случае связи 1:М одному значению первичного ключа может соответствовать несколько знач-ий вторичного ключа.Так как счет может совместно использоваться несколькими клиентами и клиент может иметь несколько счетов, то каждый экземпляр сущности СЧЕТ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности СЧЕТ. В этом случае связь 3 имеет тип "многие-ко-многим" (М:N). В случае связи М:N одному значению первичного ключа может соответствовать несколько значений вторичного, и одному знач-ию вторичного-несколько знач-ий первичного.

Если каждый экземпляр сущности А связать с экземпляром сущности В,то класс принадлежности сущности А называется обязательным. Это отмечается на ER-диаграмме черным кружком,помещённым в прямоуг-к, смежный с прямоуг-м сущности А.

Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности явл-ся необязательным. Это отмечается на ER-диаграмме черным кружком,помещённым на линии связи возле прямоугольника сущности А.

22. Правила преобразования ER-диаграмм в реляционные таблицы в случае связей 1:1.

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

Правило2: Если связь типа 1:1 и класс принадл-ти одной сущности явл-ся обязат.,а др.-необязат., то необходимо построить таблицу для каждой сущности.

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

Правило3: Если связь типа 1:1 и класс принадл-ти обеих сущностей необязат.,то необходимо построить 3 таблицы-по одной для каждой сущ-ти и одну для связи. Первичный ключ сущ-ти д.б. первич.ключом соответствующей таблицы.Т-ца для связи должна иметь 2 атрибута-внешние ключи обеих сущ-ей.

23.Правила преобразования ER-диаграмм в реляционные таблицы в случае связей 1:М, М:N.

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

Правило5: Если связь типа 1:М и класс принадл-ти сущ-ти на стороне М явл-ся необязат.,то необходимо построить 3 таб-цы- по одной для каждой сущ-ти и одной для связи. Первичный ключ сущ-ти д.б.первичным ключом соответс.таб-цы.Таб-ца для связи д.иметь 2 атрибута-внешние ключи обеих сущ-ей.

Правило6: Если связь типа М:N, то необходимо построить 3 таб-цы-по одной для каждой сущ-ти и одну для связи.Первичный ключ сущ-ти д.б.первичным ключом соответствующей таб-цы. Таблица для связи д.иметь 2 атрибута-ключи обеих сущ-ей.При этом осущ-ся декомпозиция связи М:N на две связи 1:М.

Реляц.БД явл-ся эфф-ной, если обладает след. хар-ками:

1.минимизация избыточности данных

2.минимальн. использ-е отсутств-щих значений(null-значений)

3. предотвращение потери информации

Нормализация таблиц позволяет минимизировать избыточность данных. Методику нормализации таблиц разработал А.Ф.Кодд. Её суть сводится к приведению таблиц к той или иной нормальн.форме. Были выделены 3 нормальн формы: 1НФ, 2НФ, 3НФ. Позже стали выделять нормальн форму Бойса-Кодда(НФБК), затем 4НФ И 5НФ. Каждая последующая нормальн форма вводит определенные ограничения на хранимые в базе данные. Реляц БД считается эфф-ной, если все ее таблицы наход-ся как минимум в 3НФ. Таблица наход-ся в 1НФ, если все ее поля содержат только простые неделимые значения.

В отношении R атрибут Y функционально полно зависит от атрибута X (Y и X м.б. составными) в том и только в том случае, если каждому значению X соответствует в точности одно значение Y. R.X®R.Y.

Табл наход-ся во 2НФ, если она удовл-т требованиям 1НФ и неключевые поля функционально полно зависят от первичн ключа. Для приведения отношения ко 2НФ необходимо: - построить его проекцию, исключив атрибуты, которые не находятся в функционально-полной зависимости от составного ключа; - построить дополнительную проекцию на части составного ключа и атрибута, функционально зависящие от этой части ключа.

Функциональная зависимость R.X®R.Y. называется транзитивной, если существует такой атрибут Z, что имеются функциональные зависимости R.X®R.Z и R.Z®R.Y и отсутствует функциональная зависимость R.Z®R.X.

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

Алгоритм приведения к 3НФ:

ШАГ1(приведение к 1НФ)-задается 1 или несколько отнош-й, отбраж-х понятия предметн обл-ти. По модели предметн обл-ти выпис-ся обнаруж-е функц-е завис-ти. Все отнош-я автомат-ки наход-ся в 1НФ.

ШАГ2(приведение ко 2НФ)-если обнаружена завис-ть атрибутов от части сложн ключа, то проводится декомпозиция на несколько отношений: те атрибуты, которые зависят от части сложн ключа, выносятся в отдельн отнош-е вместе с этой частью ключа. В исходн отнош-и ост-ся все ключ атрибуты.

ШАГ3(привед к 3НФ)-если обнаружена завис-ть некот-х неключ атрибутов др-х неключ атрибутов, то проводится декомпозиция этих отнош-й след образом: те неключ атрибуты, которые зависят от других неключ атрибутов вынос-ся в отдельн отнош-е. В новом отнош-и ключом становится детерминант функ-й завис-ти.

Цель концептуальн проектирования-создание концептуальн модели данных исходя из представлений пользователя о предметной обл-ти.

Концептуальн проектир-ние:

1 анализ требований к БД: выявление представлений конечных пользователей и требований к обработке транзакций

2 моделир-ние связей сущностей и нормализация; определение сущностей, атрибутов и связей, построение ER-диаграмм, нормализация таблиц.

3 проверка модели данных: правила ввода, обновления и удаления, проверка отчетов, запросов, представлений

4 проектирование распределенной БД: определение местополож-я таблиц, требований доступа и стратегии фрагментирования.

Процедуры: 1 определение сущностей и их документирование: для идентификации сущностей определяются объекты, которые существуют независимо от других. Такие объекты являются сущностями. Каждой сущности присваивается осмысленное имя, понятное пользователям. Имена и описания сущностей заносятся в словарь данных.

2 создание семантической модели предметной области

3 определение связей между сущностями и их документирование:

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

4обсуждение концептуальной модели данных с конечными пользователями - если будут обнаружены несоответствия предметной области, то в модель вносятся изменения до тех пор, пока пользователи не подтвердят, что предложенная им модель адекватно отображает их личные представления.

Цель – преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физической реализации БД.

Результат: - логич структура БД, которая представляет собой схему, описанную в терминах языка описания данных

- функционирование спецификации программных модулей и набор возможных запросов к БД.

Процедуры: 1 определение набора таблиц из ER-модели и их документирование-для каждой сущности ER-модели создается таблица. Имя сущности – имя таблицы. Устанавливаются связи между таблицами посредством механизма первичных и внешних ключей. Структуры таблиц и установленные связи между ними документируются.

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

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

4 создание окончательного варианта логической модели данных и обсуждение его с пользователями – подготавливается окончательный вариант ER-модели, представляющей логическую модель данных.

Цель этапа физическ проектирования- описание конкретной реализации БД, размещаемой во внешней памяти компьютера. Процедуры физич проектир-я:1 проектир-ние таблиц БД средствами выбранной СУБД – осущ-ся выбор реляционной СУБД, которая будет использ-ся для создания БД, размещаемой на машинных носителях. Изучаются ее функциональные возможности по проектир-ю таблиц. Затем выполняется проектир-ние таблиц и схемы их связи в среде СУБД. Подготовленный проект БД описывается в сопровождаемой документации.

2 проектир-е физической организации БД. На этом шаге выбирается наилучшая файловая организация для таблиц. Выявляются транзакции, которые будут выполняться в проектируемой БД, и выделяются наиболее важные из них. Анализируется пропускная способность транзакций-кол-во транзакций, которые могут быть обработаны за заданный интервал времени, и время ответа – промежуток времени, необходимый для выполнения одной транзакции. Стремятся к повышению пропускной способности транзакций и уменьшению времени ответа. На основании указанных показателей принимаются решения об оптимизации производительности БД путем определения индексов в таблицах, ускоряющих выборку данных из базы, или снижения требований к уровню нормализации таблиц. Проводится оценка дискового объема памяти, необходимого для размещения создаваемой БД. Стремятся к его минимизации.

3 разработка стратегии защиты БД. БД- ценный корпоративный ресурс, поэтому орг-ции ее защиты уделяется много внимания. Для этого проектировщики должны иметь полное и ясное представление обо всех средствах защиты, представляемых выбранной СУБД.

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

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

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

Архитектура. В среде СУБД можно выделить след. пять основных компонентов:

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

Программное обеспечение. Этот компонент включает операционную систему, программное обеспечение самой СУБД, прикладные программы, включая и сетевое программное обеспечение, если СУБД используется в сети. Обычно приложения создаются на языках третьего поколения, таких как С, COBOL, Fortran, Ada или Pascal, или на языках четвертого поколения, таких как SQL, операторы которых внедряются в программы на языках третьего поколения.

Данные – наиболее важный компонент с точки зрения конечных пользователей. База данных содержит как рабочие данные, так и метаданные, т.е. "данные о данных".

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

Пользователи: клиенты БД, администратор БД, прикладные программисты. Более подробно этот компонент рассматривается в лекции №9 (Администрирование БД)

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

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

Третий компонент СУБД – ее ядро (DBMS Engine) выполняет функцию посредника между подсистемой средств проектирования и обработки и данными. Ядро СУБД получает запросы от двух других компонентов, выраженные в терминах таблиц, строк и столбцов, и преобразует эти запросы в команды операционной системы, выполняющие запись и чтение данных с физического устройства.

Microsoft представляет два различных ядра для Access 2003: Jet Engine и SQL Server. Ядро Jet Engine используется для персональных и коллективных баз данных небольшого объема. Ядро SQL Server предназначено для крупных баз данных.

Дата добавления: 2015-05-09