Приложения и компоненты базы данных. Словарь данных

Приложения БД = формы, отчеты, Web-страницы и прикладные программы.

Запросы – требования польз-ля на отбор Д из БД на выполнение орп-х дейс-ий.

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

Отчеты  это формат-ое отображ И из БД при выводе на печать.

Web-страницы исп-ся для просмотра, редакт-я, обновления, удаления, отбора, группировки и сортировки изменяющихся данных базы данных в Microsoft Internet Explorer.

Компоненты БД 4 основных компонент: данных пользователя, метаданных, индексов и метаданных приложений.

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

Метаданные представ-ют собой описание стр-ры БД с помощью так наз системных таблиц.

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

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

2.10 Трехуровн модель орг-ции БД. 3 уровня предс-тавления Д: внешний, концептуальн и внутрен

 

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

2.11 Понятие МД. Иерархич модель, ее + и --.

Ядро любой БД – модель данных – сов-ть структур Д и операций их обработки. Наиб важный принцип отличия – способ орг-ции связей м/ду данными в базе. Класич-ие МД – иерархическая (ИМД), сетевая и реляционная.

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

Операции над Д в ИМД: Добав, Измен, Удал, Извлечь

+ простота, эф-ное исп-е памяти, неплохая скорость выпол операций

-- громоздкость в обработке Д, доступ к И возможен только по вертикальн схеме, огранич применение.

2.12 Сетевая модель, ее + и --.

Сетевая модель (СМД) – это стр-ра, у к-ой любой элемент м б связан с любым другим элементом.

Сетевая БД сос-т из наборов записей, к-ые связаны между собой так, что записи могут содержать явные ссылки на другие наборы записей. Тем самым наборы записей образуют сеть. Операции над Д в СМД: Добав, Извлечь, Обнов, Удал, Включить в группов отношение, Исключить из группового отношения, Переключить.

+ высокая эффек-ть затрат памяти и оперативность, Д более равноправны (доступ м б осущ-н, начиная с люб узла).

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

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

2.13 Реляцион модель. Ее базов понятия, + и --.

Реляционная модель (РМД) - сов-ть Д, состоящая из набора таблиц, между котор устанавлив связи. РМД была предложена Коббом, котор в 1970г вперв сформулир-л ее основ понятия, явл удобной и наибол привычн формой представления Д.

Любая таблица в реляционной базе состоит из строк (записи), и столбцов (поля). На пересечении строк и столбцов находятся конкретные значения Д.

В основе РМД лежит понятие «отношение». Отнош-е отображ нек-ый объект, объект хар-ся набором атрибутов, каждый атрибут – набором допустимых значений (доменом). Список имен атрибутов наз-ся схемой отношения, а кол-во атрибутов в отн-ии – степень отношения. Столбцы этой табл соот-т атрибутам, а строки наз-ся кортежами. Кол-во картежей в отн-ии наз-ся мощностью отношения.

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

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

системы управления БД используют именно реляционную модель: dBase, FoxBase, FoxPro, Paradox, Oracle, Microsoft Access, Clarion, Clipper, Ingres; отечественные: ПАЛЬМА, HyTech и др.

2.14 Связь м/ду Т в РМД. Первич и внеш ключи, их отлич.

Данные об объектах в базе связаны м/ду собой. Типы:

Связь 1:1: означ, что каждому элем-ту объекта А может соотв-ть только один элемент объекта В и наоборот.

Связь 1:М: …могут существовать экземпляры объекта А, к-ым соотв-т более одного экз-ра объекта В. Но при этом каждому экз-ру объекта В может соответствовать только один экз-р объекта А.

Связь М:1: … каждому экземпляру объекта А может соотв-ть только один экз-р объекта В, но среди экз-в объекта В могут быть такие, которым соответствует несколько экз-в объекта А.

Связь М:N, или групповое … может сущ экз-р объекта А, к-ому соотв-т несколько экз-в объекта В и наоборот.

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

Виды: простой, сост из 1 поля, сложный, из нескольк п.

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

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

2.15 Реляц целостность: цел-ть отнош-й, ссылочн цел-ть.

В РМД должны ваполн условия целостности Д.

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

 

 

2.16 Операции реляц алгебры: объед, пересеч, разность, декартово произвед-е, проекция, выборка, соедин, делен.

Основными операциями в реляц базе явл операции обновления БД и операции обработки отношений.

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

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

2.17 Постреляционная модель, ее + и --.

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

+ постреляц модели явл-ся возможность представления сов-ти связанных реляц табл в виде одной постреляц таблицы (Д хран более компактно). Эфф-ть обработки и высок наглядность

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

Постреляц модель данных реализована в СУБД uniVers, Bubba и Dasdb.

 

 

2.18 Объекто-ориентир МД. Ее базов понятия, + и --.

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

мех-мы – наследование, инкапсуляция, полиморфизм.

Инкапсуляция – объед-е в един целое Д и алгоритмов (функций и методов) их обработки, а также скрытие Д внутри объектов, что повыш надежн-ть разрабатываем програм обесп-я. Наследование – возм-ть порождать один класс от др с сохр всех св-в и методов класса-предка и добавлением при необх-ти новых свойств и методов. Отображ иерархичность. Полиморфизм – спос-ть объектов по-разном реагировать на одно и то же событие в окруж-м мире. («печать рез-та» работает для каждого по-разному)

+ возможность отображ И о сложных взаимосвязях объектов, идентифицировать отдельные записи в базе и определять функции их обработки.

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

Сегодня уже разработаны и успешно функционируют такие системы управления базами данных как: Iris, Orion и др., – обслуживающие эти модели.

 

2.19 Объектно-реляционная МД, ее + и --.

Эта модель включ в себя основные «+» ООМД и одноврем простоту стр-ры РМД, и потому стала назыв ОРМД. Исходя из этого, модель ОРМД наиболее приспособлена для бизнес-приложений. Некоторые специалисты полагают, что в будущем произойдет слияние ООМД и ОРМД моделей. Однако есть и ряд --, основные из которых следующие:

•отсутствие унифицирован теории, есть в реляцион М;

•отсутствие формальной методологии проектирования БД, как нормализация в реляц базах;

•отсутствие специальных средств создания запросов;

•отсутств общих правил определ-я целостности и др.

 

 

2.20 Многомерная МД, ее базовые понятия, + и --.

И в ММД представ-ся в виде многомерных массивов, (гиперкубов). В одной БД, построенной на многомерн модели, может храниться мн-во таких кубов, на основе котор можн проводить совместн анализ показателей. Многомерн БД хорошо обслуж-т именно аналитич обработку Д и обычно явл узко специализированными. Они обеспеч более быстр поиск и чтение Д по сравнен с РМД, а такж избавляют от необход-ти многократного связывания таблиц. Измерение – это мн-во однотипн Д, образ-х одну из граней гиперкуба. (дни, квартал, год; район, город, страна) Ячейка – это поле, знач кот однозначн определ-ся фиксиров набором измерений.

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

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

Примеры Essbase, Oracle Express Server.

3.21 Понятие проектирования БД. Требования, предъявляемые к БД.

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

1) целостность БД - требование полноты и непротиворечивости данных;

2) многократное использ-е данных;

3) быстрый поиск и получ-е И по запросам польз-й;

4) простота обновления и модификации данных;

5) отсутствие дублирования данных;

6) компактное и надежное хранение данных.