
- •3. Классификация инфо. Системы классификации.
- •4. Классификаторы инфо, их назначение, виды.
- •5. Кодирование инфо. Методы кодирования.
- •15. Реляционная целостность
- •27. Правила преобразования er-диаграмм в реляц таблицы в случае связи1:м, м:м.
- •34. Понятие субд. Архитектура субд.
- •35. Функциональные возможности субд. Производительность субд
- •47. Инструментальные средства для создания бд и ее объектов, для выполнения расчетов
- •43. Формальные логические модели.
- •Роль sql в субд
- •Достоинства sql
- •57. Структура команды языка sql.
- •58. Типы данных и выражения в sql.
- •Константы
- •Операторы:
- •59. Диалекты языка sql в субд.
- •60 Эволюция концепций обработки данных
- •61. Системы удаленной обработки
- •62. Системы срвместного использования файлоа.
- •64. Клиенты, серверы. Клиентские приложения, серверы баз данных
- •65.Функции клиентского прилож.И сервера бд,
- •66.Общие сведен о храним процедур.И триггерах
- •68 Механизмы доступа к данным
- •69. Понятие и архитектура распределенных баз данных (РаБд). Стратегии распределения данных в РаБд. Гомогенные и гетерогенные РаБд
- •70. Распределенные субд (РаСубд). Двенадцать правил к. Дейта
- •72. Хранилища данных.
- •73. Пользователи и администраторы базы данных.
- •75. Методы защиты баз данных:
- •76. Восстановление базы данных с помощью резервного копирования базы данных,журн транз.
- •77. Оптимизация работы базы данных.
- •78. Возможности access по администрированию бд.
- •79. Правовая охрана баз данных
27. Правила преобразования er-диаграмм в реляц таблицы в случае связи1:м, м:м.
4 Если связь типа 1:М и класс принадлежности сущности на стороне М является обязательным, то необходимо построить таблицу для каждой сущности. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Первичный ключ сущности на стороне 1 добавляется как атрибут в таблицу для сущности на стороне М.
5 Если связь типа 1:М и класс принадлежности сущности на стороне М является необязательным, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
6 Если связь типа М:N, то необходимо построить три таблицы – по одной для каждой сущности и одну для связи. Первичный ключ сущности должен быть первичным ключом соответствующей таблицы. Таблица для связи среди своих атрибутов должна иметь ключи обеих сущностей.
28. Нормализация таблиц, ее цель. Первая нормальная форма. Вторая нормальная форма. Третья нормальная форма. Реляционная база данных считается эффективной, если все ее таблицы находятся как минимум в 3НФ. Нормализация таблиц – это процесс, позвол. миниз. избыточность данных. 1НФ. Таблица находится в 1НФ, если все ее поля содержат только неделимые значения. На практике. Если в клетках столбца содержится несколько значений, то каждое из них следует представить отдельной записью. 2 НФ, если она находится в 1 НФ и ее не ключевые поля зависят от первичного ключа. На практике. Неключевые поля, находящиеся в частичной ФЗ от некоторого подмножества первичного ключа, удаляются из таблицы и помещаются в новую таблицу совместно с подмножеством первичного ключа, от которого они зависят. Функциональная зависимость (ФЗ)– это семантическое понятие, отображающее определенную семантическую связь между полями таблицы. 3НФ если в таблице не имеется транзитивных зависимостей между не ключевыми полями, т.е. значение любого поля таблицы, не входившего в первичный ключ, не зависит от значения другого поля, не входившего в первичный ключ.
Преимущества нормальных форм таблиц: устранение избыточности таблиц; независимость записей в таблице с первичным ключом от записей в таблице с соответствующим внешним ключом, т.е. записи в таблице с внешним ключом (detail -таблицы) могут быть изменены (удалены) без нарушений в master – таблицы.
29. Цель этапа концептуального проектирования – создание концептуальной модели данных исходя из представлений пользователей о предметной области. Для ее достижения выполняется ряд последовательных процедур.
1. Определение сущностей и их документирование. Для идентификации сущностей определяются объекты (сущности), которые существуют независимо от других. Имена и описания сущностей заносятся в словарь данных. 2. Определение связей между сущностями и их документирование. 3. Создание ER-модели предметной области. Для представления сущностей и связей между ними используются ER-диаграммы. На их основе создается единый наглядный образ моделируемой предметной области – ER-модель предметной области. 4. Определение атрибутов и их документирование. Выявляются все атрибуты, описывающие сущности созданной ER-модели. 5. Определение значений атрибутов и их документирование. Для каждого атрибута сущности, участвующей в ER-модели, определяется набор допустимых значений и ему присваивается имя. 6. Определение первичных ключей для сущностей и их документирование. 7. Обсуждение концептуальной модели данных с конечными пользователями.
30. Цель этапа логического проектирования – преобразование концептуальной модели на основе выбранной модели данных в логическую модель, не зависимую от особенностей используемой в дальнейшем СУБД для физической реализации базы данных. Процедуры:
1. Выбор модели данных. Чаще всего выбирается реляционная модель данных в связи с наглядностью табличного представления данных и удобства работы с ними.
2. Определение набора таблиц исходя из ER-модели и их документирование.
3. Нормализация таблиц. На этом шаге проектировщик проверяет корректность структуры таблиц, созданных на предыдущем шаге, посредством применения к ним процедуры нормализации.
4. Проверка логической модели данных на предмет возможности выполнения транзакций. Если во время выполнения транзакции произойдет сбой в работе компьютера, то база данных окажется в противоречивом состоянии, так как некоторые изменения уже будут внесены, а остальные еще нет. Поэтому все частичные изменения должны быть отменены для возвращения базы данных в прежнее непротиворечивое состояние.
5. Определение требований поддержки целостности данных и их документирование. Эти требования представляют собой ограничения, которые вводятся с целью предотвратить помещение в базу данных противоречивых данных.
6. Создание окончательного варианта логической модели данных и обсуждение его с пользователями.
31. Цель этапа физического проектирования – описание конкретной реализации базы данных, размещаемой во внешней памяти компьютера.
1. Проектирование таблиц базы данных средствами выбранной СУБД.
2. Реализация бизнес-правил в среде выбранной СУБД.
3. Проектирование физической организации базы данных. На этом шаге выбирается наилучшая файловая организация для таблиц. Выявляются транзакции, которые будут выполняться в проектируемой базе данных, и выделяются наиболее важные из них.
4. Разработка стратегии защиты базы данных.
5. Организация мониторинга функционирования базы данных и ее настройка.
32. Семантическая объектная модель (СОМД). В основе СОМД лежит понятие семантического объекта. Семантический означает "смысловой" и семантический объект – это объект, который в определенной степени моделирует смысл пользовательских данных. Семантический объект – это представление некоторой вещи, идентифицируемой в рабочей среде пользователя. Подобно сущностям семантический объект имеет набор атрибутов, являющийся достаточным описанием объекта, т.е. он описывает все характеристики, необходимые пользователям для работы.
Есть три типа атрибутов. Простые атрибуты состоят из одного элемента. Н-р, Код клиента. Групповые – совокупности нескольких атрибутов. Н-р, Адрес (Улица, Город, Республика, Индекс). Семантические объектные атрибуты – это атрибуты, которые устанавливают связь между двумя семантическими объектами.
Домен – набор всевозможных значений атрибута.
На объектных диаграммах объекты изображаются в вертикально ориентированных прямоугольниках
Экземпляр объекта-атрибут получивш конкрет знач-е. В СОМД объектные атрибуты должны быть парными. Если один объект содержит в себе другой, то этот другой содержит в себе первый. Так, объект УНИВЕРСИТЕТ должен содержать объект КАФЕДРА. СОМД в качестве базовых элементов рассматривает не сущности, а семантические объекты. Она содержит больше информации о значении данных, чем модель "сущность-связь".
33. Case-средства для моделирования данных. Назначения и функ-ные возможности ERwin. ER-модели получили широкое распространение в CASE - средствах. Эти средства предназначены для автоматизированного проектирования реляционных баз данных. Их графические средства моделирования предметной области дают возможность наглядно изучать концептуальную модель данных и перестраивать ее соответственно поставленным целям и имеющимся ограничениям. Проект БД готовится в реальном масштабе времени.