Концептуальное представление данных требования

15.04.2018 Выкл. Автор admin

Уровни моделей данных

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

Цель трехуровневой архитектуры заключается в отделении пользовательского представления БД от ее физического представления. Причины:

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

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

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

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

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

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

  • Распределение дискового пространства для хранения данных и индексов;
  • Описание подробностей сохранения записей ( с указанием реальных размеров сохраняемых элементов данных);
  • Сведения о размещении записей;
  • Сведения о сжатии данных и выбранных методах их шифрования.

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

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

Три основные компоненты модели данных:

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

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

«+» простота организации, эффективное использование памяти ЭВМ для иерархической ПО, неплохая производительность даже на медленных ЭВМ.

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

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

В сетевой модели существует две основные структуры данных:

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

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

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

3. Реляционная – разработанная Э.Коддом в 1970г. логическая модель данных, описывающая:

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

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

Тип данных – характеристика набора данных, которая определяет: диапазон возможных значений данных из набора (домен); допустимые операции, которые можно выполнять над этими значениями; способ хранения этих значений в памяти. В современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как деньги), а также специальных «темпоральных» данных (дата, время, временной интервал).

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

Не требуется операция join. Проблема целостности и непротиворечивости данных решается только средствами СУБД (по аналогии с процедурами в клиент-серверных моделях).

«+» можно представить несколько реляционных таблиц в одной постреляционной, увеличивается наглядность и эфф-ть обработки.

«–» проблема контроля целостности и непротиворечивости данных.

5. Многомерная (OLAP. online analytical processing, аналитическая обработка в реальном времени).

Многомерное логическое представление структуры данных при их описании и в операциях над ними.

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

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

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

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

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

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

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

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

Основное отличие от иерархической модели в методах манипулирования данными:

Инкапсуляция – свойство видно только в пределах того объекта, в котором оно определено.

Наследование – свойство видимо всем потомкам объекта.

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

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

«–» неудобство обработки данных, низкая скорость выполнения запросов.

Концептуальное представление данных требования

Сервис бесплатной оценки стоимости работы

  1. Заполните заявку. Специалисты рассчитают стоимость вашей работы
  2. Расчет стоимости придет на почту и по СМС

Номер вашей заявки

Прямо сейчас на почту придет автоматическое письмо-подтверждение с информацией о заявке.

Большая Энциклопедия Нефти и Газа

Концептуальное представление

Следует отметить, что эта теория иерархических систем достаточно близко примыкает к системологии именно в смысле координации, которую можно считать центральным положением теории Месаровича. Концептуальное представление теории иерархических систем и системологии сводится к тому, что в модуле — двух уровневой системе — имеются три уровня целей: низший — цели низшего уровня, координационный — цели блоков верхнего уровня ( координатора) и глобальный — цели всей большой системы. Ключевым в системологии является понятие система. В строгой постановке под системой будем подразумевать определенное во времени и в пространстве множество элементов с известными свойствами и с упорядоченными связями между элементами и свойствами, ориентированными на выполнение главной задачи данного множества. [16]

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

Центральный прямоугольник на рис. 3.1 ( этап 4) является очень важным элементом в современных структурах баз данных. Он обозначает концептуальное представление данных в системе. Иногда его определяют как модель данных или концептуальную модель. Иногда называют схемой или концептуальной схемой. Концептуальная схема должна быть разработана таким образом, чтобы быть по возможности стабильной. [18]

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

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

Предложен новый подход для построения методов классификации функциональных семейств белков. Этот подход основан на применении концептуального представления экспертных знаний [ 9] в молекулярной биологии. Отличительной чертой этого подхода является отображение знаний в виде списков инфомации и взаимодействующих с ними программ для представления и обработки информации. [21]

В таком понимании оно является результатом объединения внешних представлений, для которых проектируется база данных. Для моделируемой предметной области существует только одно концептуальное представление данных , которое структурно не связано с сетевыми, иерархическими или реляционными моделями баз данных. [22]

Реляционная модель является моделью данных в этом смысле, и она является первой, удовлетворяющей этому определению. Структурная часть реляционной модели данных состоит из доменов, отношений неопределенного порядка ( relations of assorted degrees) ( основным средством концептуального представления которых являются таблицы), атрибутов, кортежей ( tuples), потенциальных ключей и первичных ключей. В соответствии с выбранным представлением атрибуты становятся столбцами таблиц, а кортежи — строками, но здесь, когда это касается таблиц нашей базы данных, не существует понятия того, что один столбец таблицы следует за другим или одна строка следует за другой. Другими словами, в этих таблицах порядок столбцов слева направо и порядок строк сверху вниз является произвольным и несущественным. [23]

Концептуальная схема призвана обеспечить прочную и долговременную основу проектирования БД. Такая схема должна строиться вне зависимости от конкретной СУБД, в которой она будет реализована. Двумя наиболее важными свойствами концептуального представления данных являются следующие: оно должно быть настолько простым, насколько это практически возможно, и должно иметь серьезную теоретическую основу [ 19, с. [24]

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

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

При концептуальном проектировании определяется общий вид всей системы и ее потребности в данных. Если по какой-либо причине требования изменятся, то в это время мы сможем изменить общий вид. Вдобавок к независимости от программного обеспечения, концептуальное представление позволяет нам определить все возможные источники получения данных. Хотя ГИС не должна быть движима исключительно лишь данными, ее функциональность и даже жизнеспособность могут в значительной степени определяться доступностью, ценой и качеством данных для решения поставленных задач. Это значит, что нам может потребоваться использование разнородного ПО или выдвижение предложения об изменении бюджета проекта для приобретения дополнительных данных. Возможно даже, что мы поймем, что ГИС не является практически осуществимым или жизнеспособным решением для данной организации. [27]

Читайте так же:  Бюджетные полномочия органов гос власти

Иногда возникают следующие вопросы: Почему такая мо-дель называется реляционной моделью данных. Для этого есть две причины: ( Г) Когда реляционная модель данных была предложена впервые, многие людй, занимающиеся обработкой данных, считали, что отноше-шие между двумя или более объектами нужно представлять с помощью связных структур данных ( и название было1 дано так, чтобы учесть это неправильное представление); ( 2) понятие таблицы находится на более низком уровне абстракции, чем понятие отношения, так как при его использовании создается впечатление, что применим способ адресации по позиции ( в то время как это неверно для отношений / г-го порядка), и тот факт, что содержание информации в таблице не зависит от порядка строк, не является очевидным. Тем не менее, даже обладая этими несущественными недостатками, таблицы являются основным средством концептуального представления отношений , потому что слово таблица понятно всем. [28]

В своей работе о гипергеометрических функциях, связанных с торическими многообразиями [ G-K-Z 1 ], Гельфанд, Зелевинский и Капранов ввели новый комбинаторный объект, ассоциированный с конечным множеством А из п точек в R: вторичный многогранник QQ ( A), лежащий в Rn, который задается при помощи регулярных триангуляции2 множества А. Один из их основных результатов ( см. [ G-K-Z 2 ]), о котором пойдет речь в этой статье, заключается в том, что QQ ( A) является многогранником Ньютона дискриминанта, соответствующего множеству А. Кроме того, они дают явную формулу для коэффициентов при крайних мономах дискриминанта. В частности, эти коэффициенты всегда с точностью до знака являются произведениями целых чисел вида NN. Недавно Капранов, Штурмфельс и Зелевинский [ K-S-Z ] дали более концептуальное представление этих результатов в терминах торических вырождений и форм Чжоу. [29]

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

Концептуальное представление данных требования

Работа добавлена: 2016-06-22

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

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

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

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

Концептуальное представление данных требования

Большая Энциклопедия Нефти и Газа

Концептуальное представление

Следует отметить, что эта теория иерархических систем достаточно близко примыкает к системологии именно в смысле координации, которую можно считать центральным положением теории Месаровича. Концептуальное представление теории иерархических систем и системологии сводится к тому, что в модуле — двух уровневой системе — имеются три уровня целей: низший — цели низшего уровня, координационный — цели блоков верхнего уровня ( координатора) и глобальный — цели всей большой системы. Ключевым в системологии является понятие система. В строгой постановке под системой будем подразумевать определенное во времени и в пространстве множество элементов с известными свойствами и с упорядоченными связями между элементами и свойствами, ориентированными на выполнение главной задачи данного множества. [16]

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

Центральный прямоугольник на рис. 3.1 ( этап 4) является очень важным элементом в современных структурах баз данных. Он обозначает концептуальное представление данных в системе. Иногда его определяют как модель данных или концептуальную модель. Иногда называют схемой или концептуальной схемой. Концептуальная схема должна быть разработана таким образом, чтобы быть по возможности стабильной. [18]

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

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

Предложен новый подход для построения методов классификации функциональных семейств белков. Этот подход основан на применении концептуального представления экспертных знаний [ 9] в молекулярной биологии. Отличительной чертой этого подхода является отображение знаний в виде списков инфомации и взаимодействующих с ними программ для представления и обработки информации. [21]

В таком понимании оно является результатом объединения внешних представлений, для которых проектируется база данных. Для моделируемой предметной области существует только одно концептуальное представление данных , которое структурно не связано с сетевыми, иерархическими или реляционными моделями баз данных. [22]

Реляционная модель является моделью данных в этом смысле, и она является первой, удовлетворяющей этому определению. Структурная часть реляционной модели данных состоит из доменов, отношений неопределенного порядка ( relations of assorted degrees) ( основным средством концептуального представления которых являются таблицы), атрибутов, кортежей ( tuples), потенциальных ключей и первичных ключей. В соответствии с выбранным представлением атрибуты становятся столбцами таблиц, а кортежи — строками, но здесь, когда это касается таблиц нашей базы данных, не существует понятия того, что один столбец таблицы следует за другим или одна строка следует за другой. Другими словами, в этих таблицах порядок столбцов слева направо и порядок строк сверху вниз является произвольным и несущественным. [23]

Концептуальная схема призвана обеспечить прочную и долговременную основу проектирования БД. Такая схема должна строиться вне зависимости от конкретной СУБД, в которой она будет реализована. Двумя наиболее важными свойствами концептуального представления данных являются следующие: оно должно быть настолько простым, насколько это практически возможно, и должно иметь серьезную теоретическую основу [ 19, с. [24]

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

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

При концептуальном проектировании определяется общий вид всей системы и ее потребности в данных. Если по какой-либо причине требования изменятся, то в это время мы сможем изменить общий вид. Вдобавок к независимости от программного обеспечения, концептуальное представление позволяет нам определить все возможные источники получения данных. Хотя ГИС не должна быть движима исключительно лишь данными, ее функциональность и даже жизнеспособность могут в значительной степени определяться доступностью, ценой и качеством данных для решения поставленных задач. Это значит, что нам может потребоваться использование разнородного ПО или выдвижение предложения об изменении бюджета проекта для приобретения дополнительных данных. Возможно даже, что мы поймем, что ГИС не является практически осуществимым или жизнеспособным решением для данной организации. [27]

Иногда возникают следующие вопросы: Почему такая мо-дель называется реляционной моделью данных. Для этого есть две причины: ( Г) Когда реляционная модель данных была предложена впервые, многие людй, занимающиеся обработкой данных, считали, что отноше-шие между двумя или более объектами нужно представлять с помощью связных структур данных ( и название было1 дано так, чтобы учесть это неправильное представление); ( 2) понятие таблицы находится на более низком уровне абстракции, чем понятие отношения, так как при его использовании создается впечатление, что применим способ адресации по позиции ( в то время как это неверно для отношений / г-го порядка), и тот факт, что содержание информации в таблице не зависит от порядка строк, не является очевидным. Тем не менее, даже обладая этими несущественными недостатками, таблицы являются основным средством концептуального представления отношений , потому что слово таблица понятно всем. [28]

В своей работе о гипергеометрических функциях, связанных с торическими многообразиями [ G-K-Z 1 ], Гельфанд, Зелевинский и Капранов ввели новый комбинаторный объект, ассоциированный с конечным множеством А из п точек в R: вторичный многогранник QQ ( A), лежащий в Rn, который задается при помощи регулярных триангуляции2 множества А. Один из их основных результатов ( см. [ G-K-Z 2 ]), о котором пойдет речь в этой статье, заключается в том, что QQ ( A) является многогранником Ньютона дискриминанта, соответствующего множеству А. Кроме того, они дают явную формулу для коэффициентов при крайних мономах дискриминанта. В частности, эти коэффициенты всегда с точностью до знака являются произведениями целых чисел вида NN. Недавно Капранов, Штурмфельс и Зелевинский [ K-S-Z ] дали более концептуальное представление этих результатов в терминах торических вырождений и форм Чжоу. [29]

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

Концептуальное представление данных требования

Работа добавлена: 2016-06-22

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

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

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

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

Уровни моделей данных

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

Цель трехуровневой архитектуры заключается в отделении пользовательского представления БД от ее физического представления. Причины:

  • Каждый пользователь должен иметь возможность обращаться к одним и тем же данным, реализуя свое представление о данных, причем это изменение не должно оказывать влияния на других пользователей;
  • Внутренняя структура БД не должна зависеть от таких изменений физических аспектов хранения информации, как переключение на новое устройство хранения;
  • Пользователи не должны непосредственно иметь дело с такими подробностями физического хранения данных в базе, как индексирование и хеширование. Иначе говоря, взаимодействие пользователя с базой не должно зависеть от особенностей хранения в ней данных;
  • Администратор БД должен иметь возможность изменять структуру хранения данных в базе на свое усмотрение, не оказывая влияния на пользовательское представление;
  • Администратор БД должен иметь возможность модернизировать концептуальную структуру БД без какого-либо влияния на всех пользователей.
Читайте так же:  Для приобретения охотничьего ружья лицензия

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

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

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

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

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

  • Распределение дискового пространства для хранения данных и индексов;
  • Описание подробностей сохранения записей ( с указанием реальных размеров сохраняемых элементов данных);
  • Сведения о размещении записей;
  • Сведения о сжатии данных и выбранных методах их шифрования.

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

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

Три основные компоненты модели данных:

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

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

«+» простота организации, эффективное использование памяти ЭВМ для иерархической ПО, неплохая производительность даже на медленных ЭВМ.

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

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

В сетевой модели существует две основные структуры данных:

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

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

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

3. Реляционная – разработанная Э.Коддом в 1970г. логическая модель данных, описывающая:

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

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

Тип данных – характеристика набора данных, которая определяет: диапазон возможных значений данных из набора (домен); допустимые операции, которые можно выполнять над этими значениями; способ хранения этих значений в памяти. В современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как деньги), а также специальных «темпоральных» данных (дата, время, временной интервал).

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

Не требуется операция join. Проблема целостности и непротиворечивости данных решается только средствами СУБД (по аналогии с процедурами в клиент-серверных моделях).

«+» можно представить несколько реляционных таблиц в одной постреляционной, увеличивается наглядность и эфф-ть обработки.

«–» проблема контроля целостности и непротиворечивости данных.

5. Многомерная (OLAP. online analytical processing, аналитическая обработка в реальном времени).

Многомерное логическое представление структуры данных при их описании и в операциях над ними.

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

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

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

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

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

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

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

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

Основное отличие от иерархической модели в методах манипулирования данными:

Инкапсуляция – свойство видно только в пределах того объекта, в котором оно определено.

Наследование – свойство видимо всем потомкам объекта.

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

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

«–» неудобство обработки данных, низкая скорость выполнения запросов.

Уровни представления данных в БД

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

Это — системные программисты, разрабатывающие автоматизированную систему и БД, ответственные за все вопросы, связанные с правильным функционированием БД;

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

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

У каждого из них существует свой взгляд на данные, хранящиеся в БД, для каждого необходимы свои средства взаимодействия с БД.

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

В различных АИС, используемых на практике, реализовано различное число уровней представления данных, минимально — 2: концептуальный и внутренний. Однако, для того, чтобы удовлетворялись все требования, предъявляемые к БД, необходимо три уровня: внешний, концептуальный и внутренний.

Центральной частью БД является концептуальный уровень представления данных или концептуальная схема. Концептуальная схема (или схема БД) — это описание общей логической структуры данных.

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

Отображение А внешний — Отображение В внешний-

Отображение концептуальный — внутренний

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

Разработанная схема описывается на ЯОД (языке описания данных) той СУБД, которая будет использоваться. Описание схемы БД хранится в памяти машины наряду с самими данными и образует так называемые метаданные. В некоторых СУБД метаданные выделяются в отдельную подсистему, называемую словарем данных.

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

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

На концептуальном уровне представления данных никак не учитывается способ хранения данных в памяти ЭВМ, стратегия доступа к данным, программные средства реализации БД. Этим обеспечивается независимость концептуального уровня от уровня хранения данных.

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

С БД будут работать пользователи разных уровней.

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

Самый верхний уровень — уровень пользователя— разрабатывается для пользователей-непрограммистов. Такой пользователь (кассир в ж/д кассе, банковский служащий) может ничего не знать о базах данных и программировании. Он знает лишь определенную совокупность действий или простейших команд, которые позволяют ему выполнять свою работу, используя данные из БД. Такой пользователь имеет доступ только к подсхеме. Для него разрабатывается специальный дружественный интерфейс, обеспечивающий простое и удобное взаимодействие с системой, — интерфейс пользователянепрограммиста. Такой интерфейс часто основан на принципе «меню» с инициативой со стороны системы.

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

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

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

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

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

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

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

Лицо или группа лиц, ответственных за всю БД в целом, за систему защиты и за все уровни представления данных называется Администратором Базы Данных (АБД).

Концептуальное представление данных требования

Технологии баз данных
и знаний

Разработчик: доц. Бородина А.И.

1. Трехуровневая модель организации баз данных

1. ТРЕХУРОВНЕВАЯ МОДЕЛЬ ОРГАНИЗАЦИИ БАЗ ДАННЫХ

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

Читайте так же:  Нотариус лермонтов

Рис. 1. Трехуровневая модель организации баз данных

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

§ внешний уровень – это тот, на котором представляют данные пользователи;

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

§ на внутреннем уровне данные воспринимаются СУБД и операционной системой.

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

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

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

Концептуальный уровень – это попытка представить требования к базе со стороны организации. И этот уровень не должен содержать никаких сведений о методах хранения данных. Здесь должны быть отражены:

§ все сущности, включаемые в базу, их атрибуты и связи;

§ накладываемые на данные ограничения;

§ семантическая информация о данных;

§ информация о мерах обеспечения безопасности и поддержки целостности данных.

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

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

§ распределение дискового пространства для хранения данных и индексов;

§ описание подробностей хранения данных;

§ сведения о размещении записей;

§ сведения о сжатии данных и методах их шифрования.

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

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

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

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

1.5. Уровни представления данных

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

Рис.1.4. Уровни представления данных

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

Внутренний уровень архитектуры поддерживает представление БД в среде хранения – хранимую базу данных. На этом архитектурном уровне БД представлена в полностью “материализованном” виде, тогда как на других уровнях идёт работа на уровне отдельных экземпляров или множества экземпляров записей. Описание БД на внутреннем уровне называется внутренней схемой или схемой хранения.

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

Совокупность схем всех уровней называется схемой базы данных

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

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

2. Основные модели данных

2.1. Понятие модели данных

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

Модель данных – это комбинация трех составляющих:

1. набора типов структур данных;

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

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

2.1.1. Типы структур данных

Структуризация данных базируется на использовании концепций «агрегации» и «обобщения». Первый вариант структуризации данных был предложен Ассоциацией по языкам обработки данных (Conference on Data Systems Languages, CODASYL) (рис.2.1).

Рис.2.1. Композиция структур данных по версии CODASYL

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

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

Рис.2.2. Примеры агрегатов: а) простой и б) составной агрегат

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

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

Иногда термин «запись» заменяют термином «группа».

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

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

Рис. 2.3. Пример диаграммы Бахмана для фрагмента БД «Город»

Здесь запись типа ПОЛИКЛИНИКА является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением диспансеризация. Запись типа ОРГАНИЗАЦИЯ также является владельцем записей типа ЖИТЕЛЬ и они связаны групповым отношением работают. Записи типа РЭУ и типа ЖИТЕЛЬ являются владельцами записей типа КВАРТИРА с отношениями соответственно обслуживают и проживают. Таким образом, запись одного и того же типа может быть членом одного отношения и владельцем другого.

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

2.1.2. Операции над данными

Модель данных определяет множество действий, которые допустимо производить над некоторой реализацией БД для её перевода из одного состояния в другое. Это множество соотносят с языком манипулирования данными (Data Manipulation Language, DML).

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

По типу производимых действий различают следующие операции:

идентификация данных и нахождение их позиции в БД;

выборка (чтение) данных из БД;

включение (запись) данных в БД;

удаление данных из БД;

модификация (изменение) данных БД.

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

2.1.3. Ограничения целостности

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

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

Явные ограничения задаются в схеме базы данных с помощью средств языка описания данных (DDL, Data Definition Language). В качестве явных ограничений чаще всего выступают условия, накладываемые на значения данных. Например, заработная плата не может быть отрицательной, а дата приема сотрудника на работу обязательно будет меньше, чем дата его перевода на другую работу. За выполнением этих ограничений следит СУБД в процессе своего функционирования.

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

В настоящее время разработано много различных моделей данных. Основные – это сетевая, иерархическая и реляционная модели.