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

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

3. Физическое проектирование. Предполагает определение способов и мест размещения базы данных, оценку ее объема и других параметров.

Этапы проектирования БД

алгебры.
Первая работа по реляционной модели данных «A Relational Model of Data for Large Shared Data Banks» была опубликована в 1970 г.
Её автор - Эдгар Франк Кодд. В своей статье Э. Кодд вывел несколько правил, или форм, по упорядочиванию данных и их отношений.
Нормализация БД - это проектирование базы данных так, чтобы она была компактной и не несла логическую избыточность. Существует несколько разновидностей нормализации, так называемые нормальные формы. Все они идут в порядке усложнения от простого.
Каждой нормальной форме соответствует некоторый определенный набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
Всего существует 6 нормальных форм. На практике редко нормализуют выше 3-ей нормальной формы.

Реляционные базы данных.
Нормализация БД

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

Ключи

Первичный ключ таблицы «Маршруты»

Первичный ключ таблицы «Маршрут-остановка»

Внешний ключ

в другой. Степень связи бывает 3-х видов:
один-к-одному
один-ко-многим
многие-к-многим.

Степень связи

1) Связь «один-к-одному». Такая связь означает, что каждому значению реквизита А соответствует одно и только одно значение связанного с ним реквизита В, и наоборот.

2) Связь «один-ко-многим». Эта связь означает, что каждому значению реквизита А соответствует ноль, одно или несколько значений связанного с ним реквизита В, а каждому значению реквизита В соответствует одно и только одно значение реквизита А.

3) Связь «многие-ко-многим». Такая связь означает, что каждому значению реквизита А соответствует несколько значений связанного с ним реквизита В, и наоборот. Например, турагентство может работать с несколькими туроператорами, а туроператор обычно имеет разветвленную сеть турагентств.

ее атрибут атомарен.
Атрибут атомарен тогда, когда его значение теряет смысл при перестановке любой из его частей или при любом разбиении его на части. То есть, одно поле - одно значение.

Пример таблицы, которая не атомарна, а значит и не отвечает правилам первой нормальной формы:

Первая нормальная форма (1NF)

формы:

Правила 1NF

1. Если у нескольких товаров одинаковая цена, то для каждого товара должна быть отдельная запись (строка в таблице).
2. Если товар может храниться на нескольких складах, то для каждого склада должна быть отдельная запись.
3. Стоимость товара – это число. Записывать его с пробелом в качестве разделения числового разряда не правильно.

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

Вторая нормальная форма (2NF)

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

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

Правила 2NF

находится во второй нормальной форме и отсутствуют транзитивные зависимости не ключевых объектов от ключевых.
Транзитивная зависимость - это очевидная зависимость между полями. Если поле А равно х, то поле Б обязательно будет равно y. А если поле Б равно z, то тогда поле С будет равно m. Такой зависимости между объектами быть не должно.

Третья нормальная форма (3NF)

На рис. показано наличие транзитивной зависимости - это поля "Город" и "Индекс". Если индекс равен 650023, то мы уже знаем, что это город Кемерово (других городов с таким индексом нет). От такой транзитивной зависимости необходимо избавляться путем разбиения таблицы.

отвечает правилам третьей нормальной формы.
Примечание: В таблице "Индексы" в качестве первичного ключа используется не ID (суррогатный ключ, генерируемый СУБД), а номер индекса, так как он уникален, не может повторяться и не изменяется с течением времени.

Третья нормальная форма (3NF)

Склады

Индекс

Город

и Р
АТП
Университет
Реестр транспортных средств

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

Вариант 1

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

информация о которых должна находиться в базе данных:
фамилия исполнителя, дата рождения исполнителя, год создания группы, адрес исполнителя, E-mail исполнителя, сот. телефон исполнителя, сайт группы, название группы, руководитель группы, название альбома, дата выпуска альбома, название композиций, номер композиции в альбоме по порядку, жанр композиции, фотография исполнителя, фотография обложки альбома, цена альбома, год вступления в группу.
Построить логическую модель базы данных.