ПОНЯТИЕ ПРЕДМЕТНОЙ ОБЛАСТИПредметная область – часть реальной среды, которая описывается и отражается в базе данных (фирма, предприятие, институт и т.д.) Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных для ИС данных, связей между ними и операций над ними образует информационную и функциональную модели предметной области, описывающие ее состояние с определенной точностью. Важно понимать, что информационная и функциональная модели предметной области создаются на этапе анализа требований к базе данных и не содержат предположений о технологии реализации базы данных. Они строятся независимо от выбираемой модели данных (сетевой, иерархической, реляционной, объектно-ориентированной, многомерной и т.д.), поддерживаемой СУБД, модели вычислений, программно-аппаратной платформы для базы данных. Информационная и функциональная модели предметной области являются входными данными для процесса проектирования базы данных. Поэтому проектировщик должен уметь правильно интерпретировать их в ходе решения своих проектных задач. Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение в рассмотрение понятия предметной области базы данных ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет выполнять запросы за конечное время. Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области, которое имеет онтологический статус. 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. Пользователи БД. Администрирование баз данных.
ПОЛЬЗОВАТЕЛИ БАЗЫ ДАННЫХ При первоначальном создании (включении) пользователя в БД ему можно определить некоторое табличное пространство (например, заданное по умолчанию), в котором будут создаваться объекты пользователя. Пользователю может быть определён объём памяти, который он может использовать в табличном пространстве. Другой способ создания пользователя БД подразумевает предоставление пользователю определённой роли. Для удаления (исключения) пользователя из базы данных удаляют его учётную запись из словаря базы данных. Если пользователь владел некоторыми объектами базы данных, то их можно последовательно удалить, или автоматически уничтожить все объекты, связанные с учётной записью пользователя. АДМИНИСТРИРОВАНИЕ БД заключается в предоставлении пользователям соответствующих прав использования возможностей работы с базой данных; обеспечении целостности данных, а также создании м
|
Иерархическая модель БД состоит из объектов с указателями от родительских объектов к потомкам, соединяя вместе связанную информацию. Иерархические базы данных могут быть представлены как дерево, состоящее из объектов различных уровней. Верхний уровень занимает один объект, второй — объекты второго уровня и т. д. Между объектами существуют связи, каждый объект может включать в себя несколько объектов более низкого уровня. Такие объекты находятся в отношении предка (объект более близкий к корню) к потомку (объект более низкого уровня), при этом возможно, когда объект-предок не имеет потомков или имеет их несколько, тогда как у объекта-потомка обязательно только один предок. Объекты, имеющие общего предка, называются близнецами.
К основным понятиям сетевой модели БД относятся: уровень, элемент (узел), связь. Узел — это совокупность атрибутов данных, описывающих некоторый объект. На схеме иерархического дерева узлы представляются вершинами графа.В сетевой структуре каждый элемент может быть связан с любым другим элементом. Сетевые базы данных подобны иерархическим, за исключением того, что в них имеются указатели в обоих направлениях, которые соединяют родственную информацию. Несмотря на то, что эта модель решает некоторые проблемы, связанные с иерархической моделью, выполнение простых запросов остается достаточно сложным процессом. Также, поскольку логика процедуры выборки данных зависит от физической организации этих данных, то эта модель не является полностью независимой от приложения. Другими словами, если необходимо изменить структуру данных, то нужно изменить и приложение.
, а сущность «Автор» имеет необязательный класс принадлежности – 
.
