Введение в базы данных. Реляционное проектирование

Введение в базы данных.
Реляционное проектирование
Затрагиваемые темы
Проблемы, решаемые хранением данных в СУБД
 Виды знаний по БД в контексте IT-процессов
 Реляционные таблицы, ключи, внешние ключи
 Ссылочная целостность. Связи 1:N и M:N
 Диаграммное представление структуры БД, CASE
 «Рецепты» качественного проектирования РБД

Введение: Проблемы хранения данных

Особенности информационных систем





Проблемы хранения данных в файлах




Много пользователей, работающих одновременно
Большой объем данных – нельзя все загрузить в ОЗУ
Данные разнородны и имеют много разнообразных связей
Одни данные имеют различные представления userам
Дублирование, самосогласованное изменение
Низкая скорость доступа к данным (поиск, изменение)
Сложность программирования: нужно помнить, что где
Возможности систем управления базами данных






Разделение логической и физической структуры данных
Унифицированые интерфейсы доступа (языки, протоколы)
Хранение без дублирования + логическая целостность БД
Оптимизация скорости (буферизация, индексирование)
Многопользовательская работа: транзакции, привилегии..
Журнализация изменений и восстановление после сбоев
Введение: процесс разработки

Место знаний по БД в процессе разработки ИС

Анализ бизнес-процессов, отн. к ИС. Бизнес-требования
Формулировка технических требований //+словарь терминов

Анализ и проектирование


Разработка архитектуры //нужно знать возможности выбр. СУБД
Проектирование БД (модель лог.уровня, поведение БД) //важно

Проектирование приложений (структура модулей, UI, etc.)




Реализация //программисты пишут SQL, знают оптимизацию SQL
Документирование, верификация, внедрение, поддержка..
//администраторы выполняют SQL-скрипты, внедренцы анализируют
возникающие проблемы на SQL, support включает SQL-патчи и т.д.
Уровни моделей данных



Концептуальный (семантический, etc.) //обсуждаем с userами
Логический //зависит от подхода к проектированию = типа СУБД
Физический //зависит от СУБД, часто касается администраторов БД
Понятия реляционных моделей

Сущность (Entity) – таблица – отношение //класс



Экз. сущности – строка – кортеж //объект
Сущность – схема (заголовок) табл. – схема отнош.
Атрибут (Attribute) – столбец – атрибут //поле
Свойства атрибута: обязательность, вид (простой,
сущность, множество простых, множество сущностей)
 В реляционной модели вид только простой; атрибут имеет
тип и домен = {тип, ограничения на значение атрибута}
 Ключ – [min набор] атрибут[ов], по значению которого
можно однозначно найти нужный экземпляр сущности.
В РБД 1 из ключей и называется первичным (на практике

состоит из 1 атрибута, называют идентификатором)

Связь (Relationship) – внешний ключ (foreign key)


Виды связей: 1 ко многим, 1 к одному, многие ко многим
Свойства связей: required, identifying; ref. integrity actions
Реляционная таблица
Реляционная модель

Структурная часть, свойства реляционной таблицы
РБД представляет собой набор таблиц, таких, что:
 Ячейки столбца содержат однотипные данные (домен)
 Знач. в ячейках атомарны (простой тип, не множество)
 Столбцы поименованы, столбцы и строки неупорядочены //на практике столбцы упорядочены (performance!)


Целостностная часть реляционной модели



Целостность сущности: существует ключ
Ссылочная целостность (referential integrity):
 строка в parent: её ID = внешний ключ в child (если он не null)
Пользовательские ограничения целостности (CHECK):
логические условия на значения 1 или нескольких атрибутов


Целостность обеспечивается СУБД (запрет
вставки/изменения, каскадное удаление, обnullение, ..)
Манипуляционная часть = набор операций (SQL)
Диаграммное представление модели
Концептуальная модель
(сущности, связи)
Реляционная модель
(таблицы, ключи, типы данных)
Пример структуры РБД на одной из распространенных
нотаций типа Entity-Relationship – IDEF1X
(нарисовано в CASE-средстве ERwin)
Реляционное проектирование

Простейшие «рецепты» реляц. проектирования





Доп. неизменяемый атрибут - PK (<tablename>_ID int)
Связи 1:1 и 1:N – внешний ключ, N:M – доп. таблица
Атрибуты с фикс. числом значений => отд. таблица +FK
НФ: меньше зависимостей в таблице, больше таблиц
Основные причины отхода от реляционной модели
Ограничения модели: атомарность, замена атрибутовобъектов вн. ключом, нет наследования таблиц, типов
 Несоответствие таблиц ОО языкам программирования


CASE-средства //например, ERwin (проектирование РБД)


Диаграммы для задач анализа, проектирования и др.
Связь с реализацией: forward & reverse engineering