- •1.Сравнительные характеристики автоматизированных информационных систем (ис): файловые системы и системы баз данных (бд).
- •2.Основные понятия теории баз данных. Банк данных и его компоненты.
- •3.Классические модели систем бд – организация и обработка данных.
- •4.Основные понятия в концептуальном проектировании реляционных баз данных (сущность , атрибуты , отношения ). Элементы реляционной модели.
- •Зависимости между атрибутами
- •5.Целостность данных и ее виды. Нарушения целостности (аномалии).
- •6.Функциональные связи атрибутов и нормализация таблиц. Основные нормальные формы (нф). Примеры нф.
- •7.Использование er–моделирования в концептуальном проектировании бд. Диаграммы er- экземпляров и er-типов.
- •8.Преобразование концептуальной модели в реляционную. Основные этапы и правила формирования отношений (пример).
- •9.Структура и основные технические характеристики субд access 200*.Возможности проектирования персональных и сетевых приложений.
- •10.Конструирование таблиц в ms access хр.Свойства полей. Определение типа данных, ключей, индексов.
- •11.Связывание таблиц в субд access. Логическая схема и обеспечение ссылочной целостности данных .
- •12.Средства реализации запросов в субд access. Виды запросов.
- •5.2.3 Запрос к связанным таблицам
- •5.2.4 Запросы удаления
- •13.Реализация запросов с групповыми операциями и вычисляемыми полями. Примеры.
- •14.Реализация запросов на модификацию и на создание таблицы.
- •15.Стандарты современных реализаций языка sql. Основные разделы и их наполнение в sql-Jet.
- •16.Общий формат select-инструкции (запроса на выборку). Пример реализации.
- •17.Пример qbe- и sql–реализации перекрестного запроса.
- •18.Создание интерфейса приложения в субд access. Работа в конструкторе форм. Разделы, элементы управления, свойства.
- •19.Создание вложенных sql-запросов. Пример реализации.
- •20.Программы сервиса субд access.
- •21.Защита и администрирование бд средствами субд access.
- •22.Использование макросов, отчетов и страниц доступа к данным в приложениях ms access хр.
- •23.Система программирования Matlab: общая характеристика. Пакеты расширения и специализированные приложения: назначения и возможности. Подсистема Simulink.
- •24.Структуры данных и основные структуры управления в системе программирования matlab
- •25.Графические средства системы matlab. Работа с инструментом lti-Viewer графического анализа линейных систем управления.
- •26.Этапы построения модели в подсистеме Simulink. Элементы технологии визуально-блочного моделирования. Настройка параметров моделирования и параметров блоков.
- •27.Общее описание блоков библиотеки simulink.
- •28.Реализация принципа иерархии в Simulink – моделях посредством блоков портов и подсистем. Маскирование подсистем.
- •29.Компоненты виртуального прибора и их сборка в приложение в среде LabView. Основные элементы управления и индикаторы LabView и их соединение на блок-диаграмме.
11.Связывание таблиц в субд access. Логическая схема и обеспечение ссылочной целостности данных .
Установление связей между таблицами
Установление связи между таблицами выполняется в окне Схема данных из меню Сервис (имеется одноимённая кнопка). . Для того, чтобы установить связь следует добавить связываемые таблицы в окно Схема данных: в этом окне вызвать контекстное меню, выбрать пункт Добавить таблицы, затем из списка имеющихся таблиц отметить те, которые надо поместить в поле окна Схема данных. При очередной отметке выбранная таблица со списком имен будет появляться в окне схемы данных.
Установление связи между таблицами выполняется буксировкой ключевого поля одной таблицы на связываемое поле в другой таблице, внутри окна Схема связи. Тип создаваемой связи зависит от полей, для которых определяется связь.
После создания совокупности таблиц требуется выполнить связывание таблиц. Как известно, установление табличных связей позволяет контролировать целостность и достоверность информации в базе данных. Кроме того, чем раньше образованы связи между таблицами, тем удобнее создавать многотабличные запросы, формы и отчеты. При наличии связей между таблицами разработка перечисленных объектов БД ведется с учетом установленных связей.
Второе требование называется требованием целостности по ссылкам и является несколько более сложным. Очевидно, что при соблюдении нормализованности отношений сложные сущности реального мира представляются в реляционной БД в виде нескольких кортежей нескольких отношений. Например, представим, что нам требуется представить в реляционной базе данных сущность ОТДЕЛ с атрибутами ОТД_НОМЕР (номер отдела), ОТД_КОЛ (количество сотрудников) и ОТД_СОТР (набор сотрудников отдела). Для каждого сотрудника нужно хранить СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ (имя сотрудника) и СОТР_ЗАРП (заработная плата сотрудника). Как мы вскоре увидим, при правильном проектировании соответствующей БД в ней появятся два отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ ) (первичный ключ - ОТД_НОМЕР) и СОТРУДНИКИ ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП, СОТР_ОТД_НОМ ) (первичный ключ - СОТР_НОМЕР).
Как видно, атрибут СОТР_ОТД_НОМ появляется в отношении СОТРУДНИКИ не потому, что номер отдела является собственным свойством сотрудника, а лишь для того, чтобы иметь возможность восстановить при необходимости полную сущность ОТДЕЛ. Значение атрибута СОТР_ОТД_НОМ в любом кортеже отношения СОТРУДНИКИ должно соответствовать значению атрибута ОТД_НОМ в некотором кортеже отношения ОТДЕЛЫ. Атрибут такого рода называется внешним ключом, поскольку его значения однозначно характеризуют сущности, представленные кортежами некоторого другого отношения (т.е. задают значения их первичного ключа). Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором такой же атрибут является первичным ключом.
Требование целостности по ссылкам, или требование внешнего ключа состоит в том, что для каждого значения внешнего ключа, появляющегося в ссылающемся отношении, в отношении, на которое ведет ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть неопределенным (т.е. ни на что не указывать). Для нашего примера это означает, что если для сотрудника указан номер отдела, то этот отдел должен существовать.