Работа с базами данных
Характеристика реляционной, иерархической и сетевой моделей баз данных. Анализ методов проектирования (декомпозиция, синтез, объектная связь), организации, обновления, восстановления, ограничений, поддержания целостности данных на примере СУБД Ms Access.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | дипломная работа |
| Язык | русский |
| Дата добавления | 13.02.2010 |
| Размер файла | 347,4 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
Содержание
- Введение. Понятие информации и информационной системы. Требования к организации данных
- Глава 1. Базы данных
- 1.1 Модели баз данных
- 1.1.1 Реляционная модель
- 1.1.2 Иерархическая модель
- 1.1.3 Сетевая модель
- 1.1.4 Объектно-ориентированная модель данных
- 1.2 Теория нормальных форм
- 1.3 Достоверность и безопасность информации
- Глава 2. Основы разработки базы данных
- 2.1 Методы проектирования БД
- 2.1.1 Метод декомпозиции
- 2.1.2 Метод синтеза
- 2.1.3 Метод объектной связи
- 2.2 Организация СУБД
- 2.2.1 Требования к современной СУБД
- 2.2.2 Архитектура СУБД
- 2.2.3 Работа СУБД
- 2.3 Организация данных
- 2.3.1 Физическая организация данных
- 2.3.2 Организация индексных таблиц
- 2.4 Обновление и восстановление данных
- 2.4.1 Типы ключевых полей
- 2.4.2 Создание и изменение ключевых полей
- 2.5 БД в сетях
- 2.6 Доступ к данным в Windows
- Глава 3. Работа с таблицами базы данных на примере СУБД Microsoft Access
- 3.1 Структура таблицы, ее создание
- 3.1.1 Создание новой пустой таблицы
- 3.1.2 Создание таблицы в режиме конструктора
- 3.2 Ключи и индексы
- 3.2.1 Типы ключевых полей
- 3.2.2 Индексы
- 3.2.3 Создание и изменение ключевых полей
- 3.3 Общая картина ограничений и поддержания целостности данных
- 3.3.1 Ограничения в базе данных
- 3.3.2 Типы ограничений в базе данных
- 3.3.3 Поддержание целостности данных
- Заключение
Введение. Понятие информации и информационной системы. Требования к организации данных
Веками человечество накапливало знания, навыки работы, сведения об окружающем мире, другими словами - собирало информацию. Вначале информация передавалась из поколения в поколение в виде преданий и устных рассказов. Возникновение и развитие книжного дела позволило передавать и хранить информацию в более надежном письменном виде. Открытия в области электричества привели к появлению телеграфа, телефона, радио, телевидения - средств, позволяющих оперативно передавать и накапливать информацию. Развитие прогресса обусловило резкий рост информации, в связи, с чем вопрос о ее сохранении и переработке становился год от года острее. С появлением вычислительной техники значительно упростились способы хранения, а главное, обработки информации. Развитие вычислительной техники на базе микропроцессоров приводит к совершенствованию компьютеров и программного обеспечения. Появляются программы, способные обработать большие потоки информации. С помощью таких программ создаются информационные системы. Целью любой информационной системы является обработка данных об объектах и явлениях реального мира и предоставление человеку нужной информации о них. Если мы рассмотрим совокупность некоторых объектов, то сможем выделить объекты, обладающие одинаковыми свойствами. Такие объекты выделяют в отдельные классы. Внутри выделенного класса объекты можно упорядочивать как по общим правилам классифицирования, например по алфавиту, так и по некоторым конкретным общим признакам, например по цвету или материалу. Группировка объектов по определенным признакам значительно облегчает поиск и отбор информации.
Информационные системы (ИС) можно условно разделить на фактографические и документальные.
В фактографических ИС регистрируются факты - конкретные значения данных (атрибутов) об объектах реального мира. Основная идея таких систем заключается в том, что все сведения об объектах (фамилии людей и названия предметов, числа, даты) сообщаются компьютеру в каком-то заранее обусловленном формате (например дата - в виде комбинации ДД.ММ.ГГГГ). Информация, с которой работает фактографическая ИС, имеет четкую структуру, позволяющую машине отличать одно данное от другого, например фамилию от должности человека, дату рождения от роста и т.п. Поэтому фактографическая система способна давать однозначные ответы на поставленные вопросы.
Документальные ИС обслуживают принципиально иной класс задач, которые не предполагают однозначного ответа на поставленный вопрос. Базу данных таких систем образует совокупность неструктурированных текстовых документов (статьи, книги, рефераты и т.д.) и графических объектов, снабженная тем или иным формализованным аппаратом поиска. Цель системы, как правило, - выдать в ответ на запрос пользователя список документов или объектов, в какой-то мере удовлетворяющих сформулированным в запросе условиям.
Указанная классификация ИС в известной мере устарела, так как современные фактографические системы часто работают с неструктурированными блоками информации (текстами, графикой, звуком, видео), снабженными структурированными описателями. Чтобы пояснить, как фактографическая система может превратиться в документальную (и наоборот), рассмотрим условный пример.
Пусть объектом обработки фактографической ИС является некий список ученых-экономистов, причем для каждого ученого имеются следующие данные:
Имя;
Дата рождения в формате ДД.ММ.ГГГГ;
Национальность (русский или иностранец);
Биография (произвольный текст);
Названия трудов ученого.
Требования к организации данных информационных систем:
Интеграция данных -- когда все данные хранятся централизованно, создавая динамически обновляемую модель.
Максимальная независимость прикладных программ от данных или обеспечение физической и логической независимости данных.
Выполнение этих требований привело к созданию единого для всех задач блока данных -- базы данных и разработки одной управляющей программы для манипулирования данными на физическом уровне -- СУБД.\
Именно СУБД обеспечивает независимость данных, изменение физической организации воспринимается СУБД и не влияет на прикладную программу. С другой стороны, изменение логики программы не требует реорганизации и изменения механизма доступа к физическим данным. Введение СУБД разделяет логическую структуру данных от физической структуры данных. Отличительной чертой современных БД следует считать совместное хранение данных с их описанием. Современный подход требует, чтобы в программе были заданы лишь имена и форматы обрабатываемых данных. Поставляя данные в программу, СУБД их предварительно обрабатывает, в связи с чем изменение организации данных не отражается на прикладных программах, в этом случае меняются только процедуры СУБД. Описание БД называют метаданными.
Располагая структурированными описателями (имя, дата, пол), система может выдать строгие ответы на вопросы: а) о любом ученом персонально; б) о распределении ученых по дате рождения и полу (в любых сочетаниях). Заметим, что те же данные в той или иной форме дублируются в биографии, например: "Уильям Стаффорд родился в 1554 году в семье…", "Иван Тихонович Посошков жил с 1652 по 1726 год…" и т.д. Однако, если удалить из списка структурированные описатели, система превратится в документальную и, если не принять мер, утратит способность находить и классифицировать ученых. В отличие от нас, компьютер не знает, что Стаффорд - иностранец, а Посошков - русский, что "родиться" и "жить с… по…" - синонимы и т.д.
В данной работе рассматриваются фактографические ИС, которые используются буквально во всех сферах человеческой деятельности, а практика работы с ними будет рассмотрена на примере современной системы управления базами данных (СУБД) Microsoft Access.
Глава 1. Базы данных
Что такое база данных (БД)? В широком смысле слова можно сказать, что БД - это совокупность сведений о конкретных объектах реального мира в какой-либо предметной области. Синоним термина "база данных" - "банк данных".
Чтобы обеспечить быстроту и качество поиска данных в базе, этот процесс должен быть автоматизирован. Компьютерную базу данных можно создать несколькими способами:
С помощью алгоритмических языков программирования, таких как Basic, Pascal, C++ и т.д. Данный способ применяется для создания уникальных баз данных.
С помощью прикладной среды, например Visual Basic. С его помощью можно создавать базы данных, требующие каких-то индивидуальных особенностей построения.
С помощью специальных программных сред, которые называются системами управления базами данных.
В настоящее время существует несколько видов СУБД. Наиболее известными и популярными СУБД являются Access, FoxPro и Paradox.
Каждый объект, сущность обладает набором свойств или атрибутов. Мыслить в терминах конкретных объектов трудно, поэтому прибегают к разбиению всего множества объектов на группы объектов однородных по структуре и поведению, и называемых типами объектов, типами записей (в ООП -- класс, объект). При этом предполагается, что все экземпляры объектов одного типа обладают одинаковым наборам атрибутов. Свойства по своей структуре могут быть любой степени сложности. Большинство современных СУБД плохо развито с точки зрения описания сложных свойств: графика, текст.
Свойства могут быть:
во времени:
статические;
динамические;
по структуре:
1) неделимые (атомарные);
2) составные.
Байт -- наименьшая единица адресуемых битов.
Элемент данных -- наименьшая единица поименованных данных, называют полем.
Агрегат данных -- поименованная совокупность данных внутри записи, рассматриваемая как единое целое. Позволяет в приложениях за одно обращение получить некоторую логически связанную совокупность данных. Может содержать в себе и другие агрегаты данных. Если агрегат состоит из одномерной упорядоченной совокупности элементов данных одного типа, то говорят, что в этом типе записи определен вектор. Вектор может быть фиксированной и переменной длины. Если агрегат встречается несколько раз в экземпляре записи, то агрегат называется повторяющейся группой. В повторяющуюся группу могут входить отдельные элементы данных, вектор, другие агрегаты или повторяющиеся группы. Повторяющиеся группы могут быть фиксированной и переменной длины.
Пример:
Тип объекта (записи) "СОТРУДНИК".
|
ФИО |
АДРЕС (ул., дом, кв.) |
ТЕЛЕФОН |
ЗАРПЛАТА (за 3 месяца) |
ДИПЛОМ |
ДЕТИ (имя, возраст) |
|
|
Жуков И.П. |
Победы, 5, 36 |
42-37-05 |
10 540,66 |
АО-3628 |
Иван, 10 |
|
|
Семенов А.В. |
Водная, 15, 105 |
29-45-99 |
15 530,07 |
ВН-5491, КР-1367 |
Мария, 5 Алексей, 8 |
|
|
Элемент |
Агрегат |
Элемент |
Вектор, фиксированный |
Вектор, переменный |
Повторяющаяся группа, переменной длины |
Запись -- агрегат, который не входит в состав никакого другого агрегата. Основная единица обработки данных.
Каждый экземпляр типа записи должен быть отличимым от других объектов данного типа. С этой целью каждому объекту данного типа назначается идентификатор, позволяющий на них однозначно ссылаться, он уникален. Он называется первичным ключом. В качестве первичного ключа может использоваться атрибут, комбинация атрибутов и даже части атрибутов. На практике используют не уникальные идентификаторы называемые вторичным ключом. К каждому такому множеству относятся объекты, которым соответствует одинаковое значение вторичного ключа.
1.1 Модели баз данных
БД может быть основана на одной модели или на совокупности нескольких моделей. Любую модель данных можно рассматривать как объект, который характеризуется своими свойствами (параметрами), и над ней, как над объектом, можно производить какие-либо действия.
Так как пользователя БД не интересует подробности физического хранения данных, в представлении данных можно выделить два уровня абстракции: логическая и физическая. На логическом уровне описываются данные информационной моделью, выделяют внешнюю и внутреннюю информационные модели, а на физическом - физической моделью. Информационная модель должна отражать предметную область в терминах понятных и привычных пользователю. Обычная информационная модель описывает объекты любой природы в терминах: сущность, атрибуты и связи. Абстрактная модель должна быть описана для представления в ЭВМ. Это описание делается средствами модели данных, которую поддерживает СУБД и называется внутренней или концептуальной информационной схемой. Итак, СУБД поддерживает некоторую модель данных и отображает её в соответствующие структуры физической БД.
Модель Данных (МД) -- средство логического представления физических данных. Формализованное описание данных, отражающее их состав, типы данных, а также взаимосвязь между ними.
МД, которую поддерживает СУБД на логическом уровне определяется:
допустимой структурой данных, разнообразием и количеством типов данных, которые можно описать с помощью МД;
множеством допустимых операций над данными;
ограничениями контроля целостности.
В зависимости от поддерживаемой структуры данных, МД подразделяются на:
сетевые;
иерархические;
реляционные.
Большинство БД реляционные.
1.1.1 Реляционная модель
Термин "реляционный" (от латинского relation - отношение) указывает, прежде всего, на то, что такая модель хранения данных построена на взаимоотношении составляющих ее частей. В простейшем случае она представляет собой двухмерный массив или двухмерную таблицу, а при создании сложных информационных моделей составит совокупность взаимосвязанных таблиц. Каждая строка такой таблицы называется записью, а столбец - полем.
Реляционная модель данных имеет следующие свойства:
Каждый элемент таблицы - один элемент данных.
Все поля в таблице являются однородными, т.е. имеют один тип.
Каждое поле имеет уникальное имя.
Одинаковые записи в таблице отсутствуют.
Порядок записей в таблице может быть произвольным и может характеризоваться количеством полей, типом данных.
Реляционная таблица -- множество отношений содержащих всю необходимую информацию о предметной области.
|
Неспециалист |
Математик |
Программист ОД |
Проектировщик БД |
|
|
Таблица Строка Столбец |
Отношение Кортеж Атрибут |
Файл данных Запись Поле |
Объект Экземпляр данных Атрибут |
Отношение реляционной БД в зависимости от содержания подразделяется на два класса:
объектные;
связанные.
Таблица объектов хранит данные об экземплярах объекта, каждая строка содержит ключ и признаки объекта, которые функционально зависят от этого ключа.
Таблица связи хранит ключи двух или более таблиц объектов и таким образом устанавливаются связи между таблицами объектов, каждая строка связи содержит внешние ключи и характеристики связей.
Связь между объектами обычно выражается глаголами: "Служащие работают в отделах". Поэтому название таблице связей часто дают по имени связи или в названии указывают имена объектов участвующих в связи.
Отличительный признак объекта:
--объект может существовать сам по себе, ни с кем не связываясь, связь автономно существовать не может, требуя наличия хотя бы двух объектов.
Пример:
СТУДЕНТ (СТ#, ФИО, Группа, Адрес);
ПРЕДМЕТ (П#, Название, Вид контроля);
ИЗУЧАЕТ (СТ#, П#, Оценка).
Допустимые и недопустимые связи.
Пример:
Институт делится на подразделения, которые могут работать над несколькими проектами, над каждым проектом могут работать сотрудники из нескольких отделов.
Три таблицы:
|
Сотрудники |
Отделы |
Проекты |
||||||
|
С# |
ФИО |
О# |
Название |
П# |
Название |
|||
Связи:
Сотрудники - Проекты. Сотрудники - Отдел.
|
Сотрудник |
Проект |
Сотрудник |
Отдел |
Должность |
||
Для логической завершенности не хватает третьей связи "отдел - проекты", которая отражает какое подразделение над чем работает. Связь содержится в таблице, но косвенно через сотрудников, выделим её явно. С появлением 6-ой таблицы появляется противоречие. Причиной служит то, что один и тот же факт хранится в двух разных местах, косвенно -- через исполнителя и явно (С - П) и явно в дополнительной шестой таблице. Вывод: связи между объектами не могут замыкаться. Недоразумение в этом примере вызвано нечеткой формулировкой задачи: отделы как таковые не работают над проектом, они работают над проектом тогда и только тогда, когда над проектом работает хотя бы один сотрудник. Две связи допустимы, а третья запрещена.
Если убрать связь СОТРУДНИКИ - Проекты, то изменится постановка задачи, тогда проекты
закрепляются за отделами, и все сотрудники должны будут работать над проектом.
Сотрудники не закреплены за отделами и свободно переходят в отдел занятый их проектом.
Реляционные модели связей не могут замыкаться, какие связи запрещены, а какие разрешены, зависит от постановки задачи. Для двух объектов возможна одна связь, для трех - две, а для n - (n-1). Для модели из n объектов необходимо (2n-1) объектов.
Работа с БД подразумевает задание и выполнение запросов.
Пример:
Найти всех студентов сдавших на отлично сессию. При этом используются специальные языковые средства, основанные на:
реляционной алгебре;
реляционном исчислении.
Алгебраический подход требует наличия операндов и совокупности операций над ними. В реляционной алгебре используются в качестве операндов -- отношения (таблица).
Операции РА были предложены Коддом. Язык РА -- аппликативный язык. Кодд доказал, что запросы сформированные с помощью реляционного исчисления могут сформировать язык РА и наоборот. Результатом любой реляционной операции является некоторое отношение.
Реляционная модель кроме РА может также включать операции реляционного присваивания Target := Source, где левые и правые части -- реляционные выражения, представляющие совместимые по типу отношения. Target -- базовое отношение.
Операция присваивания дает возможность запоминать значения некоторых алгебраических выражений в БД и изменять состояние БД.
Замечание: язык РА не применяется. Используется язык реляционного исчисления.
Исчисление -- это знаковая система, в которой имеется некоторое количество исходных объектов и некоторое количество правил построения объектов из исходных и уже построенных. Дедуктивная система.
Были созданы различные разновидности языков исчисления предикатов, оно называлось реляционным исчислением.
Рассмотрим два языка, широко используемых в СУБД: SQL и QBE.
Язык Структурных Запросов (SQL)
SQL разработан фирмой IBM. Одобрен в качестве стандарта для больших и малых ЭВМ. Если D-Base ориентирована на операции с данными в виде записи, то SQL - на операции с данными, в виде таблиц. Кроме обычных таблиц SQL позволяет создавать особый тип таблиц - выборку (подмножество строк и столбцов из одной или нескольких таблиц). Часто выборку называют виртуальной таблицей.
Язык SQL оперирует понятием БД, которая содержит всю информацию, необходимую для обработки данных: таблицы, выборки, синонимы (альтернативные имена таблицы) и индексы (файлы для быстрого поиска данных, присоединяемые к таблице). В SQL можно выделить следующие средства:
средства запросов;
средства манипулирования данными;
средства определения данных;
средства контроля данных;
средства встраивания в основной язык.
Средства запросов
Большинство запросов на извлечение данных из БД строится на основе команды SELECT.
SELECT <список атрибутов и/или функций от атрибутов>
FROM <список отношений>
WHERE <условие>
GROUP BY <список колонок>
HAVING <условие>
ORDER BY <список сортировки>
TO FILE | TO PRINTER | TO SCREEN | INTO
Принципиальная схема выполнения запроса:
образуется декартово произведение таблиц, перечисленных в FROM;
для каждой строки декартового произведения вычисляется значение логического выражения, заданного в WHERE, строки с ложным значением - удаляются;
если заданно GROUP BY, то оставшиеся строки делятся на группы соответственно значениям указанных в ней колонок;
для каждой группы или строки вычисляется выражение, заданное во фразе SELECT;
для каждой группы производится проверка условий заданного фразой HAVING, варианты с false удаляются;
результат сортируется по колонкам из ORDER BY, в соответствии с заданным порядком сортировки.
В строке SELECT указываются через запятую имена столбцов в выходной таблице. Символ "*" означает, что выбираются все столбцы, указанные в предложении FROM. Если в нескольких таблицах имеются колонки с одинаковым именем, то перед этими именами указываются имена таблицы, разделённые ".". Чтобы вывести все столбцы таблицы, можно указать <имя таблицы>.*. Для того, чтобы вывести только уникальные столбцы таблицы, используют слово DISTINCT <столбцы>. Предложением SELECT можно задавать вывод символьного выражения и так же исчисляемую колонку (виртуальную).
Пример:
SELECT Tab_No, Fam, Oklad + Prem AS "оклад + премия".
В команде SELECT можно использовать специальные агрегатные функции:
COUNT () - количество отображаемых строк.
SUM () - суммирует значения числовых столбцов
MIN () - находит минимум числового столбца
MAX () - находит максимум числового столбца
AVG() - находит среднее значение числовой колонки, в скобках имя столбца.
Пример:
SELECT SUM(Oklad);
SELECT Name, SUM(Cena * Kol-vo) AS "Сумма";
SELECT COUNT(*);
SELECT MAX(Oklad), MIN(Oklad), AVG(Oklad).
Для отбора строк по заданному критерию используют предложение WHERE:
Пример:
SELECT имя покупателя
FROM заказ
WHERE Изд# = 139
Предикат IN в неявном виде заменяет квантор существования.
Пример:
WHERE X IN P(X) (эквивалентно xP(x))
WHERE X NOT IN P(X) (эквивалентно xP(x))
Множество, задающееся в предложении IN(), можно определить не только перечислением его элементов, но и косвенно, используя вложенный подзапрос:
Пример:
WHERE X IN (SELECT ... FROM ...)
Предикат LIKE осуществляет выбор на включаемые надстройки, задаваемой переменной или константой. Подстрока определяется заданными символами, замещёнными "-" (замещает один символ) и "%" (любое число символов):
Пример:
WHERE ФИО LIKE "ПЕТ%"
В предложении WHERE предикаты BETWEEN, IN, LIKE могут объединятся связями AND, OR, NOT.
Два дополнительных предложения GROUP BY и HAVING позволяют располагать строки по группам. Затем можно выполнять операции с этими группами. Например, использовать операцию агрегирования.
Предложение GROUP BY позволяет строки результирующей таблицы, определяемой предложением SELECT, сгруппировать в группы с одинаковым значением заданных колонок. После агрегирования каждая такая колонка сводится к одной строке результирующей таблицы. В качестве имени колонки используется имя агрегирующей функции с номером этой функции.
Предложение HAVING позволяет отображать составные группы строк, удовлетворяющих заданным условиям. Действие HAVING аналогичное WHERE, но определяет условие, которому должна удовлетворять каждая группа для вывода результирующей таблицы. Например, для вывода упорядоченного по алфавиту перечня деталей стоимостью более 300р., имеющихся на складе в количестве более 10 шт., можно использовать команду SELECT.
SELECT <номер>, SUM(<количество>), <стоимость>, <название>
FROM <склад>
WHERE <стоимость> > 300
GROUP BY <название>, <номер>, <стоимость>
HAVING SUM(<количество>) > 10
ORDER BY <название>
Если HAVING используется без GROUP BY, то его действие распространяется на всю таблицу и эквивалентно WHERE.
ORDER BY `<колонка | целое число [ASC, DESC]>'
Вместо имени колонки допустимо использование целого числа, определяющего её позицию в таблице SELECT.
Особенности языка SQL
фактический - стандарт обращения к современным БД;
ориентирован на операции с данными, представленными в виде совокупности таблиц (DBASE работает с записями);
ориентирован на конечный результат обработки. Система сама определяет оптимальный путь организации запроса в отличие от процедурных языков, требующих задания последовательности выполнения операций обработки. Поэтому говорят, что SQL более декларативен, чем язык РА, который ближе к процедурным языкам.
Объекты современных реляционных БД
Данные реляционных БД хранятся в виде таблиц. Для поддержки уникальности данных в колонках таблиц, а также для ускорения доступа используются индексы. Кроме таблиц, многие СУБД поддерживают представление и рассматривают их как отдельные объекты БД.
Представление
Представление -- виртуальная таблица, то есть таблица, которая сама по себе не существует, но для пользователя выглядит так, словно она существует. Тогда как базовая таблица -- реальная таблица, для любой строки которой существует двойник в физической памяти. То есть представления не поддерживаются их собственными физически хранимыми данными. Вместо этого в каталоге хранятся их определения в терминах других таблиц. Представление может быть создано с помощью команды SQL
CREATE VIEW <имя представления>
[(<имя поля>[,<имя поля>…])]
AS SELECT
FROM
WHERE
Когда исполняется это предложение, подзапрос, следующий за AS, не исполняется. Вместо этого, он просто сохраняется в каталоге. Но для пользователя это выглядит так, будто в БД действительно существует такая таблица. Эта таблица представляет собой фактически окно в реальную таблицу. Это окно является динамическим. Изменение в реальной таблице будут автоматически видны через это окно. Изменения в виртуальной таблице также будут автоматически внесены в реальную таблицу. Пользователь может производить операции над представлением, как если бы это была реальная таблица.
Синонимы
Синонимы представляют собой альтернативные имена таблиц, либо базовых, либо виртуальных. Чаще всего, синоним создается для таблицы. Которая была создана каким-нибудь другим пользователем и для которой вы должны были бы в противном случае использовать полностью уточненное имя. Например, пользователь Ivan создает таблицу
CREATE TABLE Primer,
тогда Петр может использовать таблицу Ivan.Primer. чтобы избежать длинных обращений, Петр может создать синоним
CREATE SYNONYM P1 FOR Ivan.Primer
и обращаться к таблице через P1.
Имя Р1 является частным для пользователя Петра. Другой пользователь может создать собственный синоним. Описание всех таблиц, представлений, синонимов хранится в специальном каталоге.
Каталог
Системная БД, содержащая дескриптор (информацию) относительно разных объектов, а именно: таблиц, представлений, синонимов, индексов, БД, прав доступа и т.д. Сам каталог состоит из множества таблиц, точно таких же, как обычные пользовательские таблицы.
SYS TABLES -- таблицы и представления. Обычно содержат поля:
Name - имя таблицы;
Creator - имя пользователя;
ColCount - количество столбцов.
SYS COLUMNS -- колонки БД. В каждой строке этой таблицы содержится информация о столбце какой-либо таблицы. Для этого служат поля
Name - имя столбца;
TBName - имя таблицы;
ColType - тип данных для столбца.
SYS INDEX -- любому индексу в системе отводится одна строка в этой таблице. Для каждого индекса в ней указано его имя, имя индексной таблицы TBName, имя пользователя и т.д.
Так как каталог состоит из таблиц точно таких же, как обычные пользовательские таблицы, из него можно запрашивать данные с помощью предложения SELECT.
Пример:
SELECT FROM SYSIBM.SYS COLUMNS WHERE Creator=''
Хранимые программы и процедуры
Обычно в среде клиент-сервер конечные приложения располагаются на клиентской машине и там же выполняются. Любой доступ к БД из приложения использует контакт с сервером по сети. Когда же приложение рассматривается внутри БД, оно называется хранимой командой или хранимой процедурой. Она выполняется непосредственно на компьютере сервера БД.
Хранимая команда -- SQL-запрос, который хранится на сервере в скомпилированном виде. Выполнение хранимой программы производится гораздо быстрее, чем обычные SQL-запросы, однако хранение команды имеет ограниченную функциональность в рамках синтаксиса SQL.
Хранимая процедура -- предложения, объединяющие SQL-запросы и процедурную логику. Хранимые процедуры позволяют хранить на сервере сложные приложения, выполняющие большой объем работы без передачи данных по сети и взаимодействия с клиентом. Хранимые процедуры обычно пишутся на автономном языке разработки конечных приложений.
Использование хранимых команд и процедур преследует следующие цели:
Повышение производительности;
Простота использования. Обычно технология, которая подразумевает большое число клиентов, подключаемых к серверу. Тогда использование хранимых команд и процедур позволяет хранить приложения на одном компьютере, а не на каждом компьютере в отдельности.
Усиление защищенности данных -- набор операций, которые могут быть осуществлены пользователем, легко контролируются с помощью управления доступом к небольшому количеству хранимых процедур. Нормальное завершение процедуры возвращает нулевое значение в вызвавшее ее приложение. Возвращенное значение может быть найдено в специальном файле, чтобы выдать пользователю сообщение об ошибке.
Триггеры
Триггеры -- определяемое пользователем действие, которое выполняется, когда над таблицей, к которой подключен триггер, выполняется операция INSERT, UPDATE или DELETE.
Триггеры используются для решения трех основных задач:
Усиление ссылочной целостности. Например, триггер можно использовать для реализации ограничений ссылочной целостности, выходящих за пределы стандартных ограничений СУБД. Пользователь может захотеть реализовать правило каскадного изменения данных. для этого необходимо создать триггер, который будет обновлять дочерние таблицы при каждом изменении колонки родительской таблицы.
Проверка данных => значения колонок могут пересекаться в триггере, представляемом в качестве параметров, где над ними могут производиться самые разнообразные операции. Например, пользователь может создать триггер, который будет получать из приложения данные для ввода в строку таблицы, создавать уникальный ключ для этой строки внутри своей процедуры и перерабатывать в БД полную строку с ключом.
Регистрация изменений данных. Создатель таблицы, или администратор БД может пожелать иметь информацию о времени каждого изменения данных в таблице, а также какой пользователь… Для этого он создает триггер, который поступает в системное время операции UPDATE имя пользователя. Процедура триггера затем вводит эту информацию в специальную таблицу регистрации изменений. Триггер может быть определен для выполнения либо перед операцией (BEFORE), либо после (AFTER) INSERT, UPDATE, DELETE.
Формат команды
CREATE TRIGGER ON <имя таблицы>
FOR DELETE | UPDATE | INSERT
AS <логическое выражение>
<логическое выражение> -- задает выражение, определяемое для выражения триггера. Параметром логического выражения может быть функция либо сохраненная процедура, возвращающая логическое выражение.
1.1.2 Иерархическая модель
Иерархическая модель БД представляет собой совокупность элементов, расположенных в порядке их подчинения от общего к частному и образующих перевернутое дерево (граф). Данная модель характеризуется такими параметрами, как уровни, узлы, связи. Принцип работы модели таков, что несколько узлов более низкого уровня
где A, B, C, D, E - типы записей (сегменты)
соединяются при помощи связи с одним узлом более высокого уровня.
Узел - информационная модель элемента, находящегося на данном уровне иерархии.
Совокупность корневой записи и множества подчинённых ей записей называется деревом. Число деревьев определяется числом корневых записей. Групповые отношения этой модели не именуются, т.к. определяются парой типов записей. К любой записи существует единственный путь от корня записи. Этот путь называется иерархическим. Каждая запись идентифицируется полным сцепленным ключом, под которым понимают совокупность ключей всех записей от корня вдоль иерархического пути.
Свойства иерархической модели данных:
Несколько узлов низшего уровня связано только с одним узлом высшего уровня.
Иерархическое дерево имеет только одну вершину (корень), не подчиненную никакой другой вершине.
Каждый узел имеет свое имя (идентификатор).
Существует только один путь от корневой записи к более частной записи данных.
Особенности иерархической модели данных
· Данные организованны в иерархической структуре;
· При отображении сетевых структур необходимо дублирование данных и меры по поддержанию семантической целостности;
· Основная единица обработки - запись;
· Обработка начинается с корневой записи, доступ к некорневым записям осуществляется по иерархическому пути.
Иерархическая структура реализуется отношением "один ко многим" между исходной и подчиненной записями, однако для предоставления отношения многих ко многим необходимо дублирование деревьев. При этом сохранение целостности БД ложится на программиста.
Операции над данными:
Извлечь по значению ключа;
Запомнить;
Обновить;
Удалить.
1.1.3 Сетевая модель
Сетевая модель БД похожа на иерархическую. Она имеет те же основные составляющие (узел, уровень, связь), однако характер их отношений принципиально иной. В сетевой модели принята свободная связь между элементами разных уровней.
Каждую сетевую структуру можно представить в виде иерархической модели, но при этом сеть нуждается в преобразовании:
С точки зрения теории графов сетевой модели соответствует произвольный граф, возможно -- с циклами и петлями, узлы которого - типы записей, а ребра - связи между ними.
Особенности сетевой модели
Позволяет устанавливать несколько признаков одинаково направленных групповых отношений между двумя типами записи;
Допускает циклические структуры.
Возможные операции над данными
Запомнить -- занести новую запись в БД и автоматически включить её в групповое отношение (ГО), где она объявлена подчиненной соответствующим режимам включения;
Включить -- позволяет подчинённую запись связать с записью-владельцем;
Переключить -- переключить подчинённую запись на другого владельца в том же ГО;
Исключить -- разрывает связь между владельцем и подчинённой записью, сохранив обе записи в БД.
Каждый тип ГО характеризуется:
1) способом упорядочивания подчиненной записи (ПЗ)
2) a) произвольный;
б) хронологический;
в) обратнохронологический;
г) сортированный;
3) режимом включения ПЗ
а) автоматический - подчинённая запись включается в отношение одновременно с запоминанием в БД, т.е. происходит автоматическое закрепление ПЗ за ее владельцем;
б) ручной - позволяет запомнить ПЗ в БД, а не включать сразу в ГО;
4) режимом исключения ПЗ вводится понятие класса принадлежности
Для сетевой модели:
a) фиксированный -- ПЗ жёстко закрепляется за владельцем и не может существовать без него (поэт и произведение). При удалении записи-владельца (ЗВ) система автоматически удаляет ПЗ;
б) обязательный -- каждая ПЗ всегда будет связана с некоторой ЗВ, но может быть переназначена на другую ЗВ. Для успешного удаления ЗВ необходимо, чтобы не было ПЗ с обязательным членством;
в) необязательный -- позволяет исключить ПЗ из экземпляра ГО, но сохранить её в БД, не прикрепляя к другому владельцу.
Основные особенности обработки данных в сетевых моделях
Обработка может быть начата с записи любого типа, независимо от её расположения в структуре БД;
От извлечённой записи возможны переходы, как к её подчинённым записям, так и к тем, которым она подчинена;
Основная структурная единица - набор, единица обработки - запись.
1.1.4 Объектно-ориентированная модель данных
В настоящий момент времени до конца не разработана.
1.2 Теория нормальных форм
Можно доказать, что любую структуру данных можно преобразовать в простую двухмерную таблицу. Такое представление является наиболее удобным и для пользователя, и для машины, - подавляющее большинство современных информационных систем работает именно с такими таблицами, т.е. с реляционными базами данных.
Основная идея реляционного подхода состоит в том, чтобы представить произвольную структуру данных в виде двухмерной таблицы, т.е. нормализовать структуру.
Каждая запись в таблице должна иметь первичный ключ, т.е. идентификатор (или адрес), значение которого однозначно определяет эту и только эту запись. Первичный ключ должен обладать двумя свойствами.
Однозначная идентификация записи: запись должна однозначно определяться значением ключа.
Отсутствие избыточности: никакое поле нельзя удалить из ключа, не нарушая при этом свойства однозначной идентификации.
Каждое значение первичного ключа в пределах таблицы должно быть уникальным. В противном случае невозможно отличить одну запись от другой. Указание ключа - это единственный способ отличить одну запись от другой. Обычно используют придуманные разработчиком уникальные цифровые значения - код, табельные номера и т.д.
Кроме первичного, могут использоваться так называемые простые (или вторичные) ключи таблицы. Простых ключей может быть множество. Они используются при упорядочивании (индексировании) таблиц.
Процесс превращения иерархической или сетевой структуры данных в реляционную называется нормализацией. Внешне эта операция очень проста, но содержит некоторые нюансы, игнорирование которых может привести к неприятностям. Нюансы эти заключаются в том, что даже для простых двухмерных структур приходится подправлять состав полей.
Например, мы включим в таблицу поле, значение которого не зависит от первичного ключа. В таком случае появляется возможность утери информации. Однако важнее другое: повторяя многократно одни и те же данные, мы не только переделаем массу лишней работы, но и неминуемо ошибемся. Поэтому следует стремиться к исключению из таблицы полей, которые не связаны непосредственно с первичным ключом таблицы. Для этого, помимо оперативной, можно создать несколько справочных таблиц. Оперативная таблица меняется часто, а справочники - редко, их легко выправить раз и навсегда, внося в дальнейшем лишь небольшие изменения.
При проектировании таблиц рекомендуются следующие "золотые правила":
Надо уяснить себе, что есть первичный ключ таблицы (т.е. убедиться, что двух записей с одинаковым значением ключа в таблице быть не может)
Если первичный ключ не просматривается, подумать, правильно ли подобран состав полей
Если первичный ключ безупречен, к нему можно дописывать любые атрибуты, зависящие только от ключа.
Если при просмотре подготовленной БД в паре таблиц обнаружится одноименное поле, которое не входит в первичный ключ ни одной из этих таблиц, - это ошибка нормализации. Система не сможет контролировать согласованность значений таких полей.
Состав атрибутов отношений БД должен удовлетворять двум основным требованиям:
Между атрибутами не должно быть нежелательных функциональных зависимостей (ФЗ);
Группировка атрибутов должна обеспечивать минимальное дублирование данных.
Удовлетворение этих требований достигается нормализацией отношений БД - пошаговый обратимый процесс декомпозиции (разложения) исходных отношений на более мелкие и простые отношения. При этом устраняются все нежелательные функциональные зависимости. Аппарат нормализации был разработан Е. Коддом.
В чём определяются различные нормальные формы (НФ)? Кодд выделил три НФ. На сегодня определены ещё четвёртая и пятая. Каждая НФ ограничена определённым типом ФЗ и устраняет соответствующие аномалии при вычислении операций над отношениями. При декомпозиции встает проблема обратимости. Декомпозиция гарантирует такое восстановление без потерь. В результате применения последовательности операций естественных соединений над проекциями исходных отношений должно получиться отношение, эквивалентное исходному, причём в результирующем отношении не должны появляться раньше отсутствующие кортежи - следствия ошибочного соединения.
Если есть атрибуты А и В, говорят что В функционально зависит от А, если для каждого значения А в любой момент времени существует ровно одно связанное с ним значение В, причём А и В могут быть составными - представлять собой группы, состоящие из 2-х и более атрибутов.
I нормальная форма
Простой атрибут - атрибут, значения которого неделимы, атомарны.
Сложный атрибут - атрибут, значение которого представляет собой конкатенацию значений одного/нескольких доменов (аналоги - агрегат, вектор, повторяющаяся группа)
Отношение находится в первой нормальной форме (НФ), если все атрибуты простые (атомарные) и нет повторяющихся групп. Отношение в I НФ должно быть прежде постановки вопроса о разбиении на два или более отношений, т.е. к I НФ необходимо привести универсальное отношение.
Универсальное отношение - отношение, в состав которого входят все атрибуты проектируемой БД.
Пример:
Сотрудники
|
ФИО |
Таб. № |
Отдел |
Тел. |
Дети |
||
|
Имя |
Возраст |
|||||
|
Борисов Борисов |
211 211 |
СС СС |
3-57 3-57 |
Иван Миша |
10 15 |
|
|
Андреев Андреев |
364 364 |
УП УП |
2-15 2-15 |
Маша Егор |
6 4 |
II нормальная форма
Отношение находится во II НФ, если оно находиться в I НФ, и каждый не ключевой атрибут функционально полно зависит от составного ключа.
Чтобы привести отношение ко 2 НФ необходимо:
Построить его проекцию, исключив атрибуты, которые не находятся в полной функциональной зависимости от составного ключа;
построить дополнительно одну или несколько проекций на часть составного ключа и атрибуты, функционально зависящие от этой части ключа. Атрибуты, функционально зависящие от одной и той же части ключа, объединяются в одно отношение.
Пример:
Универсальное отношение "Сотрудник" разбивается на два отношения:
Сотрудники Дети
|
Таб. № |
ФИО |
Отдел |
Тел. |
Таб. № |
Имя |
Возраст |
|
|
211 |
Борисов |
СС |
3-57 |
211 |
Иван |
10 |
|
|
211 |
Миша |
15 |
|||||
|
364 |
Андреев |
УП |
2-15 |
364 |
Маша |
6 |
|
|
364 |
Егор |
4 |
Наличие транзитивной зависимости порождает неудобства и аномалии следующего характера (например, атрибут Тел.):
Имеет место дублирование информации для сотрудников одного отдела;
Существует проблема контроля избыточности, поскольку изменение номера телефона отдела ведёт к необходимости поиска и замены номеров сотрудников отдела;
Аномалия добавления и удаления: нельзя включить данные о новом отделе, если на данный момент отсутствуют его сотрудники, и наоборот: при увольнении всех сотрудников отдела данные о нём нельзя сохранить.
Таким образом, отношение во II НФ также может потребовать дальнейших преобразований.
III нормальная форма
Отношение находиться в III НФ, если оно находиться во II НФ и в нём отсутствует транзитивная зависимость неключевых атрибутов от ключа.
Для преобразования к III НФ необходимо построить несколько проекций.
Пример:
(в нашем случае -- отношение "Сотрудник" разбить на два: Отдел - Тел.,
Таб. № - ФИО - Отдел).
|
Сотрудники |
Отдел |
Дети |
||||
|
Таб. № |
ФИО |
Отдел |
Отдел |
Тел. |
Дети - // - |
|
|
211 |
Борисов |
СС |
СС |
3-56 |
||
|
364 |
Андреев |
УП |
УП |
2-15 |
В итоге получили три таблицы: "Сотрудники", "Отдел", "Дети"
III НФ освобождает от избыточности и аномалий редактирования, если отношения имеют один ключ и другие зависимости (в т.ч. многозначные) в нём отсутствуют.
Но если имеются многозначные зависимости от ключа, то III НФ не обеспечивает отсутствия аномалий обновления. В этом случае применяют усиленную III НФ.
Усиленная III нормальная форма (Бойса-Кодда) НФБК
Отношение находятся в НФБК, если оно находится в III НФ, и в нём отсутствуют зависимости ключей от не ключевых атрибутов.
Пусть имеется отношение R(А, В, С) с ключом К = {А, В}. Между атрибутами этого отношения существуют ФЗ А, В С и С В:
А, В С - зависит от ключа
С В - зависимость ключа от не ключевых атрибутов
Пример:
А - адрес, В - город, С - индекс;
Проект (Деталь#, Проект#, Поставщик#);
Дет#, Пр# Пост#, Пост# Пр#
Каждый проект может обслуживаться несколькими поставщиками, но любой поставщик обслуживает только один проект.
Для приведения к НФБК необходимо выполнить
;
.
Хотя существует НФ более высокого уровня, которые накладывают даже более сильные ограничения на отношения, на практике обычно стараются получить отношение НФБК.
Переход к НФБК происходит не по схеме , а с использованием более общего подхода к декомпозиции отношения.
IV нормальная форма
Отношение, находится в IV НФ, если оно находится в НФБК, но в нем отсутствуют многозначные зависимости. IV НФ показывает, что отношение может находиться в НФБК, но тем не менее могут существовать аномалии, особенно при добавлении.
Например, для отношения преподаватель Препод (ФИО, группа, предмет) при появлении у преподавателя новой группы в отношение приходится добавлять не один кортеж, а столько, сколько предметов он читает в этой группе. Аналогичная ситуация возникает при добавлении в отношение нового предмета.
Устранение аномалий достигается разложением исходного отношения на несколько отношений с многозначной зависимостью от одного и того же ключа.
В нашем случае "Препод" разбивается на:
Предмет (ФИО, предмет)
Группа (ФИО, группа)
1.3 Достоверность и безопасность информации
Поскольку первичное заполнение таблиц и ввод их в машину ведет человек, ошибки в данных являются не исключением, а правилом, и любая ИС должна иметь средство для диагностики и исправления ошибок.
Нарушение логической взаимосвязи - это логические (семантические) ошибки, ошибки смысла, которые могут быть обнаружены аппаратом формального логического контроля, построенным для ИС. Кроме того, конкретная ИС может иметь собственные средства дополнительного ("нестандартного") контроля, так как стандартные средства не могут охватить все возможные случаи. В современных СУБД имеются средства поддержания целостности данных. Кроме того, в современных ИС можно указать условия, которым должны удовлетворять значения некоторых полей (условия верификации данных).
Гораздо сложнее дело обстоит с ошибками в допустимых значениях данных. Такие ошибки условно называются арифметическими, хотя это не совсем точно, так как ошибочно может быть записано значение текстового данного: например, Иванов И.П. вместо Иванов А.П. Существует ряд средств для выявления арифметических ошибок, однако на пользовательском уровне ограничиваются простым визуальным контролем.
Термин "безопасность" относится к защите базы данных от несанкционированного доступа. Под безопасностью БД подразумевается, что пользователям разрешается выполнять некоторые действия. Под целостностью подразумевается, что это действие выполняется корректно.
Существуют различные аспекты безопасности:
правовой;
физический;
аппаратное обеспечение;
безопасность БД.
СУБД поддерживает два подхода доступа к данным: избирательный и обязательный. В случае избирательного управления пользователь обладает различными правами при работе с разными объектами. В случае обязательного управления каждому объекту данных присваивается некоторый уровень доступа, а каждый пользователь обладает определенным уровнем. Доступом к определенному объекту обладает только пользователь с соответствующим уровнем доступа.
Избирательное управление доступом.
Для определения правил безопасности нужно использовать некоторый язык:
CREATE SECURITY RULE <правило>
GRANT <список привилегий>
ON <выражение>
TO <список пользователей>
[ON ATTENTED VIOLATION <действие>]
<правило> -- имя нового правила безопасности;
<список привилегий> может быть представлен:
RETRIEVE [<список атрибутов>]
INSERT
UPDATE [<список атрибутов>]
DELETE
ALL
<выражение> -- подразумевает выражение реляционного исчисления, в котором задано диапазоном действие данного правила. Диапазоном является некоторое подмножество кортежей единственного отношения.
<действие> -- процедура произвольной сложности, например, заблокировать клавиатуру, записать нарушение правил безопасности. Т.е. выполнить отслеживание угроз.
Пример:
CREATE SECURITY RULE ПС3 // создание правил секретности
GRANT RETRIEVE (У#, ЛФУ, Разр), DELETE
ON Узел WHERE ЛФУ<>"Сумматор"
TO Иванов, Петров, Сидоров // для пользователей
ON ATTENTED VIOLATION REJECT // не выполнять при нарушении этого правила
В системе должен быть предусмотрен способ устранения существующих правил безопасности.
DESTROY SECURITY RULE
Обязательное управление доступом
Каждый объект имеет некоторый уровень классификации. Эти уровни образуют строгую иерархию. Например, "совершенно секретно", "секретно", "для служебного пользования". Каждый пользователь имеет уровень доступа с такими же градациями, что и уровни классификации.
Можно сформулировать два простых правила:
Пользователь А имеет доступ к объекту В, если его уровень доступа больше или равен уровню классификации объекта;
Пользователь А может модифицировать объект В, если его уровень доступа равен уровню классификации объекта. Таким образом, любая информация, записанная пользователем А, приобретает классификацию, равную уровню пользователя А. Необходимо предотвратить запись секретных данных в файлы с меньшим уровнем классификации.
До сих пор предполагалось, что пользователь пытается незаконно проникнуть в БД с помощью обычных средств доступа, имеющихся в системе. Теперь рассмотрим случай, когда такой пользователь пытается проникнуть в БД, минуя систему, то есть физически перемещая часть БД или подключаясь к коммуникационному каналу. Наиболее эффективным методом борьбы является шифрование данных.
Исходные (незакодированные) данные называются открытым текстом. Открытый текст шифруется с помощью специального алгоритма шифрования. В качестве входных данных поступает открытый текст и ключ шифрования, на выводе -- зашифрованный текст. Если алгоритм может не утаиваться, то ключ хранится в секрете.
Обычно выделяются следующие методы шифрования: процедуры подстановки, перестановки, комбинация указанных методов.
Рассмотрим алгоритм шифрования на примере использования процедуры подстановки.
Разбейте открытый текст на блоки, длина которых равна длине ключа шифрования. пусть в качестве открытого текста дана строка:
AS KINGFISHERS CATCH FIRE
ключ: ELIOT
разбиение: "AS_KI", "NGFIS", "HERS_", "CATCH", "_FIRE"
Замените каждый символ открытого текста целым числом в диапазоне от 0 до 26, используя для пробелов число 00. В результате получится строка чисел
0119001109 1407060919 0805181900 0301200308 0006091805,
ключ: 0512091520.
Значение для каждого символа в каждом блоке открытого текста просуммируйте с соответствующими значениями каждого символа ключа шифрования по модулю 27.
Для нашего примера получим
0604092602 1919152412 1317100620 0813021801 0518180625
Замените каждое число в строке соответствующим текстом символов:
"FDIZB", "SSOXL", "MQJFT", "HMBRA", "ERRGY"
зашифрованный текст: FDIZBSSOXLMQJFTHMBRAERRGY
Если ключ известен, расшифровка может быть выполнена достаточно быстро.
Глава 2. Основы разработки базы данных
Прежде чем приступать к работе с базой данных, в первую очередь необходимо выбрать модель представления данных. Она должна отвечать следующим требованиям:
Наглядность представления информации;
Простота ввода информации;
Удобство поиска и отбора информации;
Возможность использования информации, введенной в другую базу;
Возможность быстрой перенастройки базы данных (добавление новых полей, новых записей, их удаление).
При разработке БД можно выделить следующие этапы работы.
I этап. Постановка проблемы
На этом этапе формируется задание по созданию БД. В нем подробно описывается состав базы, назначение и цели ее создания, а также перечисляется, какие виды работ предполагается осуществлять в этой базе данных (отбор, дополнение, изменение данных, печать или вывод отчета и т.д.).
II этап. Анализ объекта
На этом этапе необходимо рассмотреть, из каких объектов может состоять ваша БД, каковы свойства этих объектов. После разбиения БД на отдельные объекты необходимо рассмотреть свойства каждого из этих объектов, другими словами, установить, какими параметрами описывается каждый объект. Все эти сведения можно располагать в виде отдельных записей и таблиц. Далее необходимо рассмотреть тип данных каждой отдельной единицы записи (текстовый, числовой и т.д.). Сведения о типах данных также следует занести в составляемую таблицу.
Подобные документы
Понятие базы данных, её структура. Общие принципы хранения информации. Краткая характеристика особенностей иерархической, сетевой и реляционной модели организации данных. Structured Query Language: понятие, состав. Составление таблиц в Microsoft Access.
лекция [202,8 K], добавлен 25.06.2013Основные этапы проектирования базы данных. Access как система управления базами данных (СУБД), ее предназначение, отличительные возможности. Работа с таблицами, их создание и редактирование. Порядок создания запросов. Способы защиты баз данных.
лабораторная работа [3,1 M], добавлен 18.08.2009Базы данных с двумерными файлами и реляционные системы управления базами данных (СУБД). Создание базы данных и обработка запросов к ним с помощью СУБД. Основные типы баз данных. Базовые понятия реляционных баз данных. Фундаментальные свойства отношений.
реферат [57,1 K], добавлен 20.12.2010Система управления базой данных (СУБД), централизованное обеспечение безопасности и целостности данных, защита от несанкционированного доступа. Построение концептуальной и реляционной моделей. Процесс нормализации. Проектирование базы данных в ACCESS.
курсовая работа [1,8 M], добавлен 29.10.2008Понятие и сущность базы данных, их классификация и характеристика. Системы управления базами данных. СУБД структуры "сервер-клиент", его суть. Microsoft Access - функционально полная реляционная СУБД. Предназначение СУБД Access, и описание ее работы.
реферат [44,3 K], добавлен 27.02.2009Основные понятия, используемые в теории управления базами данных. Характеристика объектов MS Access. Построение базы данных, содержащей информацию об учебном процессе текущего семестра. Свойства полей таблицы, работа с записями, импортирование данных.
лабораторная работа [46,0 K], добавлен 23.12.2010Общая характеристика системы управления базами данных MySQL, ее основные особенности и возможности, касающиеся обеспечения целостности данных. Реализация ограничений семантической и ссылочной целостности в СУБД MySQL на примере фрагмента ИС "Салон магии".
курсовая работа [981,0 K], добавлен 14.10.2012Современные системы управления базами данных (СУБД). Анализ иерархической модели данных. Реляционная модель данных. Постреляционная модель данных как расширенная реляционная модель, снимающая ограничение неделимости данных, хранящихся в записях таблиц.
научная работа [871,7 K], добавлен 08.06.2010Преимущества и недостатки иерархической модели данных. Целостная часть реляционной модели данных. Базовые требования целостности сущностей и по ссылкам. Ограничения целостности сущности и по ссылкам. Аксиомы Армстронга, аномалии обновления и их виды.
контрольная работа [262,3 K], добавлен 05.02.2011Исследование процесса разработки базы данных, позволяющей определять состояние кафедр и факультетов Дагестанского государственного технического университета. Характеристика иерархической, сетевой, реляционной, даталогической и физической моделей данных.
курсовая работа [156,7 K], добавлен 08.02.2012
