Инфологическая и логическая модель реляционной базы данных.

Вопросы по MS Access

1. Понятия «данные» и «структурированные данные». Определение и назначение базы данных.

2. Понятие системы управления базами данных. Важнейшие функции СУБД.

3. Этапы проектирования базы данных.

4. Иерархическая, сетевая и реляционная модели данных.

5. Реляционная модель данных. Понятие ключа таблицы. Типы ключей.

6. Связи между таблицами. Связи типа «один к одному» и «один ко многим».

7. Инфологическая и логическая модель реляционной базы данных.

8. Обеспечение целостности данных в таблицах.

9. Нормализация отношений в таблицах.

10. Назначение, основные возможности СУБД Access. Основные элементы окна. Основные объекты базы данных.

11. Создание таблиц в режиме конструктора и с использованием Мастера. Однотабличные и многотабличные базы данных.

12. Использование арифметических, условных и логических выражений в MS Access.

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

14. Использование арифметических, условных и логических выражений в MS Access.

15. Понятие запроса. Типы запросов в CУБД Access. Построение запросов.

16. Создание запросов на обновление, удаление, с параметрами. Создание итогового и перекрестного запросов.

17. Понятие формы. Создание сложной формы. Создание форм с вычисляемыми полями.

18. Подчиненная форма. Вставка в форму диаграммы.

19. Создание форм для ввода, просмотра данных. Использование режима конструктора и Мастера.

20. Формы для многотабличной базы данных.

21. Создание кнопочных форм с помощью СУБД Access.

22. Понятие отчета. Использование отчета для представления информации.

23. Создание отчетов различных типов.

24. Использование вычисляемых полей в отчетах.

25. Выбор и корректировка макета отчета.

1. Понятия «данные» и «структурированные данные». Определение и назначение базы данных.

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

Неструктурированные данные– данные, записанные, например, в текстовом файле: Личное дело № 1 Сидоров Олег Иванович, дата рожл. 14.11.92, Личное дело № 2 Петрова Анна Викторовна, дата рожд. 15.03.91.

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

Пример структурированных данных: № Ф. И. О Дата рожд.

1СидоровОлег Иванович 14.11.92

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

А – поле (столбец) – это элементарная неделимая единица организации информации

Б – запись (строка) – это совокупность логически связанных полей

В – таблица (файл) – это совокупность экземпляров записей одной структуры.

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

Назначение БД:

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

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

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

4. Поддержка целостности данных. Целостность базы данных означает корректность и непротиворечивость хранимых в ней данных. Целостность обычно описывается с помощью ограничений, т.е. правил под­держки непротиворечивости, которые не должны нарушаться в базе данных. Ограничения можно применять к элементам данных внутри одной записи или к связям между записями. Например, ограничение целостности может гласить, что зарплата сотрудника не должна превышать 40 000 рублей в год или же что в записи с данными о сотруднике номер отделения, в котором он работает, должен соответствовать реально существующему отделению компании.

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

Понятие системы управления базами данных. Важнейшие функции СУБД.

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

Первые СУБД были разработаны фирмами IBM – IMS (1968 г.) и Software AG– ADABA• (1969 г.).

Важнейшие функции СУБД:

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

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

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

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

Обеспечение логической и физической независимости данных.

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

Защита логической целостности базы данных.

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

Защита физической целостности.

При работе ЭВМ возможны сбои в работе (например, из-за отключения электропитания), повреждение машинных носителей данных. При этом могут быть нарушены связи между данными, что приводит к невозможности дальнейшей работы. Развитые СУБД имеют средства восстановления базы данных. Важнейшим используемым понятием является понятие «транзакции». Транзакция – это единица действий, производимых с базой данных. В состав транзакции может входить несколько операторов изменения базы данных, но либо выполняются все эти операторы, либо не выполняется ни один. СУБД, кроме ведения собственно базы данных, ведет также журнал транзакций.

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

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

Синхронизация работы нескольких пользователей.

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

Управление ресурсами среды хранения.

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

Поддержка деятельности системного персонала.

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

Этапы проектирования базы данных.

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

I этап. Постановка задачи.

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

II этап. Анализ объекта.

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

III этап. Синтез модели.

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

IV этап. Выбор способов представления информации и программного инструментария.

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

В большинстве СУБД данные можно хранить в двух видах:

l с использованием форм;

l без использования форм.

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

V этап. Синтез компьютерной модели объекта.

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

Стадия 1. Запуск СУБД, создание нового файла базы данных или открытие созданной ранее базы.

Стадия 2. Создание исходной таблицы или таблиц.

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

При проектировании таблиц, рекомендуется руководствоваться следующими основными принципами:

1. Информация в таблице не должна дублироваться.

2. Каждая таблица должна содержать информацию только на одну тему.

3. Каждая таблица должна содержать необходимые поля.

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

Стадия 3. Создание экранных форм.

Первоначально необходимо указать таблицу, на базе которой будет создаваться форма. Стадия 4. Заполнение БД.

Процесс заполнения БД может проводиться в двух видах: в виде таблицы и в виде формы. Числовые и текстовые поля можно заполнять в виде таблицы, а поля типа МЕМО и OLE – в виде формы.

VI этап. Работа с созданной базой данных.

Работа с БД включает в себя следующие действия:

l поиск необходимых сведений;

l сортировка данных;

l отбор данных;

l вывод на печать;

l изменение и дополнение данных.

Иерархическая, сетевая и реляционная модели данных.

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

Сетевая модель данных предполагает наличие вертикальных и горизонтальных связей, а также перекрестных связей (каждый элемент может быть связан с любым другим элементом.) Недостаток: сложность поиска данных.
Концепция реляционной модели данных (РМД) была предложена Е.Ф.Коддом в 1970 году. Эта модель характеризуется простотой структуры данных, удобным для пользователя табличным представлением. В основе РМД лежит понятие ОТНОШЕНИЯ.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц, которые обладают след свойствами:

- строки соответствуют записям, а столбцы - полям.

- каждый элемент таблицы-один элемент данных

- все столбцы в таблице однородные, т е все элементы в столбце имеют одинаковый тип (числовой, символьный и т д) и длину

- каждый столбец имеет уникальное имя

- одинаковые строки в таблице отсутствуют

- порядок следования строк и столбцов может быть произвольным

Реляционная модель данных. Понятие ключа таблицы. Типы ключей.

Концепция реляционной модели данных (РМД) была предложена Е.Ф.Коддом в 1970 году. Эта модель характеризуется простотой структуры данных, удобным для пользователя табличным представлением. В основе РМД лежит понятие ОТНОШЕНИЯ.
Реляционная модель ориентирована на организацию данных в виде двумерных таблиц, которые обладают след свойствами:

- строки соответствуют записям, а столбцы - полям.

- каждый элемент таблицы-один элемент данных

- все столбцы в таблице однородные, т е все элементы в столбце имеют одинаковый тип (числовой, символьный и т д) и длину

- каждый столбец имеет уникальное имя

- одинаковые строки в таблице отсутствуют

- порядок следования строк и столбцов может быть произвольным

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

Ключи

Ключевое поле- поле, по которому можно однозначно выделить, найти запись таблицы.

Ключевые поля бывают двух типов — первичные (Primary Key) и внешние (Foreign Key). Первичные ключи служат для однозначного определения записи в таблице и должны содержать уникальные для данной таблицы значения. Система автоматически предотвращает ввод в такое поле повторяющихся и пустых (Null) значений. Вторичные ключи выполняют роль поисковых или группировочных признаков по значению вторичного ключа можно найти несколько записей).

6. Связи между таблицами. Связи типа «один к одному» и «один ко многим».

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

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

(М:М) предполагает, что в каждый момент времени одному экземпляру информ.об."А" соответствует 0, 1 или более экземпляров объекта "В" и наоборот. Такие связи не могут непосредственно реализовываться в реляционной базе данных. Поэтому в том случае, когда будут выявлены, такие связи, может возникнуть необходимость их преобразования путем введения дополнительного объекта "связка". Исходные объекты будут, связаны с этим объектом одно/многозначными связями. Таким образом, объект-связка является подчиненным в одно/многозначных связях по отношению к каждому из исходных объектов.

Инфологическая и логическая модель реляционной базы данных.

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

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

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

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

Инф.об.может иметь несколько ключей.

Информационно-логическая модель реляционной базы данных

Логическая модель.

Обеспечение целостности данных в таблицах.

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

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

связанные поля имеют один тип данных. Здесь существует два исключения. Поле счетчика может быть связано с числовым полем, если в последнем поле в свойстве Размер поля (FieldSize) указано значение Длинное целое (Long Integer), или в обоих полях свойство Размер поля (FieldSize) имеет значение Код репликации (Replication ID);

обе таблицы принадлежат одной базе данных Microsoft Access.

Замечание

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

Дата добавления: 2015-10-29