1)История возникновения и развития технологий баз данных может рассматриваться как в широком, так и в узком аспекте.

В широком аспекте понятие истории баз данных обобщается до истории любых средств, с помощью которых человечество хранило и обрабатывало данные. В таком контексте упоминаются, например, средства учёта царской казны и налогов в древнемШумере (4000 г. до н. э.), узелковая письменность инков — кипу, клинописи, содержащие документы Ассирийского царстваи т. п. Следует помнить, что недостатком этого подхода является размывание понятия «база данных» и фактическое его слияние с понятиями «архив» и даже «письменность».

История баз данных в узком аспекте рассматривает базы данных в традиционном (современном) понимании. Эта история начинается с 1955 года, когда появилось программируемое оборудование обработки записей. Программное обеспечение этого времени поддерживало модель обработки записей на основе файлов. Для хранения данных использовались перфокарты.

Оперативные сетевые базы данных появились в середине 1960-х. Операции над оперативными базами данных обрабатывались в интерактивном режиме с помощью терминалов. Простые индексно-последовательные организации записей быстро развились к более мощной модели записей, ориентированной на наборы. За руководство работой Data Base Task Group (DBTG), разработавшей стандартный язык описания данных и манипулирования данными, Чарльз Бахман получил Тьюринговскую премию.

В это же время в сообществе баз данных COBOL была проработана концепция схем баз данных и концепция независимости данных.

Следующий важный этап связан с появлением в начале 1970-х реляционной модели данных, благодаря работам Эдгара Ф. Кодда. Работы Кодда открыли путь к тесной связи прикладной технологии баз данных с математикой и логикой. За свой вклад в теорию и практику Эдгар Ф. Кодд также получил премию Тьюринга.

Сам термин database (база данных) появился в начале 1960-х годов, и был введён в употребление на симпозиумах, организованных фирмой SDC (System Development Corporation) в 1964 и 1965 годах, хотя понимался сначала в довольно узком смысле, в контексте систем искусственного интеллекта. В широкое употребление в современном понимании термин вошёл лишь в 1970-е годы.

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

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

Информация – это любые сведения о каком-либо событии, процессе, объекте.

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

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

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

Модель данных - это концептуальное описание выбранной предметной области. Модель данных не содержит ссылок и указаний на физическую модель самой системы.

СУБД – это ПО, которое позволяет пользователям определять создавать и обслуживать БД, а так же управлять доступом к ней.

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

3)В 60-е годы до появления ЭВМ третьего поколения обработка данных осуществлялась в основ­ном операциями ввода-вывода. Файлы при такой обработке были организова­ны последовательным способом. При этом физическая структура данных и логическая структура файла совпадали.

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

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

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

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

4) Логически в современной СУБД можно выделить 3 составляющие: ядро СУБД, компилятор языка БД, подсистему поддержки времени выполнения и набор утилит.

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

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

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

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

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

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

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

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

Физическая последовательность блоков определяется соображениями

•  удобства поиска в файле,

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

•   предпочтительности размещения записей в порядке, требуемом при выводе результатов

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

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

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

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

11)Любая проектируемая БД должна обладать следующими свойствами:

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

- восстанавливаемость – данное свойство предполагает возможность восстановления БД после сбоя системы или отдельных её составляющих, например, проверка файлов приложения, наличие резервных копий БД и т.д;

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

- эффективность – подразделяется на 2 категории : минимальное время реакции на запрос пользователя и минимальные потребности в памяти, в современных СУБД требуется сочетание обоих этих параметров;

- предельные размеры и эксплуатационные ограничения.

12)

1. Непосредственное управление данными во внешней памяти.

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

2. Управление буферами оперативной памяти.

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

3.Управление транзакциями.

Транзакция - последовательность операций над БД, рассматриваемых СУБД как единое целое. Если транзак­ция успешно выполняется, то СУБД фиксирует изменения БД, произведен­ные этой транзакцией во внешней памяти, если нет – БД остаётся в прежнем состоянии, выполняется откат транзакции, т.е. ликвидация всех изменений, произведённых транзакцией. Тем самым поддерживается логическая целостность однопользовательской БД.

4. Журнализация.

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

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

Журнал - это специальная часть БД, в которую по­ступают записи обо всех изменениях основной части БД. Журнал недоступная пользователям СУБД и поддерживается с особой тщательностью (часто ведутся две ко­пии журнала).

10)Эта архитектура включается в себя 3 уровня абстракции: концептуальный уровень проектирования БД; логический уровень проектирования БД; физический уровень проектирования БД.

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

Логический уровень – описывает пользовательские элементы данных и связи между ними, исходя из предложенной концептуальной схемы БД. Каждая пользовательская группа на логическом уровне получает свое собственное представление данных, т.е. получает ориентированное на пользователя описание основных элементов и отношений между ними. В отношении машинной реализации может служить ЕR-диаграмма.

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

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

13) БД как и любое ПО обладает собственным жизненным циклом, т.е. создаются, функционируют и устаревают. Создание единой базы и программ необходимых для её функционирования и составляют главную часть жизненного цикла. Для любой БД можно выделить 3 основных этапа жизненного цикла:

1) анализ и проектирование БД:

-формулирование задачи и анализ требований;

-концептуальное проектирование;

-проектирование реализации;

2) реализация структуры БД

-непосредственная реализация

-физическое проектирование

-тестирование

3)поддержка БД

-анализ функционирования и поддержка исходного варианта БД

-адаптация, модернизация и поддержка переработанных вариантов.

Анализ и проектирование.

1) Формулирование задачи и анализ требований подразумевает разработку стратегического плана, в процессе которого осуществляется предварительное планирование конкретной системы управления БД. Информационная модель, созданная на данном этапе анализируется и видоизменяется в процессе разработки структуры БД.

2) После полного сбора информации и формулирования требований к БД, осуществляется переход к инфологическому проектированию БД. При проектирование БД различают 2 аспекта инфологический и даталогический.

3) проектирование реализации – после получение концептуальной модели БД переходят к проектированию реализации.

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

1. выбор и приобретение СУБД

2. преобразование концептуальной модели в физическую

3. заполнение БД

4. создание прикладных программ

5. тестирование

4) Оценка работы и поддержка.

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

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

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

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

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

15) концептуальное проектирование – приводит к созданию концептуальной схемы БД.

В проектировании концептуальной модели данных выделяют следующие этапы:

- выделение локальных представлений, соответствующих относительно независимым данным

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

- выделение ключевых атрибутов

-определение спецификации связей между объектами

-анализ и добавление не ключевых атрибутов

- описание локальных представлений

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

В процессе концептуального проектирования предметной области рассматривается следующая объектная система:

- объект

- временные характеристики

- связи

Объект – это информационная единица, о которой накапливается информация в информационной системе.

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

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

Н

Студент.Иванов

апример:

Объектные множества бывают лексические и абстрактные. Элементы лексических объектных множеств подлежат обработке, тогда, как под абстрактными понимаются интуитивные связи или обощения. Некоторые объектные множества могут входить в структуру более крупных множеств.

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

Для того, чтобы связать объекты или множества вводят следующие типы связей, которые отображаются в инфологической модели предметной области: 1 к 1; 1 ко многим; многие ко многим(является избыточным).

16) концептуальное проектирование – приводит к созданию концептуальной схемы БД.

В проектировании концептуальной модели данных выделяют следующие этапы:

- выделение локальных представлений, соответствующих относительно независимым данным

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

- выделение ключевых атрибутов

-определение спецификации связей между объектами

-анализ и добавление не ключевых атрибутов

- описание локальных представлений

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

В процессе концептуального проектирования предметной области рассматривается следующая объектная система:

- объект

- временные характеристики

- связи

Объект – это информационная единица, о которой накапливается информация в информационной системе.

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

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

Н

Студент.Иванов

апример:

Объектные множества бывают лексические и абстрактные. Элементы лексических объектных множеств подлежат обработке, тогда, как под абстрактными понимаются интуитивные связи или обощения. Некоторые объектные множества могут входить в структуру более крупных множеств.

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

Для того, чтобы связать объекты или множества вводят следующие типы связей, которые отображаются в инфологической модели предметной области: 1 к 1; 1 ко многим; многие ко многим(является избыточным).

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

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

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

6) Т-М модели используют математический аппарат, реляционную алгебру и реляционное исчисление. К моделям данного типа относят реляционную модель, которая представляет из себя совокупность таблиц, над которыми могут выполняться операции, формируемых в терминах реляционной алгебры и реляционного исчисления. Запросы к базе формируются более компактно, однако такой подход порождает и ряд проблем, связанных с производительностью СУБД, наличием интерфейса СУБД, который бы поддерживал реляционную модель данных и традиционными языками программирования.

7) К теоретико-графовым моделям относят 2 разновидности: сетевые модели и иерархические модели.

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

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

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

Наша организация предлагает полный комплекс услуг по поддержке и сопровождению баз данных:

 Поддержка БД:

- техническое сопровождение и обновление БД;

- регулирование работы БД (дефрагментация БД и др.)

- адаптация БД к нуждам организации;

- обследование IT-инфраструктуры предприятия (оценка состояния баз данных, производительности, необходимость миграции);

- сервисная поддержка;

 Технические регламенты:

- архивирование и копирование данных;

- разработка приложений к СУБД;

- обеспечение функциональности и продуктивности деятельности БД;

 Оперативная помощь:

- помощь по управлению и эксплуатации БД;

- решение оперативных вопросов по телефону и электронной почте.

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

8) Типичным представителем систем, основанных на сетевой модели данных является СУБД ID MS integrated database management system, основанная на мейнфреймах компании IBM. Сетевой подход к организации данных является расширением иерархического в том смысле, что в сетевой структуре у потомка может иметься любое число предков.

Сетевая БД состоит из набора записей и набора связей между этими записями.

Тип связи определяется из 2х типов записи – предка и потомка, например для данного типа связи L с типом записи предка P и типом записи потомка С будут выполняться следующие условия: 1. Каждый экземпляр P является предком только для одного типа связи L. 2. Каждый экземпляр С является потомком не более чем в одном типе связи L. Пример->> Отдел, служащие, руководитель.

Граф строится последующим правилам:

1. БД содержит любое количество наборов и записей

2. Между двумя типами записей может быть любое количество наборов

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

Манипулирование данными в сетевой модели.

1. Осуществлять поиск записи

2. Переход от предка к потомку по некоторой связи

3. Переход от потомка к предку по некоторой связи

4. Создание новой записи, уничтожение записи, модификация записи,

5. включение в связь,

6. исключение из связи

7. определение для записи нового типа связи.

Сетевые модели имеют внутренние ограничения:

1. В конкретном экземпляре набора не может быть более одного экземпляра

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

9) Типичным представителем иерархической модели данных является СУБД IMS(information management system) компании IBM. 1я версия системы появилась в 1968 году.

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

В иерархической модели данных потомок имеет в точности 1го предка.

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

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

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

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

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

Операции манипулирования данными:

-поиск указанного элемента в дереве БД,

-переход от одного элемента к другому,

-переход от экземпляра одного типа записи к экземпляру другого типа записи. Переход от одной записи к другой в порядке обхода иерархии.

-добавление новой записи в порядке обхода иерархии.

-удаление текущей записи.

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

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

25)

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

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

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

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

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

6. Правило обновления представлений – все представления, которые теоретически можно обновить должны быть доступны для обновления

7. Правило добавления, обновления и удаления – определяет возможность работать с отношением, как с одним операндом, как при чтении данных, так и добавлении, обновлении и удалении.

8. Правило независимости физических данных – прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться неизменными и при любых изменениях способов хранения и методов доступа к ним не менять свои значения.

9. Правило независимости логических данных – прикладные программы и утилиты для работы с данными должны на логическом уровне оставаться неизменными.

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

11. Правило независимости распространения – реляционная СУБД не должна зависеть от потребностей конкретного пользователя

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

26) Функциональная зависимость – это связь между атрибутами, позволяющая определить по известному значению одного атрибута описание или характеристики другого атрибута.

Например: по номеру счёта клиента можно определить состояние его счёта, в таком случает можно сказать, что атрибут состояния счёта клиента функционально зависит от атрибута номер счёта клиента.

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

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

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

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

Во многих случаях возникает путаница, связанная с понятиями функциональной зависимости, ключа. Атрибут, находящийся в отношении по правую сторону называется детерминантом, например, № студента – специальность; серийный номер ПК – объём памяти.

Детерминант функционально зависит от ключевого атрибута и в свою очередь может принимать как уникальные, так и неуникальные значения. В отличие от детерминантов ключи всегда являются уникальными. Ключ функционально определяет целую строку таблицы. Если бы ключ дублировались, то дублировался бы и весь кортеж, что недопустимо согласно определению отношения.

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

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

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

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

Любые отношения можно классифицировать по 3м типам аномалий: связанные с удалением добавлением и изменением данных. Для устранения которых и предотвращения их возникновения любые отношения приводят к нормальным формам.

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

Нормализованное отношение представляется в виде таблицы. Имя таблицы соответствует имени отношения, имена столбцов - именам атрибутов, строки - кортежам.

-Все строки (кортежи) должны быть различны.

-Отношение может иметь «пустой» атрибут, если его значения не применяются или пока неизвестны.

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

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

Внешний ключ – набор атрибутов (или один атрибут) одного отношения, являющийся ключом другого отношения. Атрибуты внешнего ключа могут иметь имена, отличные от имён ключа другого отношения, с которым устанавливается связь.

Подведем итоги:

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

• Степень отношения - число его атрибутов. Отношение степени один называют унарным, степени два - бинарным, степени три - тернарным, а степени n - n-арным.

Кардинальное число или мощность отношения - это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

• Реляционная схема базы данных содержит имена реляционных таблиц, имена атрибутов, ключевые атрибуты, внешние ключи.

Обновление отношений выполняется следующими операциями: -добавление кортежа; -удаление кортежа и -изменение кортежа.

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

29) Основная задача нормализации БД - найти такой состав отношений, который удовлетворял бы следующему минимуму требований:

-множество отношений должно обеспечивать минимизацию избыточности представления информации;

-назначенные для отношения ключи должны быть минимальными;

-при выполнении операций удаления, включения, модификации в БД не должно быть аномалий;

-перестройка набора отношений РБД при изменении структуры какого-либо отношения (добавление, удаление, изменение атрибутов) должна быть минимальной;

-разброс времени выполнения запросов в БД должен быть небольшим.

Например, отношение ПОСТАВКА содержит следующие атрибуты: ПОСТАВКА (Дата поставки, Поставщик, Товар, Адрес_поставщика, Количество_товара, Цена_ ед_товара)

Такое отношение имеет следующие недостатки:

-избыточность информации (атрибут Адрес_ поставщика для поставки товаров не важен);

-первичный ключ не минимален (состоит из трёх атрибутов);

-аномалия модификации (при изменении атрибута Адрес поставщика, он не изменяется в других отношениях, в результате возникает нарушение целостности БД;

-аномалия включения: если с поставщиком заключен договор, но товар не поставлен, его нельзя включить в БД;

-аномалия удаления: если удалили все поставки некоторого поставщика, то теряются вообще все сведения о нем.

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

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

2. Все записи в одном столбце должны иметь один и тот же тип. Каждый столбец должен иметь уникальное имя (порядок следования столбцов в таблице несущественен)

3. В таблице не должно быть одинаковых строк

Пример: таблица спортивная секция находится в 1й н. ф., т.е. таблица в 1й норм форме может иметь аномалии модификации.

31) Рассмотрим отношение секция, данное отношение может иметь аномалии модификации, т.е. отношение подвержено как аномалии удаления, так и аномалии вставки.

Проблема формирования отношения заключается в том, что отношение содержит зависимость, затрагивающее только часть ключа. Ключом является комбинация №студента секция, но отношение помимо этого содержит ещё и зависимость секция-плата. Т.к. связан с секцией. Аномалии модификации не было бы если бы плата зависела от всего ключа. Чтобы устранить аномалию разбиваем отношение на 2.

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

Отношение секция, которое разбито на 2 отношения студент-секция и секция-плата находятся во 2й нормальной форме

32) Отношение во 2й нормальной форме всё же могут иметь аномалии.

Рассмотрим следующий пример: проживание студента в общежитии. Имеется отношение, которое характеризуется атрибутами (№ студента, общежития, плата). Ключом является № студента и имеются функциональные зависимости № студента-общежитие ; общежитие-плата. Эти зависимости возникают только потому, что каждый студент живет только в одном общежитии и каждое общежитие взимает плату со всех проживающих в нём студентов (одинаковую плату). Поскольку номер студента определяет атрибут общежития, а общежитие определяет атрибут плата, то получаем косвенную зависимость № студента от платы. Такая структура функциональной зависимости называется транзитивной зависимостью.

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

Определение: отношение находится в 3й нормальной форме если оно находится во 2й нормальной форме и не имеет транзитивной зависимости. Транзитивная зависимость устраняется при разбиении отношения на 2.

33) Рассмотрим следующее отношение консультант, которое характеризуется атрибутами (№ студента, специальность, преподаватель). Определим следующие требования к отношению:

1. Студент может иметь 1 или несколько специальностей

2. Консультантом по 1 и тому же предмету могут быть несколько преподавателей.

3. Каждый преподаватель может быть консультантом только по 1й специальности.

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

Кроме ключей кандидатов, существует еще одна функциональная зависимость атрибут преподаватель определяет атрибут специальность. По определению отношение консультант находится в 1й нормальной форме, оно так же находится во 2й нормальной форме, поскольку не имеет не ключевых атрибутов. Это отношение находится в 3й нормальной форме поскольку не имеет транзитивных зависимостей, однако все же содержит аномалии модификации, например, удаляем студента с неким номером, если мы удаляем строку с информацией о студенте мы теряем тот факт, что некий преподаватель является консультантом по некоторому предмету, т.е. имеем аномалию удаления. Чтобы устранить аномалию для отношения, находящегося в 3х норм формах отношение приводят к Бойса-Кодду.

Определение. Отношение находится в нормальной форме Б-К если каждый детерминант является ключом кандидатом.

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

34) Рассмотрим отношение студент, которое отображает связи между студентами, специальностями и спортивными секциями. Предположим, что студенты могут иметь несколько специальностей и заниматься одновременно в нескольких спортивных секциях. В таком случае единственным ключом является комбинация номер студента-специальность-секция. Например, если мы удаляем студента с определенным номером, обучающегося на специальности бух.учет, то мы удаляем из секции, которую, он посещает. В данном виде связей, связь между № студента и специальностью не является функциональной зависимостью, поскольку у студента может быть несколько специальностей. Помимо этого одному и тому же атрибуту № студента может соответствовать несколько значений атрибута спортивная секция. Такая зависимость атрибутов называется многозначной зависимостью.

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

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

Многозначная зависимость существует в том случае, когда отношение имеет минимум 3 атрибута, причём 2 из них являются многозначными, а их значение зависит от 3го. Другими словами в некотором отношении Р существует многозначная зависимость, если атрибут А многозначным образом определяет атрибуты Б и С, а сами атрибуты Б и С не зависят друг от друга.

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

Определение . Отношение находится в 4й нормальной форме, если оно находится в нормальной форме Бойса-Кодда и не имеет многозначных зависимостей.

5Я нормальная форма.

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

35) В любых отношениях может быть выделена атрибутивная связь 1 к 1, 1 ко многим и многие ко многим.

Связь 1 к 1.

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

2. Один из атрибутов должен быть ключом (минимум) в идеале каждый из атрибутов должен быть ключом.

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

4. Атрибуты А и Б должны находиться в некотором отношении Р и не состоять ни в каком другом отношении.

Связь один ко многим:

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

К отношениям, между которыми имеется связь 1:N, иногда применяются термины родитель (parent) и потомок (child). Родитель — это отношение на унарной стороне связи (с кардинальным числом 1), а потомок — это отношение на множественной стороне связи (с кардинальным числом N).

Связь многие ко многим.

Тип бинарных связей, в которых сущности одного типа соответствует много сущностей второго типа, и сущности второго типа соответствует много сущностей первого типа.

Связи «многие ко многим» не могут быть напрямую представлены с помощью отношений. Т.к. не удовлетворяют требованиям нормализации.

Пример. –студент, -предмет. 1студент может изучать несколько предметов. 1 предмет может изучаться несколькими студентами

Решение этой проблемы состоит в том, чтобы создать третье отношение, представляющее связь как таковую. Подобные отношения называются отношениями пересечения, поскольку каждая строка такого отношения хранит данные о связи конкретного студента с конкретным классом. Обратите внимание, что каждой линии связи между сущностями СТУДЕНТ и ПРЕДМЕТ соответствует одна строка в отношении пересечения.

Рекурсивная связь

Это связь между сущностями одного и того же класса. У рекурсивных связей нет фундаментальных отличий от других типов связей.

У рекурсивных существует три разновидности: 1:1, 1 ко многим, многие ко многим.

Рекурсивные связи, таким образом, представляются точно так же, как и другие виды связей. Однако строки таблиц могут при этом играть две различные роли. Одни являются родительскими, другие — дочерними. Если некоторый ключ предполагается сделать родительским, и строка не имеет родителя, ее значение будет пустым. Если некоторый ключ предполагается сделать дочерним, и строка не имеет потомка, ее значение также будет пустым.

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

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

Рекурсивные связи M:N. Связь У-КОГО-ЛЕЧИТСЯ: врач и у кого лечится.

Представляет ситуацию, в которой врачи лечат друг друга. Как и для других связей M:N, нам необходимо создать таблицу пересечения, в которой будут показаны связанные между собой пары строк. В первом столбце находится имя того, кто лечит, а во втором — имя того, кто лечится.

1 ко многим: данные помещаются в отношение, одна из строк представляет человека, который приводит клиентов, а другие строки представляют клиентов, приведенных данным человеком. Строка человека, приводящего клиентов, играет роль родительской строки, а те строки, на которые она ссылается, играют роли дочерних строк. Как и для всех связей вида 1:N, ключ родителя мы вставляем в потомок.

36) Общий подход к преобразованию концептуальной модели ПрО в отношения реляционной базы данных заключается в следующем:

• построить набор предварительных отношений и указать первичные ключи для каждого отношения;

• подготовить список всех представляющих интерес атрибутов и назначить каждый из этих атрибутов одному из предварительных отношений с тем условием, чтобы эти отношения находились в НФБК. На этом шаге должны быть определены для каждого отношения межатрибутные функциональные зависимости, с помощью которых проверяется соответствие отношений НФБК. Если полученные отношения в итоге не находятся в НФБК или некоторым атрибутам не находится ло­гически обоснованных мест в предварительных отношениях, то диаграммы концептуальной модели необходимо пересмотреть.

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

Точка зрения на процесс преобразования концептуальной модели такова: если в модели присутствуют нежелательные структуры, то они должны быть исключены путем тождественной их замены на структуры данных, допустимые для реляционной модели. (объекты и атрибуты; бинарные связи типа 1:1 и типа 1:N)

Нежелательные структуры: -связи типа «многие ко многим»; -сложные связи; -рекурсивные связи; -связи с атрибутами; -множественные атрибуты; -избыточные связи.

43) Журнал транзакций на­капливает информацию об изменениях и дополнениях, которые предназначены для дальнейшей фиксации, а затем время от времени осуществляется запись части нако­пленной информации в физический файл (файлы) базы данных.

Первым делом данные попадают в журнал, который ведется на жестком диске, а в дальнейшем время от времени данные переносятся в действи­тельную базу данных.

44) Таблица состоит из так называемых данных заголовка (определений столбцов) и данных тела (самих строк). Все прикладные данные базы данных хра­нятся в таблицах.

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

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

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

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

Некластеризованный. На каждой таблице может быть задано несколько не-кластеризованных индексов.

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

45) Ядро базы данных является сердцевиной СУБД, оно отвечает за физическое структурирование и запись данных на диск, а также за физическое чтение данных с диска. Кроме того, оно принимает SQL-запросы от других компонентов СУБД, от пользовательских приложений и даже от других вычислительных систем.

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

Вот синтаксис команды создания устройства: