- •I этап. Постановка задачи.
- •II этап. Анализ объекта.
- •III этап. Синтез модели.
- •IV этап. Выбор способов представления информации и программного инструментария.
- •V этап. Синтез компьютерной модели объекта.
- •VI этап. Работа с созданной базой данных.
- •Семантическая модель Entity-Relationship (Сущность-Связь)
- •10.2.1. Основные понятия er-модели
- •10.2.2. Уникальные идентификаторы типов сущности
- •Case-средства. Общая характеристика и классификация
- •Концептуальное (инфологическое) проектирование
- •4.1.1.Структура данных.
- •4.1.2.Свойства отношений.
- •Понятие функциональной, транзитивной и многозначной зависимости. Примеры.
- •Введение
- •Преимущества и недостатки [править] Преимущества [править] Независимость от конкретной субд
- •[Править] Наличие стандартов
- •[Править] Декларативность
- •[Править] Недостатки [править] Несоответствие реляционной модели данных
- •Операторы
- •Предикат сравнения
- •2.3.4.2.2 Предикат between
- •2.3.4.2.3 Предикат in
- •2.3.4.2.4 Предикат like
- •2.3.4.2.5 Предикат null
- •2.3.4.2.6 Предикат с квантором
- •Что такое агрегатные функции ?
- •Как использовать агрегатные функции ?
- •Специальные атрибуты count
- •Использование distinct
- •Использование count со строками, а не значениями
- •Включение дубликатов в агрегатные функции
- •Агрегаты построенные на скалярном выражении
- •Предложение group by
- •Предложение having
- •Не делайте вложенных агрегатов
- •Управление доступом в базах данных
- •Запросы
- •Макросы
- •Поле объекта ole
- •Гиперссылка
- •Мастер подстановок
- •Добавление записи
- •Изменение записи
- •Удаление содержимого поля или удаление всей записи
- •Создание схемы
- •Дополнительные параметры
- •Назначение и виды запросов в Access. Назначение запросов.
- •Виды запросов.
- •( Для показа суммирования в одной колонке):
- •( Для создания всевозможных подсчетов на базе Схемы данных):
- •8.2. Вычисления в запросах, возможности создания и редактирования формул.
- •8.4. Использование запросов на Удаление и на Обновление.
- •Типы отчетов Access: краткий обзор
- •Простые отчеты
- •Иерархические отчеты
- •Отчеты, содержащие отсортированные, сгруппированные записи или записи обоих типов
- •Отчет, содержащий отсортированные записи
- •Отчет, содержащий сгруппированные записи
- •Перекрестный отчет
- •Отчет, содержащий несколько столбцов
- •Структура программ на vba
- •Стандартные способы защиты Защита с использованием пароля бд
- •Защита с использованием пароля пользователя
- •Нестандартные способы защиты Изменение расширения файла
- •Защита с использованием пароля бд, содержащего непечатные символы
- •Защита с модификацией файла
- •Защита изменением версии бд
- •Защита с использованием электронного ключа
- •Шифрование значений таблиц
- •Заключение
- •Администратор базы данных (dba)
- •История
- •Основные задачи администратора базы данных
- •Основные типы администраторов бд
- •Поддержка мультимедийных объектов
- •5.1.1. Третичная память
- •5.1.2. Новые типы данных
- •5.1.3. Качество обслуживания
- •5.1.4. Запросы с нечеткими критериями
- •5.1.5. Поддержка пользовательских интерфейсов
- •5.2. Распределение информации
- •5.2.1. Степень автономности
- •5.2.2. Учет и расчеты
- •5.2.3. Безопасность и конфиденциальность
- •5.2.4. Репликация и согласование данных
- •5.2.5. Интеграция и преобразование данных
- •5.2.6. Выборка и обнаружение данных
- •5.2.7. Качество данных
- •5.3. Новые применения баз данных
- •5.3.1. Интеллектуальный анализ данных
- •5.3.2. Хранилища данных
- •5.3.3. Репозитарии
- •5.4. Управление потоками работ и транзакциями
- •5.4.1. Управление потоками работ
- •5.4.2. Альтернативные модели транзакций
- •5.5. Простота использования
- •6. Выводы
Концептуальное (инфологическое) проектирование
Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.
Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам.
Чаще всего концептуальная модель базы данных включает в себя:
описание информационных объектов, или понятий предметной области и связей между ними.
описание ограничений целостности, т.е. требований к допустимым значениям данных и к связям между ними.
9
Це́лостность ба́зы да́нных (database integrity) — соответствие имеющейся в базе данных информации её внутренней логике, структуре и всем явно заданным правилам. Каждое правило, налагающее некоторое ограничение на возможное состояние базы данных, называется ограничением целостности (integrity constraint). Примеры правил: вес детали должен быть положительным; количество знаков в телефонном номере не должно превышать 25; возраст родителей не может быть меньше возраста их биологического ребёнка и т.д.
Задача аналитика и проектировщика базы данных — возможно более полно выявить все имеющиеся ограничения целостности и задать их в базе данных.
Целостность БД не гарантирует достоверности содержащейся в ней информации, но обеспечивает по крайней мере правдоподобность этой информации, отвергая заведомо невероятные, невозможные значения. Таким образом, не следует путать целостность БД с достоверностью БД. Достоверность (или истинность) есть соответствие фактов, хранящихся в базе данных, реальному миру. Очевидно, что для определения достоверности БД требуется обладание полными знаниями как о содержимом БД, так и о реальном мире. Для определения целостности БД требуется лишь обладание знаниями о содержимом БД и о заданных для неё правилах. Поэтому СУБД может (и должна) контролировать целостность БД, но принципиально не в состоянии контролировать достоверность БД. Контроль достоверности БД может быть возложен только на человека, да и то в ограниченных масштабах, поскольку в ряде случаев люди тоже не обладают полнотой знаний о реальном мире.
Итак, БД может быть целостной, но не достоверной. Возможно и обратное: БД может быть достоверной, но не целостной. Последнее имеет место, если правила (ограничения целостности) заданы неверно.
10
Реляционная модель предложена сотрудником компании IBM Е.Ф.Коддом в 1970 г. (русский перевод статьи, в которой она впервые описана опубликован в журнале "СУБД" N 1 за 1995 г.). В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.