трбд лекции. Лекция 1 Общие сведения

• Название: Лекция 1 Общие сведения
• Анкор: трбд лекции
• Дата: 11.12.2022
• Размер: 231.5 Kb.
• Имя файла: kurs_lekciy_trbd.doc
• Тип: Лекция; #839478
• страница: 5 из 5

3. Системы управления базами данных. Компоненты и структуры данных

3.1. Обзор современных СУБД
Развитие СУБД началось еще в 60-е годы прошлого века, когда разрабатывался проект полета корабля Apollo на Луну. Была разработана система GUKM (Generalized Update Access Method), использующая иерархическую структуру.

Затем была предложена система IDS (Integrated Data Store), основанная на сетевой структуре.

В 1970 году Кодд предложил реляционную модель данных, ставшую основой реляционных баз данных. Первые коммерческие продукты появились в конце 60-х – начале 80-х годов, тогда же был разработан структурированный язык запросов SQL. В 80-х годах были созданы различные реляционные СУБД – DB2, Oracle и другие.

В настоящее время существует несколько десятков различных реляционных СУБД. Для персональных компьютеров – это Access, FoxPro, Paradox, InterBase, FireBird, Oracle и др.

В 1976 году Чен предложил модель "сущность-связь" (Entity Relationship model – ER модель), которая в настоящее время стала самой распространенной технологией проектирования баз данных.

Появились две новые системы: объектно-ориентированная СУБД или ООСУБД и объектно-реляционная СУБД или ОРСУБД. Однако действительная структура этих моделей не совсем ясна. Эти СУБД относятся к СУБД третьего поколения и еще до конца не разработаны.

Современные СУБД кратко характеризуются следующими принципами их построения:

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

В настоящее время число используемых СУБД превышает несколько

десятков.


Основные термины:

CASE- средства (Computer Assisted System Engineering).

Нормализация РБД – одна из возможных технологий проектирования РБД.

Файл-серверные СУБД и клиент-серверные СУБД.

Транзакции – transformation action.

Отношение – плоская таблица, состоящая из столбцов и строк.

Триггер – действие, связанное с событием, которое возникает при попытке изменить содержимое таблицы.

Хранимые процедуры – Stored procedure – процедуры, выполняемые на стороне сервера.


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

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

Архитектура большинства современных СУБД строится на базе так называемой архитектуры ANSI – SPARC (American National Standard Institute Standards Planning and Requirements Committee). Хотя модель ANSI/SPARC не стала стандартом, тем не менее, она представляет собой основу для понимания некоторых функциональных особенностей СУБД.

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

В модели определены три уровня – внешний, концептуальный и внутренний (см. рис.5).

Причины, по которым желательно выполнять такое разделение:

• 
  Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, используя свое собственное представление о них.
  
• 
  Пользователи не должны иметь дело с подробностями физического хранения данных в базе.
  
• 
  АБД должен иметь возможность изменять структуру хранения данных в базе, не оказывая влияния на пользовательское представление.
  

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


Рис. 5. Архитектура современных СУБД

Каждый пользователь имеет дело с представлением «реального мира», выраженным в наиболее удобной для него форме.

Интерес представляют следующие понятия:

1. 
   Сущность – объект «реального мира», такой как Работник, Отдел, Договор.
   
2. 
   Атрибуты – свойства или качества каждой сущности (например, Имя, Адрес, Зарплата для сущности Работник).
   
3. 
   Связи – взаимоотношения между сущностями (например, Работник работает в Отделе).
   

Внешнее представление пользователя содержит только те сущности, атрибуты и связи «реального мира», которые интересны этому пользователю. Другие сущности, атрибуты и связи, которые ему не интересны, также могут быть представлены в базе данных, но они важны для другого пользователя.

(Адрес – для отдела кадров, а бухгалтерия может им не пользоваться).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Модель данных можно рассматривать как сочетание трех указанных ниже компонентов:

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

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

Для трехуровневой архитектуры существуют следующие три связанные модели данных (объектные модели):

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

Silverrun BPM (функциональная модель, модель потоков данных).

Внешние объекты, процессы, потоки, накопители.

Описание структур данных.

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

Silverrun ERX (ER – модель).

Сущности, связи, атрибуты.

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

Silverrun RDM (логическая модель, для конкретной СУБД – реляционная модель для реляционной СУБД).

Домены, типы атрибутов.

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

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

Существует три основных типа записей, определяющие три типа моделей:

• 
  реляционная модель данных (relational data model);
  
• 
  сетевая модель данных (network data model);
  
• 
  иерархическая модель данных (hierarchical data model).
  

Реляционная модель данных основана на понятии математических отношений. В реляционной модели данные и связи представлены в виде таблиц (см. рис.7), каждая из которых имеет несколько столбцов с уникальными именами.
Сущность «Работник»

StaffNo	FName	LName	DOB	Salary	BranchNo
2152	Иван	Егоров	20.02.1935	3500	02
2876	П етр	Сивохин	2.12.1981	2500	11

Сущность «Отдел»

BranchNo	Name	№ комнаты
02	Отдел сбыта	21
11	Плановый отдел	18

Рис.7 Описание данных в реляционной модели
В реляционной модели данных единственное требование состоит в том, чтобы база данных с точки зрения пользователя выглядела как набор таблиц. Это требование относится только к внешнему и концептуальному уровням архитектуры ANSI/SPARC.

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

Наиболее важные термины описания структуры данных представлены на рисунке 10.

Отношение – плоская таблица, состоящая из столбцов и строк.

Атрибут – поименованный столбец отношения.

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

Кортеж – строка отношения.

Степень – количество атрибутов, содержащихся в отношении.

Кардинальность – количество кортежей, которое содержит отношение.

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

Отношения обладают следующими свойствами:

1. 
   в них нет одинаковых кортежей;
   
2. 
   кортежи отношения не имеют упорядоченности в направлении сверху вниз;
   
3. 
   атрибуты в кортежах не упорядочены слева направо;
   
4. 
   каждый кортеж содержит ровно одно значение для каждого атрибута.
   

Свойство 1: Свойство следует из того факта, что тело отношения – это математическое множество (кортежей), а в математике множества по определению не содержат одинаковых элементов.

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

Свойство 2: Свойство следует из того, что тело отношения – это математическое множество, а простые множества в математике не упорядочены.

В таблице строки упорядочены сверху вниз.

Свойство 3: Свойство следует из того факта, что заголовок отношения также определен, как множество (атрибутов). Атрибут всегда определяется по имени, а не по расположению.

В таблице столбцы могут быть упорядочены.

Свойство 4: Свойство следует из определения кортежа: кортеж является множеством из n компонентов. Отношение, удовлетворяющее этому свойству, называется нормализованным или представленным в первой нормальной форме (1НФ).

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

Дополнительные свойства:

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

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

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

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

Такой ключ обладает двумя свойствами:

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

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

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