Студопедия Главная Случайная страница Обратная связь

Разделы: Автомобили Астрономия Биология География Дом и сад Другие языки Другое Информатика История Культура Литература Логика Математика Медицина Металлургия Механика Образование Охрана труда Педагогика Политика Право Психология Религия Риторика Социология Спорт Строительство Технология Туризм Физика Философия Финансы Химия Черчение Экология Экономика Электроника

ПОНЯТИЕ ПРЕДМЕТНОЙ ОБЛАСТИ




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

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

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

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

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

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

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

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

1)Целостность базы данных – требование полноты и непротиворечивости данных;

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

3)Быстрый поиск и получение информации по запросам пользователей;

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

5)Уменьшение излишней избыточности данных;

6)Защита данных от несанкционированного доступа, искажения и уничтожения.

Целостность базы данных(database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.

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

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

19. Модель данных. Классификация моделей. Иерархическая, сетевая, реляционная модели.

В классической теории баз данных, МОДЕЛЬ ДАННЫХ есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта:

1) аспект структуры: методы описания типов и логических структур данных в базе данных;

2) аспект манипуляции: методы манипулирования данными;

3) аспект целостности: методы описания и поддержки целостности базы данных.

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

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

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

КЛАССИФИКАЦИЯ МОДЕЛЕЙ ДАННЫХ:

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

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

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

20. Элементы реляционного отношения (кортеж, атрибут, домен). Логические связи между отношениями. Первичный ключ.

Отношение — фундаментальное понятие реляционной модели данных. По этой причине модель и называется реляционной (от лат. relatio — отношение, связь).

Реляционные отношения соответствуют наборам сущностей, а кортежи – сущностям. Столбцы в таблице, представляющей реляционное отношение, называют атрибутами.

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

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

Именованное множество пар "имя атрибута – имя домена" называется схемой отношения. Мощность этого множества - называют степенью или "арностью" отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

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

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

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

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

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

Целью разработки любой БД является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты: реляционная модель данных – удобный способ представления данных предметной области и язык SQL – универсальный способ манипулирования такими данными.

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

1. Сама предметная область

2. Модель предметной области

3. Логическая модель данных

4. Физическая модель данных

5. Собственно база данных и приложения

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

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

Логическая модель данных. На следующем, более низком уровне находится логическая модель данных предметной области. Логическая модель описывает понятия предметной области, их взаимосвязь, а также ограничения на данные, налагаемые предметной областью. Примеры понятий: "сотрудник", "отдел", "проект", "зарплата". Примеры взаимосвязей между понятиями: "сотрудник числится ровно в одном отделе", "сотрудник может выполнять несколько проектов", "над одним проектом может работать несколько сотрудников". Примеры ограничений: "возраст сотрудника не менее 16 и не более 60 лет".

Логическая модель данных является начальным прототипом будущей БД. Логическая модель строится в терминах информационных единиц, но без привязки к конкретной СУБД. Более того, логическая модель данных необязательно должна быть выражена средствами именно реляционной модели данных. Основным средством разработки логической модели данных в настоящий момент являются различные варианты ER-диаграмм (Entity-Relationship). Одну и ту же ER-модель можно преобразовать как в реляционную модель данных, так и в модель данных для иерархических и сетевых СУБД, или в постреляционную модель данных. Однако, т.к. мы рассматриваем именно реляционные СУБД, то можно считать, что логическая модель данных для нас формулируется в терминах реляционной модели данных.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

 

 

22. Информационно-логическая модель БД. Связи между таблицами. Ключевые и индексные поля. Отношения “один-к-одному”, “один-ко-многим”, “многие-ко-многим”.

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

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

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

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

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

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

При этом как ключ, так и индекс задаются самим пользователем.

Важным свойством модели «сущность-связь» является то, что она может быть представлена в виде графической схемы. В табл. 2 приведен список обозначений нотаций Чена-Мартина для построения ER-диаграммы.

Таблица 2 ‑ Условные обозначения нотации Чена-Мартина

Обозначение Значение
Независимая сущность
Зависимая сущность
Атрибут сущности
Ключевой атрибут
Связь между сущностями

 

На схеме атрибуты с сущностями и сущности со связями соединяются прямыми линиями.

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

Существует три вида связей между сущностями.

Связь "один ко многим" – наиболее распространенный вид связи. При такой связи каждому экземпляру сущности А может соответствовать множество экземпляров сущности Б, однако каждому экземпляру сущности Б может соответствовать только один экземпляр сущности А. Например, между сущностями "Издатели" и "Книги" устанавливается связь "один ко многим": каждый из издателей может опубликовать множество книг, однако каждая книга публикуется лишь одним издателем.

Важной характеристикой связи является класс принадлежности входящих в нее сущностей или кардинальность связи. Так как каждый автор обязательно должен иметь книгу, то каждой сущности «Автор» непременно должна соответствовать сущность «Книга». Однако не каждая книга должна иметь конкретного автора (например, энциклопедии и сборники), следовательно, в данной связи не каждая сущность «Автор» имеет ассоциированную с ней сущность «Книга» (рис. 2).

Рис. 2. Пример связи «один ко многим»

Таким образом, говорят, что сущность «Книга» имеет обязательный класс принадлежности – , а сущность «Автор» имеет необязательный класс принадлежности – .

Связь "многие ко многим". При установлении связи "многие ко многим" каждому экземпляру сущности А может соответствовать множество экземпляров сущности Б и наоборот. Например, между сущностями "Читатель" и "Книга" должна устанавливаться связь вида "многие ко многим" (рис.3), так как многие читатели заказывают многие книги и, наоборот. На практике такие связи создаются с помощью двух связей вида "один ко многим", которые устанавливаются между каждой из первоначальных сущностей и новой сущностью, например "Корзина". Ключевым атрибутом сущности "Корзина", как правило, выбирают сочетание ключевых атрибутов двух первоначальных сущностей (рис. 4).

Рис. 3. Пример связи «многие ко многим»

Рис. 4. Пример практической реализации связи «многие ко многим»

 

Связи "один к одному". При установлении связи "один к одному" каждому экземпляру сущности А может соответствовать только один экземпляр сущности Б и наоборот. Этот вид связи используется редко, поскольку в такой ситуации связываемые данные обычно можно хранить в одной сущности. Использовать связь вида "один к одному" можно в указанных ниже случаях:

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

чтобы изолировать часть атрибутов сущности по соображениям безопасности;

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

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

Рис. 5. Пример связи «один к одному

 

23. Типы данных в базах данных.

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

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

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

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

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

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

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

1. ВСТРОЕННЫЕ ТИПЫ ДАННЫХ, т.е. типы, предопределенные в языке программирования или языке баз данных. Обычно в состав встроенных типов данных включаются такие типы, операции над значениями которых поддерживаются командами компьютеров. В традиционный набор встроенных типов обычно входят следующие:

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

логический тип BOOLEAN содержит два значения - TRUE (истина) и FALSE (ложь). Несмотря на то, что для хранения значений этого типа теоретически достаточно одного бита, обычно в реализациях переменные этого типа занимают один байт памяти. Над булевскими значениями возможны операции конъюнкции (& или AND), дизъюнкции (| или OR) и отрицания (~ или NOT).

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

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

2. УТОЧНЯЕМЫЕ ТИПЫ ДАННЫХ – это типы, которые определены на основе встроенного типа данных, значения которого упорядочены.

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

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

3. ПЕРЕЧИСЛЯЕМЫЕ ТИПЫ ДАННЫХ составляют явно определяемые целые типы с конечным числом именованных значений. Это очень простой и легко реализуемый механизм, часто являющийся очень полезным.

Обычно для любого перечисляемого типа предопределяются операции получения значения по его номеру и получения номера по значению. Кроме того, для перечисляемого типа предопределяются операции сравнения и получения следующего и предыдущего значения.

4. КОНСТРУИРУЕМЫЕ ТИПЫ(составные) обладают той особенностью, что в языке предопределены средства спецификации таких типов и некоторый набор операций, дающих возможность доступа к компонентам составных значений. Любое значение конструируемого типа состоит из значений одного или нескольких других типов.

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

5. УКАЗАТЕЛЬНЫЕ ТИПЫ дают возможность работы с типизированными множествами абстрактных адресов переменных, содержащих значения некоторого типа.

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

6. АБСТРАКТНЫЕ (определяемые пользователями) типы данных

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

24. Общие требования, предъявляемые к системам управления базами данных (СУБД).

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

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

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

- согласованность – обеспечение блокировки доступа к информации в момент ее корректировки в целях невозможности получения частично измененной информации;

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

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

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

- совместимость – обеспечение возможности информационного взаимодействия с другими системами, а также автоматизированного ввода информации внемашинной базы данных;

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

25. Пользователи БД. Администрирование баз данных.

 

ПОЛЬЗОВАТЕЛИ БАЗЫ ДАННЫХ
Каждая база данных включает список имен пользователей. Чтобы получить доступ к базе данных, пользователь должен соединиться с базой данных, предоставив своё имя, которое включает собственно имя (логин) и пароль. Такая структура предназначена для предотвращения несанкционированного доступа к БД.

При первоначальном создании (включении) пользователя в БД ему можно определить некоторое табличное пространство (например, заданное по умолчанию), в котором будут создаваться объекты пользователя. Пользователю может быть определён объём памяти, который он может использовать в табличном пространстве. Другой способ создания пользователя БД подразумевает предоставление пользователю определённой роли.

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

АДМИНИСТРИРОВАНИЕ БД заключается в предоставлении пользователям соответствующих прав использования возможностей работы с базой данных; обеспечении целостности данных, а также создании многопользовательских приложений. Администратор базы данных может использовать табличные пространства для:

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

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

 

26. Структурированный язык запросов SQL.

SQL (Structured Query Language - язык структурированных запросов) является языком четвертого уровня, предназначенным для работы с реляционными базами данных.

Первый официальный стандарт языка SQL был принят ANSI в 1986 году и ISO в 1987 году (так называемый SQL-86) и несколько уточнён в 1989 году. Дальнейшее развитие языка поставщиками СУБД потребовало принятия в 1992 году нового расширенного стандарта (ANSI SQL-92 или просто SQL2). Следующим стандартом стал SQL:1999 (SQL3). В настоящее время действует стандарт, принятый в 2003 году (SQL:2003) с небольшими модификациями, внесёнными позже.

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

· создание в базе данных новой таблицы;

· добавление в таблицу новых записей;

· изменение записей;

· удаление записей;

· выборка записей из одной или нескольких;

· изменение структур таблиц.

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

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

Каждое предложение SQL — это либо запрос данных из базы, либо обращение к базе данных, которое приводит к изменению данных в базе. В соответствии с тем, какие изменения происходят в базе данных, различают следующие ТИПЫ ЗАПРОСОВ:

· запросы на создание или изменение в базе данных новых или существующих объектов (при этом в запросе описывается тип и структура создаваемого или изменяемого объекта);

· запросы на получение данных;

· запросы на добавление новых данных (записей)

· запросы на удаление данных;

· обращения к СУБД.

Основным объектом хранения реляционной базы данных является таблица, поэтому все SQL-запросы — это операции над таблицами. В соответствии с этим, ЗАПРОСЫ ДЕЛЯТСЯ НА:

· запросы, оперирующие самими таблицами (создание и изменение таблиц), в свою очередь, делятся на:

· для создания в базе данных новых таблиц;

· для изменения уже существующих таблиц.

· запросы, оперирующие с отдельными записями (или строками таблиц) или наборами записей. Можно разделить на:

· изменение значений полей строки или набора строк;

· удаление строки или набора строк.

Самый главный вид запроса — это запрос, возвращающий (пользователю) некоторый набор строк, с которым можно осуществить одну из трёх операций:

· просмотреть полученный набор;

· изменить все записи набора;

· удалить все записи набора.

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

Основные преимущества использования SQL:

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

2. Наличие стандартов. Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту способствует «стабилизации» языка. Однако стандарт местами чересчур формализован и раздут в размерах, например, Core-часть стандарта SQL:2003 представляет собой более 1300 страниц текста.

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

Кроме этого, можно отметить и ряд недостатков:

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

- повторяющиеся строки;

- неопределённые значения (NULL);

- явное указание порядка колонок слева направо;

- колонки без имени и дублирующиеся имена колонок;

- использование указателей и т.д.

2. Сложность. Хотя SQL и задумывался, как средство работы конечного пользователя, в конце концов, он стал настолько сложным, что превратился в инструмент программиста.

3. Отступления от стандартов. Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД (например, Oracle, Sybase, Microsoft, MySQL), вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом, появляются специфичные для каждой конкретной СУБД диалекты языка SQL. Существует четыре уровня соответствия реализации SQL стандарту:

- entry (базовый);

- transitional (переходный);

- intermediate (промежуточный);

- full (полный).

4. Сложность работы с иерархическими структурами. Ранее SQL не предлагал стандартного способа манипуляции древовидными структурами. Некоторые поставщики СУБД предлагали свои решения. Например, Oracle использует выражение CONNECT BY. В настоящее время в качестве стандарта принята рекурсивная конструкция WITH.

 

27. Организация SQL-запросов в СУБД MS Access.

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

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

SQL — это язык программирования, предназначенный для работы с наборами фактов и отношениями между ними. В программах управления реляционными базами данных, таких как Microsoft Office Access, язык SQL используется для работы с данными.

Основные предложения SQL: SELECT, FROM и WHERE

Общий формат инструкции SQL:

 

SELECT поле_1

FROM таблица_1

WHERE условие_1

;

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

Каждая инструкция SELECT заканчивается точкой с запятой (;). Точка с запятой может стоять как в конце последнего предложения, так и на отдельной строке в конце инструкции SQL.

Сортировка результатов: предложение ORDER BY

Как и в Microsoft Office Excel, в Access можно сортировать результаты запроса в таблице. Используя предложение ORDER BY, в запросе также можно указать способ сортировки результатов при выполнении запроса. Если используется предложение ORDER BY, оно должно находиться в конце инструкции SQL.

Предложение ORDER BY содержит список полей, для которых нужно выполнить сортировку, в том же порядке, в котором будут применена сортировка.

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

ORDER BY Организация DESC, [Адрес электронной почты]

По умолчанию в Access выполняется сортировка по возрастанию (A-Z, А-Я, от наименьшего к наибольшему). Чтобы вместо нее выполнить сортировку значений по убыванию, необходимо указать ключевое слово DESC.

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

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

 

Кроме того функциям СУБД относятся:

-Ведение системного каталога, доступного конечным пользователям

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

· имена, типы и размеры элементов данных;

· имена связей;

· накладываемые на дынные ограничения поддержки целостности;

· имена санкционированных пользователей, которым предоставлено право доступа к данным;

· внешняя, концептуальная и внутренняя схемы и отображения между ними;

· статистические данные, например частота транзакций и счетчики обращений к объектам базы данных.

· Наличие системного каталога позволяет:

· централизованно хранить информацию о данных, что обеспечивает контроль доступа к этим данным и любому другому ресурсу;

· легко обнаружить избыточность и противоречивость описания отдельных элементов данных;

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

· усилить меры обеспечения безопасности.

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

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

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

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

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

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

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

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

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

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

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

Приложения выполняют пять основных функций:

1. Создание, чтение, обновление и удаление представлений.

2. Форматирование представлений.

3. Реализация ограничений.

4. Обеспечение механизмов безопасности и контроля.

5. Реализация логики обработки информации.

 

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

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

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

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

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

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

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







Дата добавления: 2015-04-19; просмотров: 8204. Нарушение авторских прав


Рекомендуемые страницы:


Studopedia.info - Студопедия - 2014-2019 год . (0.049 сек.) русская версия | украинская версия