Базы данных

Вид материала

Документы

Содержание Вопрос №14. Уровни отображения данных в СУБД 2 Sal fixed bin(31) Employee_number character(6) Stored_emp bytes=20 Инфологический уровень Внешний уровень Концептуальный уровень Внутренний уровень Рис. 3. Схема архитектуры системы баз данных

Подобный материал:

• 1 научиться создавать таблицу базы данных в режиме таблицы, 54.71kb.
• Ms access Создание базы данных, 34.31kb.
• Лекция 2 10. Полнотекстовые базы данных, 133.46kb.
• Практическая работа № «Создание базы данных», 21.96kb.
• Информационные системы, использующие базы данных: оборудование, программное обеспечение,, 102.98kb.
• Конспект лекций по курсу "базы данных" (Ч., 861.92kb.
• Реферат на тему: Access. Базы данных, 274.77kb.
• Лекция №3 нормализация данных, 107.45kb.
• Курсовая работа по дисциплине «Базы данных» на тему: «Разработка базы данных для учета, 154.05kb.
• Создание базы данных “Классный, 73.09kb.

Вопрос №14. Уровни отображения данных в СУБД

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

• инфологический уровень;
  
• концептуальный уровень;
  
• внешний уровень;
  
• внутренний уровень.
  

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

В зависимости от уровня представления информации различают следующие типы схем:

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

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

Рис. 1. Пример уровней представления базы данных

Внешний (PL/I)		Внешний (COBOL)
DCL	1 EMPP 2 EMP# CHAR(6), 2 SAL FIXED BIN(31);			01 EMPC. 02 EMPNO PIC X(6). 02 DEPTNO PIC X(4).
Концептуальный
	EMPLOYEE EMPLOYEE_NUMBER CHARACTER(6) DEPARTMENT_NUMBER CHARACTER(4) SALARY DECIMAL(5)
Внутренний
	STORED_EMP BYTES=20 PREFIX BYTES=6, OFFSET=0 EMP# BYTES=6, OFFSET=6, INDEX=EMPX DEPT# BYTES=4, OFFSET=12 PAY BYTES=4, ALING=FULLWORD, OFFSET=16

Для лучшего понимания этих идей рассмотрим пример, представленный на рис. 1. Здесь отображено концептуальное представление простой базы данных о персонале, а также соответствующие ему внутреннее и два внешних представления (одно – для пользователя, применяющего язык PL/I, а другое – для пользователя, применяющего язык COBOL). Конечно, этот пример полностью гипотетичен и мало похож на реальные системы, поскольку в нем умышленно исключены многие не относящиеся к делу детали.

1. На концептуальном уровне БД содержит информацию о типе сущности с именем EMPLOYEE (служащий). Каждый экземпляр сущности EMPLOYEE включает атрибуты номера служащего EMPLOYEE_NUMBER (шесть символов), номера отдела DEPARTMENT_NUMBER (четыре символа) и зарплаты служащего SALARY (пять десятичных цифр).
   
2. На внутреннем уровне служащие предоставлены типом хранимой записи STORED_EMP, длина которой составляет 20 байтов. Запись STORED_EMP содержит четыре хранимых поля: шестибайтовый префикс (возможно, содержащий управляющую информацию, такую как флаги и указатели) и три поля данных, соответствующие трем свойствам сущности, которая представляет служащего. Кроме того, записи STORED_EMP индексированы по полю EMP# с помощью индекса EMPX, определение которого не показано.
   
3. Пользователь, применяющий язык PL/I, имеет дело с соответствующим внешним представлением БД. В нем каждый сотрудник представлен записью на языке PL/I, содержащей два поля (номера отделов данному пользователю не требуются, поэтому в представлении они опущены). Тип записи определен с помощью обычной структуры, соответствующей правилам языка PL/I.
   
4. Аналогично, пользователь, применяющий язык COBOL, имеет дело с собственным внешним представлением БД, в котором каждый сотрудник представлен записью на языке COBOL, содержащей, опять же два поля (в данном случае опущен размер оклада). Тип записи определен с помощью обычного описания на языке COBOL в соответствии с принятыми в нем стандартными правилами.
   

Обратите внимание, что в каждом случае соответствующие элементы данных могут иметь различные имена. Например, к номеру сотрудника обращаются как к полю EMP# в представлении для языка PL/I и как к полю EMPNO в представлении для языка COBOL. Этот же атрибут в концептуальном представлении имеет имя EMPLOYEE_NUMBER, а во внутреннем представлении – имя EMP#. Конечно, в системе должны быть известны все эти соответствия. Такие соответствия или отображения, на рис. 1 явно не показаны.

Инфологический уровень

Рис. 2. Пример инфологической схемы (диаграмма «сущность-связь») для базы данных компании

Рассмотрим пример инфологической схемы некоторой промышленной компании. Обычно подобному предприятию требуется записывать информацию об имеющихся проектах (Projects), используемых в этих проектах деталях (Parts), поставщиках (Suppliers) деталей, складах (Warehouses), на которых хранятся детали, служащих (Employees), работающих над проектами и т.д. Проекты, детали, поставщики и т.д. представляют собой основные сущности (entity), о которых компании необходимо хранить информацию. В теории баз данных термин сущность обычно используется для обозначения любого различимого объекта, который может быть представлен в базе данных рис. 2.

Кроме этих основных сущностей (в данном примере это поставщики, детали и т.д.), имеются еще и связи (relationship) между ними, которые объединяют эти основные сущности. На рис. 2 связи представлены ромбами с соединительными линиями. Например, между поставщиками и деталями существует связь SP: каждый поставщик поставляет определенные детали, и наоборот, каждая деталь поставляется определенными поставщиками. Аналогично, детали используются в проектах, а для реализации проектов требуются детали (связь PJ) и т.д. Эти связи бинарные (или двухсторонние), т.е. их можно прослеживать в любом направлении. В частности, используя связь SP между поставщиками и деталями, можно ответить на следующие вопросы:

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

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

В примере есть одна связь (SPJ), охватывающая три типа сущностей (Suppliers, Parts и Projects). Это пример тернарной (трехсторонней) связи. Интерпретация данной связи такова: определенные поставщики поставляют определенные детали для определенных проектов. Но такая связь не эквивалентна простой комбинации из трех бинарных связей. Например:

1. «Смит поставляет разводные гаечные ключи для Манхэттенского проекта».
   
2. «Смит поставляет разводные гаечные ключи».
   
3. «Разводные гаечные ключи используются в Манхэттенском проекте».
   
4. «Манхэттенский проект снабжается Смитом».
   

Зная только утверждения b, c и d, мы не сможем доказать справедливость утверждения a. Точнее, зная, что справедливы утверждения b, c и d, мы можем лишь сделать заключение, что Смит поставляет разводные гаечные ключи для какого-то проекта, что какой-то поставщик поставляет разводные гаечные ключи для Манхэттенского проекта и что Смит поставляет какую-то деталь для Манхэттенского проекта. Однако мы не можем утверждать, что какой-то поставщик – это Смит, какая-то деталь – это разводной гаечный ключ, а какой-то проект – это Манхэттенский проект. Ложные выводы, сделанные на основании неполной информации, называются дефектом соединения.

На схеме также есть одна связь (PP), которая связывает один тип сущности (Parts) с самим собой. Эта связь означает, что одни детали содержат другие детали как собственные компоненты (так называемая связь спецификации материалов, или связь «деталь-узел»).

Внешний уровень

Внешний уровень – это индивидуальный уровень пользователя.

У каждого пользователя есть свой язык для работы с СУБД.

• Для прикладного программиста это либо один из распространенных языков программирования (например, PL/I, C++ или Java), либо специальный язык рассматриваемой системы.
  
• Для конечного пользователя это или специальный язык запросов, или язык специального назначения, который может быть основан на использовании форм и меню.
  

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

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

Любой подъязык данных является на самом деле комбинацией, по крайней мере, двух подчиненных языков – языка определения данных (Data Definition Language - DDL), который позволяет формулировать определения или объявления объектов базы данных, и языка манипулирования данными (Data Manipulation Language - DML), который поддерживает операции с такими объектами или их обработку.

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

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

Концептуальный уровень

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

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

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

Внутренний уровень

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

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

Отображения

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

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

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

Рис. 3. Схема архитектуры системы баз данных

Таким образом, инфологический уровень предусматривает создание инфологической модели данных предметной области, независящей от каких-либо характеристик СУБД, в которой будет реализован проект. Концептуальный уровень предполагает создание концептуальной модели, в которой из инфологической модели удаляются (или преобразуются) элементы, которые не могут быть реализованы в СУБД, выбранной в качестве целевой. Внешний уровень формирует индивидуальные представления о хранимой информации для пользователей системы с помощью специального языка (обычно это SQL – Structured Query Language или QBE – Query By Example). Внутренний уровень преобразует концептуальную модель в физическую модель, предназначенную для реализации (хранения в виде баз данных и таблиц) в среде конкретной целевой СУБД.