44) Реляционный подход построения бд. Реляционная структура данных.

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

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

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

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

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

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

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

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

45) Операции над данными. Понятия агрегации и обобщения.

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

 

Можно выделить следующие основные операции над данными:

1. сбор данных– накопление информации с целью обеспечения достаточной полноты для принятия решений;

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

3. фильтрация данных – отсеивание «лишних» данных, в которых нет необходимости для принятия решений; при этом должен уменьшаться уровень «шума», а достоверность и адекватность данных должны возрастать;

4. сортировкаданных – упорядочение данных по заданному признаку с целью удобства использования; повышает доступность информации;

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

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

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

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

46) Универсальное отношение. Нормальная таблица при проектировании БД. Понятие нормализации.

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

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

Блюдо

Вид

Рецепт

Порций

Дата Р

Продукт

Калорийность

Вес (г)

Поставщик

Город

Страна

Вес (кг)

Цена ($)

Дата П

Лобио

Закуска

Лом.

158

1/9/94

Фасоль

3070

200

"Хуанхэ"

Пекин

Китай

250

0.37

24/3/01

Лобио

Закуска

Лом

108

1/9/94

Лук

450

40

"Наталка"

Киев

Украина

100

0.52

27/3/01

Лобио

Закуска

Лом

108

1/9/94

Масло

7420

30

"Лайма"

Рига

Латвия

70

1.55

30/3/01

Лобио

Закуска

Лом

108

1/9/94

Зелень

180

10

"Даугава"

Рига

Латвия

15

0.99

30/3/01

Харчо

Суп

...

144

1/9/94

Мясо

1660

80

"Наталка"

Киев

Украина

100

2.18

27/3/01

Харчо

Суп

...

144

1/9/94

Лук

450

30

"Наталка"

Киев

Украина

100

0.52

27/3/01

Харчо

Суп

...

144

1/9/94

Томаты

240

40

"Полесье"

Киев

Украина

120

0.45

27/3/01

Харчо

Суп

...

144

1/9/94

Рис

3340

50

"Хуанхэ"

Пекин

Китай

75

0.44

24/3/01

Харчо

Суп

...

144

1/9/94

Масло

7420

15

"Полесье"

Киев

Украина

50

1.62

27/3/01

Харчо

Суп

...

144

1/9/94

Зелень

180

15

"Наталка"

Киев

Украина

10

0.88

27/3/01

Шашлык

Горячее

...

207

1/9/94

Мясо

1660

180

"Юрмала"

Рига

Латвия

200

2.05

30/3/01

Шашлык

Горячее

...

207

1/9/94

Лук

450

40

"Полесье"

Киев

Украина

50

0.61

27/3/01

Шашлык

Горячее

...

207

1/9/94

Томаты

240

100

"Полесье"

Киев

Украина

120

0.45

27/3/01

Шашлык

Горячее

...

207

1/9/94

Зелень

180

20

"Даугава"

Рига

Латвия

15

0.99

30/3/01

Кофе

Десерт

...

235

1/9/94

Кофе

2750

8

"Хуанхэ"

Пекин

Китай

40

2.87

24/3/01

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

47) Функциональная и многозначная зависимость:

Функциональная зависимость, по сути, является связью типа «многие одному» между множествами атрибутов (столбцов) рассматриваемого отношения. Т.е., если в отношении R, содержащем атрибуты А и В, атрибут В функционально зависит от атрибута А, то каждое отдельное значение атрибута А связано только с одним значением атрибута В (причем в качестве А и В могут выступать группы атрибутов).

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

48) Нормальные формы. Проблемы нормализации:

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

Процесс преобразования отношений базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры БД к виду, обеспечивающему минимальную логическую избыточность, и не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение физического объёма базы данных.^[1] Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в базе данных информации. Как отмечает К. Дейт,^[2] общее назначение процесса нормализации заключается в следующем:

• исключение некоторых типов избыточности;

• устранение некоторых аномалий обновления;

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

• упрощение процедуры применения необходимых ограничений целостности.

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

49) Процедура проектирования БД. Основные этапы построения БД.

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

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

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

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

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

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

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

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

8. Указать ограничения целостности проектируемой базы данных и дать (если это необходимо) краткое описание полученных таблиц и их полей.

50) Транзакции:

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

Операция считается транзакцией, если она удовлетворяет требованиям  ACID-теста (Atomicity, Consistency, Isolation, Durability атомарность, согласованность, изолированность, долговечность).

Атомарность - лозунг транзакции - "Все или ничего": при завершении транзакции оператором COMMIT результаты гарантированно фиксируются во внешней памяти (смысл слова commit - "зафиксировать" результаты транзакции); при завершении транзакции оператором ROLLBACK результаты гарантированно отсутствуют во внешней памяти (смысл слова rollback - ликвидировать результаты транзакции).

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

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

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

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

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

51) Классификация таблиц БД. Классификация информационных систем:

Информационные системы классифицируются по разным признакам. Рассмотрим наиболее часто используемые способы классификации.

Классификация по масштабу

По масштабу информационные системы подразделяются на следующие группы:

• одиночные;

• групповые;

• корпоративные.

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

Одиночные информационные системы реализуются, как правило, на автономном персональном компьютере (сеть не используется). Такая система может содержать несколько простых приложений, связанных общим информационным фондом, и рассчитана на работу одного пользователя или группы пользователей, разделяющих по времени одно рабочее место. Подобные приложения создаются с помощью так называемых настольных или локальных систем управления базами данных (СУБД). Среди локальных СУБД наиболее известными являются Clarion, Clipper, FoxPro, Paradox, dBase и Qicrosoft Access.

Групповые информационные системы ориентированы на коллективное использование информации членами рабочей группы и чаще всего строятся на базе локальной вычислительной сети. При разработке таких приложений используются серверы баз данных (называемые также SQL-серверами) для рабочих групп. Существует довольно большое количество различных SQL-серверов, как коммерческих, так и свобод­но распространяемых. Среди них наиболее известны такие серверы баз данных, как Oracle, DB2, Qicrosoft SQL Server, InterBase, Sybase, Inforqix.

Корпоративные информационные системы являются развитием систем для рабочих групп, они ориентированы на крупные компании и могут поддерживать территориально разнесенные узлы или сети. В основном они имеют иерархическую структуру из нескольких уровней. Для таких систем характерна архитектура клиент-сервер со специализацией серверов или же многоуровневая архитектура. При разработке таких систем могут использоваться те же серверы баз данных, что и при разработке групповых информационных систем. Однако в крупных информа­ционных системах наибольшее распространение получили серверы Oracle, DB2 и Qicrosoft SQL Server.

Классификация по сфере применения

По сфере применения информационные системы обычно подразделяются на четыре группы:

• системы обработки транзакций;

• системы принятия решений;

• информационно-справочные системы;

• офисные информационные системы.

Системы обработки транзакций, в свою очередь, по оперативности обработки данных, разделяются на пакетные информационные системы и оперативные информационные системы. В информационных системах организационного управления преобладает режим оперативной обработки транзакций – OLTP (OnLine Transaction Processing), для отражения актуального состояния предметной области в любой момент времени, а пакетная обработка занимает весьма ограниченную часть. Для систем OLTP характерен регулярный (возможно, интенсивный) поток довольно простых транзакций, играющих роль заказов, платежей, запросов и т.п. Важными требованиями для них являются:

• высокая производительность обработки транзакций;

• гарантированная доставка информации при удаленном доступе к БД по телекоммуникациям.

Системы поддержки принятия решений – DSS (Decision Support Systeq) – представляют собой другой тип информационных систем, в которых с помощью довольно сложных запросов производится отбор и анализ данных в различных разрезах: временных, географических и по другим показателям.

Обширный класс информационно-справочных систем основан на гипертекстовых документах и мультимедиа. Наибольшее развитие такие информационные систе­мы получили в сети Интернет.

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

Классификация по способу организации

По способу организации групповые и корпоративные информационные системы подразделяются на следующие классы:

• системы на основе архитектуры файл-сервер;

• системы на основе архитектуры клиент-сервер;

• системы на основе многоуровневой архитектуры;

• системы на основе Интернет/ интеранет-технологий.

52) Архитектура БД:

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

1. Уровень  внешних моделей — самый верхний уровень, где каждая модель имеет свое  «видение» данных. Этот уровень определяет точку зрения на БД отдельных  приложений. Каждое приложение видит и обрабатывает только те данные,  которые необходимы именно этому приложению. Например, система распределения  работ использует сведения о квалификации сотрудника, но ее не интересуют сведения  об окладе, домашнем адресе и телефоне сотрудника, и  наоборот, именно эти сведения используются в подсистеме отдела кадров.

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

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

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

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

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

53) Построение приложений в архитектуре клиент-сервер:

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

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

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

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

54) SQL – язык программирования БД. Основные концепции работы с данными на SQL.

QL (Structured Query Language — Структурированный язык запросов) — язык управления базами данных для реляционных баз данных. Сам по себе SQL не является Тьюринг-полным языком программирования, но его стандарт позволяет создавать для него процедурные расширения, которые расширяют его функциональность до полноценного языка программирования.

Язык был создан в 1970х годах под названием “SEQUEL” для системы управления базами данных (СУБД) System R. Позднее он был переименован в “SQL” во избежание конфликта торговых марок. В 1979 году SQL был впервые опубликован в виде коммерческого продукта Oracle V2.

Первый официальный стандарт языка был принят ANSI в 1986 году и ISO — в 1987. С тех пор были созданы еще несколько версий стандарта, некоторые из них повторяли предыдущие с незначительными вариациями, другие принимали новые существенные черты.

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

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

55) SQL. Работа с БД:

Microsoft SQL Server Compact поддерживает различные функции для работы с базами данных, такие как создание, доступ, изменение, обеспечение безопасности, запросы и обслуживание.

Раздел	Описание
Обзор баз данных (SQL Server Compact)	Обзор баз данных SQL Server Compact.
Обзор компонента Database Engine (SQL Server Compact)	Вводные сведения о компоненте SQL Server Compact Database Engine и его использовании.
Основные сведения о базах данных (SQL Server Compact)	Описание объектов и типов баз данных, а также временных баз данных.
Использование и обслуживание баз данных (SQL Server Compact)	Описание способов выполнения обычных задач, связанных с базой данных, а также обслуживания базы данных SQL Server Compact.
Обеспечение безопасности баз данных (SQL Server Compact)	Описание защиты баз данных с помощью паролей и шифрования.
Доступ и изменение баз данных (SQL Server Compact)	Описание более сложных функций компонента SQL Server Compact Database Engine, в том числе транзакций, блокировок, многопользовательского доступа и курсоров.
Выполнение запросов к базам данных (SQL Server Compact)	Описание параметров запросов и модификации данных.
Вопросы международного использования (SQL Server Compact)	Вопросы международного использования SQL Server Compact.
Управление 64-разрядными приложениями баз данных	Требования для управления 64-разрядными базами данных SQL Server Compact.

56) SQL. Работа с доменами: