Создание базы данных

Создаем базу данных

Управление базами данных как объектами

Будем считать, что наша небольшая экскурсия по запросам и командам SQL со стороны «торгового зала» завершена. Заглянем теперь в его «служебные помещения» и познакомимся с тем, как создается сама база данных. Эта часть языка SQL не столь стандартизирована и сильно отличается в различных реализациях. Поэтому в дальнейших примерах я буду придерживаться синтаксиса, принятого в самой популярной на веб-серверах системе — MySQL.

MySQL — продукт шведской компании MySQL AB. Ее основатели — Дэвид Аксмарк, Аллан Ларсон и Майкл Видениус (последний больше известен по прозвищу — Монти). По одной из версий, первая часть названия продукта (My) — не что иное, как англизированная запись имени дочери М. Видениуса. Однако точно за происхождение названия сегодня не могут поручиться даже отцы-создатели. Существует версия, по которой «my» — это префикс, с которого начинались названия рабочих каталогов на их компьютерах.

Из всех команд чаще всего нам будут нужны три: CREATE (создать), ALTER (изменить) и DROP (уничтожить).

Чтобы создать новую базу данных с названием, ну скажем, OUR_SHOP, следует выполнить команду:

Еще лучше сразу при ее создании установить нужную кодировку (ведь по умолчанию в MySQL используется latin1). В итоге команда будет выглядеть так.

Если вы забыли сделать это сразу, не беда. Для того и существуют команды по изменению:

Когда, наигравшись вдоволь с пробной базой данных, вы захотите ее уничтожить, воспользуйтесь командой:

Управление таблицами

Чтобы создать таблицу GOODS, на которой мы отрабатывали манипуляции с данными, потребуется составить команду примерно такого вида:

Разберем эту команду подробнее. Тип INT устанавливается для столбцов с целочисленными данными, тип VARCHAR(100) обеспечивает хранение строк с длиной не более 100 символов, DECIMAL(10,2) соответствует действительным числам с не более чем десятью знаками и точностью в два знака после запятой.

Столбец ID объявлен первичным ключом (PRIMARY KEY).

Ключевое слово AUTO_INCREMENT означает, что при добавлении новых строк с неуказанным значением ID оно будет автоматически заполняться следующим значением. Это удобно, поскольку обычно нет нужды вручную указывать значения первичных ключей, а за тем, чтобы они были уникальными, пусть лучше следит база данных.

NOT NULL означает запрет на пустые значения в столбце, иными словами, гарантирует обязательность заполнения.

Команда DEFAULT задает значение по умолчанию — то, которое будет записываться в базу при добавлении новой строки, если не указано иное. В нашем случае она обеспечивает автоматическое объявление товара штучным (код = 1) в случае, если при добавлении новых строк не будет указан другой код.

Признак UNIQUE обеспечивает уникальность значений в колонке (в нашем случае — уникальность названий товаров).

Если в будущем вы захотите перенастроить объявленные командой CREATE столбцы таблицы, сделать это можно командой ALTER. Например, таблицу GOODS можно нарастить строчной колонкой REMARK (подкоманда ADD):

Поработав с ней немного и убедившись, что 50 символов для примечания явно недостаточно, увеличиваем максимальный размер строки до 250 (блок CHANGE):

Так как имя столбца мы не изменяли (новое совпадает со старым), то его просто повторяем в этой команде (как бы меняем само на себя).

И наконец, убедившись через какое-то время, что без примечания в товарном справочнике вполне можно обойтись, мы удаляем ставшую ненужной колонку (блок DROP):

Удалить таблицу целиком можно командой DROP:

Стоит ли говорить о том, что пользоваться командами с этим ключевым словом следует с особой осторожностью?

Этапы создания базы данных

Надлежащим образом структурированная база данных:

• Помогает сэкономить дисковое пространство за счет исключения лишних данных;
• Поддерживает точность и целостность данных;
• Обеспечивает удобный доступ к данным.

Основные этапы разработки базы данных:

1. Анализ требований или определение цели базы данных;
2. Организация данных в таблицах;
3. Указание первичных ключей и анализ связей;
4. Нормализация таблиц.

Рассмотрим каждый этап проектирования баз данных подробнее

Обратите внимание, что в этом руководстве рассматривается реляционная модель базы данных Эдгара Кодда, написанная на языке SQL (а не иерархическая, сетевая или объектная модели)

Изменение данных с помощью SQL запросов в MS Access

Запрос на добавление данных в таблицу Залы:INSERT INTO Залы ( , Наименование, , Площадь )VALUES (6, «Серебряный», 1, 145);

Запрос на удаление данных из таблицы Сотрудники Удалим записи с фамилией сотрудника, содержащей « Мечникова»:

DELETE ФИОFROM СотрудникиWHERE ФИО LIKE “Мечникова”;

Запрос на обновление данных. В таблице Издания увеличим стоимость объявлений изданий с кодами 1711 и 1712.

UPDATE Сотрудники SET Оклад = Оклад*1.2WHERE (Сотрудники.Должность Like «*контроллер»);

Запрос на создание таблицы Расписание:

SELECT Экскурсии., Экскурсии.График, Сотрудники.ФИО INTO РасписаниеFROM Сотрудники INNER JOIN Экскурсии ON Сотрудники. = Экскурсии.;

Использование среды SQL Server Management StudioUsing SQL Server Management Studio

Создание первичного ключаTo create a primary key

1. В обозревателе объектов щелкните правой кнопкой мыши таблицу, в которую необходимо добавить ограничение уникальности, и выберите Конструктор.In Object Explorer, right-click the table to which you want to add a unique constraint, and click Design.
2. В Конструкторе таблиц щелкните селектор строк для столбца базы данных, который необходимо определить в качестве первичного ключа.In Table Designer, click the row selector for the database column you want to define as the primary key. Чтобы выделить несколько столбцов, нажмите и удерживайте клавишу CTRL и щелкните селекторы строк для остальных столбцов.If you want to select multiple columns, hold down the CTRL key while you click the row selectors for the other columns.
3. Щелкните правой кнопкой мыши средство выбора строк столбца и выберите команду Задать первичный ключ.Right-click the row selector for the column and select Set Primary Key.

Внимание!

Чтобы переопределить первичный ключ, необходимо удалить все связи с существующим первичным ключом и только после этого создавать новый первичный ключ.If you want to redefine the primary key, any relationships to the existing primary key must be deleted before the new primary key can be created. Появится сообщение, предупреждающее об автоматическом удалении в ходе процесса всех существующих связей.A message will warn you that existing relationships will be automatically deleted as part of this process.

Ключевой столбец-источник идентифицируется символом первичного ключа в соответствующем селекторе строк.A primary key column is identified by a primary key symbol in its row selector.

Если первичный ключ состоит более чем из одного столбца, то в одном столбце могут встречаться дублирующиеся значения, но все сочетания значений изо всех столбцов первичного ключа должны быть уникальными.If a primary key consists of more than one column, duplicate values are allowed in one column, but each combination of values from all the columns in the primary key must be unique.

При определении составного ключа порядок столбцов в первичном ключе совпадает с порядком столбцов, показанным в таблице.If you define a compound key, the order of columns in the primary key matches the order of columns as shown in the table. Однако после создания первичного ключа порядок столбцов можно изменить.However, you can change the order of columns after the primary key is created. Дополнительные сведения см. в разделе Изменение первичных ключей.For more information, see Modify Primary Keys.

Определение ключей и создание связей схемы связей.

Определим первичные и внешние ключи в таблицах и необходимые связи между атрибутами таблиц для обеспечения целостности БД.В 1-ой таблице первичный ключ — Код экспоната. Атрибут Код зала является внешним ключом к таблице 2. Во 2-ой таблице первичный ключ- Код зала. Атрибут Код ответственного является внешним ключом по отношению к таблице 3. В 3-ей таблице первичный ключ- Код сотрудника. В 4-ой таблице первичный ключ — Код экскурсии, атрибут Код ответственного является внешним ключом по отношению к таблице 3.Создадим схему связей между атрибутами таблиц для обеспечения целостности БД.

Создание простого запроса

Откроем базу данных STUD, как было рассмотрено в ЛР1. Создадим запрос, выводящий информацию о студентах, у которых имеются задолженности.

Для создания запроса активизируем окно базы данных (см. ЛР1). После этого щелкнем по корешку «Запрос» и кнопке «Создать». В появившемся диалоговом окне «Создание запроса» выберите кнопку «Конструктор». Access откроет диалоговое окно «Добавление таблицы», позволяющее выбрать базовые таблицы и запросы для создаваемого запроса. Выберите таблицы «Результаты» и «Cтуденты», нажимая кнопку «Добавить», после чего закройте это окно кнопкой «Закрыть».

Открывшееся окно конструктора запросов состоит из двух частей: верхняя содержит списки полей выбранных таблиц, а нижняя — бланк QBE для создания запроса. Каждый столбец бланка описывает одно поле, участвующее в запросе.

Включение поля в запрос производится перетаскиванием его из списка полей таблиц (расположенного в верхней части экрана) в нужный столбец бланка QBE при помощи мышки. Включение всех полей таблицы происходит перетаскиванием символа «*», находящегося вверху списка полей данной таблицы в верхней части экрана. Включите в запрос поля таблицы «Результаты»:

перетащив их в бланк QBE . Рассмотренным выше методом перетащите из таблицы “Студенты” поле Фамилия.

Запрос “Задолженность” будет иметь вид, как показано на рисунке. Установка связей между таблицами производится автоматически, используя структуру связей, созданную при генерации проекта БД. Можно задавать другие варианты связи таблиц и иные типы связей (внешнее объединение, «один-к-одному», «один-ко-многим» и т.д.). Изменение связей производится в верхней части окна выбором связанного поля в описании одной таблицы и транспортировкой его при нажатой кнопке мышки на описание соответствующего поля связанной таблицы. Тип связи можно изменить, активизировав ее щелчком мышки на линии связи.

Условие для отбора нужных нам полей производится включением этого условия для данного поля в строке QBE «Условие отбора». Несколько значений отбора вводятся в одну строку, разделенные логическими условиями AND или OR, либо вводятся в последующие ячейки строки «или». Установим для таблицы «Результаты» условие отбора студентов, у которых задолженности, для чего в столбец описания поля внесем строку «Задолженность» из таблицы «Результаты», и в строке «Условие отбора» введем: Да

Сбросим для этого поля флажок «Показать», запрещающий вывод данного поля в выборке (т.к его не обязательно выводить). Кроме стандартных операторов сравнения ‘=’, ‘ ‘, ‘ =’, Access поддерживает также BEETWEN, IN, LIKE. В запросе могут присутствовать т.н. вычисляемые поля — вычисленные значения над любыми полями таблицы. Access поддерживает большое число функций и операторов, применяемых при генерации вычисляемых полей. Чтобы просмотреть результат запроса необходимо на панели нажать кнопку:

Изменить заголовок можно также активизировав столбец с описанием поля; а затем выполнив команду «Свойства» меню «Вид», ввести в строку «Подпись поля» его название.

Строки итоговой таблицы желательно отсортировать по полю «Фамилия» таблицы «Студенты». Для этого в столбце с описанием данного поля в строке «Сортировка» выберем пункт «по возрастанию». При необходимости сортировки по нескольким полям Access сортирует данные в порядке их расположения в бланке QBE. После просмотра запроса видно, что необходимо ввести поле Имя из таблицы “Студенты”, т.к фамилии повторяютя и запрос не несет необходимой информации. Чтобы вставить поле, перетяните его в сетку QBE на место, где он должен находится и все остальные поля передвинуться на одну позицию в право. Запустить полученный запрос на выполнение можно также командой «Выполнить» меню «Запрос». Проверим полученные результаты на соответствие критериям отбора. Сохраним полученный запрос под именем «Задолженности». Запрос представляет собой таблицу:

Создадим запрос, в котором будет вычисляться дополнительное поле. Кафедра вычислительной техники решила своим работникам к новому году выплатить премию в размере 10% от зарплаты. Создадим запрос на базе таблицы “Преподаватели”, с полями Фамилия, Кафедра, Должность, Зарплата. Чтобы создать вычисляемое поле “Премия”, выводящее информацию о величине премии работнику, в новом столбце (следующим за заполненным), в строке “Поле” введем выражение Зарплата*0,1. Изменим заголовок поля, введя перед выражение его название. Ячейка будет содержать: «Премия: *0,1».

Изменить заголовок можно также активизировав столбец с описанием поля, а затем выполнив команду «Свойства» меню «Вид», ввести в строку подпись поля его название. Введите в строку «условие отбора» для кафедры «Вычислительная техника».

Отчеты Microsoft Access

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

Microsoft Access предоставляет для применения несколько типов отчетов:

• Отчет – аксесс создаст автоматически отчет, собрав всю имеющуюся информацию;
• Пустой отчет – чистая форма, для заполнения которой вам нужно будет выбрать одно из необходимых для заполнения полей;
• Мастер отчетов – удобный инструмент для создания отчетов и форматирования полученных материалов.

Преимуществом пустого отчета является то, что пользователь самостоятельно имеет возможность добавить, удалить и настроить поля, а также заполнить их так, как будет удобно.

Об авторе

Павел Угрюмов

Основатель и главный редактор компьютерного журнала PClegko. Маркетолог, предприниматель и и путешественник. Проект интернет-журнал PClegko — моё хобби. Но я планирую вырастить его в мировой проект. Каждая ваша оценка статьи и оставленный комментарий очень важны для меня. Если проект вам нравится, то буду рад если вы меня поддержите:) В ссылке находится мой основной проект. Буду рад, если загляните!

Правила целостности данных

Также с помощью средств проектирования баз данных необходимо настроить БД с учетом возможности проверки данных на соответствие определенным правилам. Многие СУБД, такие как Microsoft Access, автоматически применяют некоторые из этих правил.

Правило целостности гласит, что первичный ключ никогда не может быть равен NULL. Если ключ состоит из нескольких столбцов, ни один из них не может быть равен NULL. В противном случае он может неоднозначно идентифицировать запись.

Правило целостности ссылок требует, чтобы каждый внешний ключ, указанный в одной таблице, сопоставлялся с одним первичным ключом в таблице, на которую он ссылается. Если первичный ключ изменяется или удаляется, эти изменения необходимо реализовать во всех объектах, на которые ссылается этот ключ в базе данных.

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

Как хранится информация в БД

В основе всей структуры хранения лежат три понятия:

• База данных;
• Таблица;
• Запись.

База данных

База данных — это высокоуровневное понятие, которое означает объединение совокупности данных, хранимых для выполнения одной цели.
Если мы делаем современный сайт, то все его данные будут храниться внутри одной базы данных. Для сайта онлайн-дневника наблюдений за погодой тоже понадобится создать отдельную базу данных.

Таблица

По отношению к базе данных таблица является вложенным объеком. То есть одна БД может содержать в себе множество таблиц.
Аналогией из реального мира может быть шкаф (база данных) внутри которого лежит множество коробок (таблиц).
Таблицы нужны для хранения данных одного типа, например, списка городов, пользователей сайта, или библиотечного каталога.
Таблицу можно представить как обычный лист в Excel-таблице, то есть совокупность строк и столбцов.
Наверняка каждый хоть раз имел дело с электронными таблицами (MS Excel).
Заполняя такую таблицу, пользователь определяет столбцы, у каждого из которых есть заголовок. В строках хранится информация.
В БД точно также: создавая новую таблицу, необходимо описать, из каких столбцов она состоит, и дать им имена.

Запись

Запись — это строка электронной таблицы.
Это неделимая сущность, которая хранится в таблице. Когда мы сохраняем данные веб-формы с сайта, то на самом деле добавляем новую запись в какую-то из таблиц базы данных. Запись состоит из полей (столбцов) и их значений. Но значения не могут быть какими угодно.
Определяя столбец, программист должен указать тип данных, который будет храниться в этом столбце: текстовый, числовой, логический, файловый и т.д. Это нужно для того, чтобы в будущем в базу не были записаны данные неверного типа.

Соберем всё вместе, чтобы понять, как будет выглядеть ведение дневника погоды при участии базы данных.

1. Создадим для сайта новую БД и дадим ей название «weather_diary».
2. Создадим в БД новую таблицу с именем «weather_log» и определим там следующие столбцы:
   • Город (тип: текст);
   • День (тип: дата);
   • Температура (тип: число);
   • Облачность (тип: число; от 0 (нет облачности) до 4 (полная облачность));
   • Были ли осадки (тип: истина или ложь);
   • Комментарий (тип: текст).
3. При сохранении формы будем добавлять в таблицу weather_log новую запись, и заполнять в ней все поля информацией из полей формы.

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

Реляционная база данных

Английское слово „relation“ можно перевести как связь, отношение.
А определение «реляционные базы данных» означает, что таблицы в этой БД могут вступать в отношения и находиться в связи между собой.
Что это за связи?
Например, одна таблица может ссылаться на другую таблицу. Это часто требуется, чтобы сократить объём и избежать дублирования информации.
В сценарии с дневником погоды пользователь вводит название своего города. Это название сохраняется вместе с погодными данными.
Но можно поступить иначе:

1. Создать новую таблицу с именем „cities“.
2. Все города в России известны, поэтому их все можно добавить в одну таблицу.
3. Переделать форму, изменив поле ввода города с текстового на поле типа «select», чтобы пользователь не вписывал город, а выбирал его из списка.
4. При сохранении погодной записи, в поле для города поставить ссылку на соответствующую запись из таблицы городов.

Так мы решим сразу две задачи:

• Сократим объём хранимой информации, так как погодные записи больше не будут содержать название города;
• Избежим дублирования: все пользователи будут выбирать один из заранее определённых городов, что исключит опечатки.

Связи между таблицами в БД бывают разных видов.
В примере выше использовалась связь типа «один-ко-многим», так как одному городу может соответствовать множество погодных записей, но не наоборот!
Бывают связи и других типов: «один-к-одному» и «многие-ко-многим», но они используются значительно реже.

Нормализация базы данных

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

В то же время не все базы данных необходимо нормализовать. В целом, базы с обработкой транзакций в реальном времени (OLTP), должны быть нормализованы.

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

Первая форма нормализации

Первая форма нормализации (сокращенно 1NF) гласит, что во время логического проектирования базы данных каждая ячейка в таблице может иметь только одно значение, а не список значений. Поэтому таблица, подобная той, которая приведена ниже, не соответствует 1NF:

1NF

Реквизиты продажПродажи1:MРеквизитами продаж

Вторая форма нормализации

Вторая форма нормализации (2NF) предусматривает, что каждый из атрибутов должен полностью зависеть от первичного ключа. Каждый атрибут должен напрямую зависеть от всего первичного ключа, а не косвенно через другой атрибут.

Например, атрибут «возраст» зависит от «дня рождения», который, в свою очередь, зависит от «ID студента», имеет частичную функциональную зависимость. Таблица, содержащая эти атрибуты, не будет соответствовать второй форме нормализации.

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

Таким образом, таблица с этими полями не будет соответствовать второй форме нормализации, поскольку атрибут «название товара» зависит от идентификатора продукта, но не от номера заказа:

• Номер заказа (первичный ключ);
• ID товара (первичный ключ);
• Название товара.

Третья форма нормализации

Третья форма нормализации (3NF): каждый не ключевой столбец должен быть независим от любого другого столбца. Если при проектировании реляционной базы данных изменение значения в одном не ключевом столбце вызывает изменение другого значения, эта таблица не соответствует третьей форме нормализации.

В соответствии с 3NF, нельзя хранить в таблице любые производные данные, такие как столбец «Налог», который в приведенном ниже примере, напрямую зависит от общей стоимости заказа:

Бойса-Кодда

Многомерные данные

Некоторым пользователям может потребоваться доступ к нескольким разрезам одного типа данных, особенно в базах данных OLAP. Например, им может потребоваться узнать продажи по клиенту, стране и месяцу. В этой ситуации лучше создать центральную таблицу, на которую могут ссылаться таблицы клиентов, стран и месяцев. Например:

Проектирование базы данных

   Основой любой реляционной БД являются
таблицы. Разработка таблиц яв­ляется одним из наиболее сложных этапов в
проектировании БД. Грамотно спро­ектированные таблицы являются основой для
создания работоспособной и эффек­тивной БД.

   Понятие таблицы в Access полностью соответствует аналогичному
понятию реляционной модели данных. Любая таблица реляционной БД состоит из строк
(называемых также записями) и столбцов (называемых
также полями).

  Строки таблицы содержат сведения об
однотипных объектах — документах, людях, предметах. На пересечении столбца и
строки находится конкретное значе­ние, характеризующее объект.

   Можно сформулировать ряд основных
требований, которым должны удов­летворять таблицы.

    1. Информация в таблице не должна
дублироваться, т.е. в таблице не должно существовать двух записей с полностью
совпадающим набором значений ее по­лей.

    2. На пересечении любого столбца и
любой строки должно находиться одно

значение.

    3.  Не рекомендуется включать в
таблицу данные, которые являются резуль­татом вычислений.

    4.  Значения данных в одном и том же
столбце должны принадлежать к од­ному и тому же типу, доступному для
использования в данной СУБД.

    5. Каждое поле должно иметь уникальное
имя.

    6. Каждая таблица должна иметь
первичный ключ.

    7. Таблицы БД должны быть связаны
через внешние ключи.

  Каждая таблица должна содержать поле
(или набор из нескольких полей), значения в котором однозначно идентифицируют
каждую запись в таблице. Такое поле (или набор полей) называется ключевым полем
таблицы или первичным ключом. Первичный ключ любой таблицы обязан
содержать уникальные непус­тые значения для каждой записи. Если
для таблицы обозначены ключевые поля, то Access предотвращает дублирование или ввод пустых значений в ключевое по­ле.

   В Access можно выделить три типа ключевых полей: простой ключ, состав­ной
ключ и поле счетчика.

   Если поле содержит уникальные значения,
такие как коды или инвентарные номера, то это поле можно определить как простой
первичный ключ. Если в этом поле появятся повторяющиеся или пустые
значения, Access выведет сообщение об ошибке.

   В случаях, когда невозможно
гарантировать уникальность значений ни од­ного из полей, можно создать ключ,
состоящий из нескольких полей — составной первичный ключ. Для
составного ключа существенным может оказаться порядок образующих ключ полей. Не
рекомендуется определять ключ по полям Имена и Фамилии, поскольку нельзя исключить
повторения этой пары значений для раз­ных людей.

   Составной ключ необходим для таблицы,
используемой для связывания двух таблиц в отношении «многие — ко — многим»
Обычно такой ключ состоит из ключевых полей связываемых таблиц.

   Если для какой-либо таблицы не удалось
определить простой первичный ключ или найти подходящий набор полей для
составного ключа, можно добавить в таблицу поле счетчика и
сделать его ключевым. При создании каждой новой за­писи Access генерирует уникальный номер записи,
называемый счетчиком. Ука­зание такого поля в качестве ключевого
является наиболее простым способом соз­дания ключевых полей.

   Если до сохранения созданной таблицы
ключевые поля не были определены, то при сохранении будет выдано предложение о
создании системой ключевого по­ля. При ответе Да будет создано ключевое
поле счетчика.

   Сила реляционных баз данных, таких как
БД Microsoft Access, заключается в том, что они могут быстро найти и связать данные
из разных таблиц при помощи запросов, форм и отчетов. Таблицы реляционных БД
связываются через одинако­вые значения одноименных полей, содержащихся в
связываемых таблицах. Такие поля называются внешним ключом для
этих таблиц. Все таблицы БД Access должны
быть связаны с помощью внешних ключей.

Создание связей между сущностями

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

Каждый объект может быть взаимосвязан с другим с помощью одного из трех типов связи:

Связь «один-к одному»

Когда существует только один экземпляр объекта A для каждого экземпляра объекта B, говорят, что между ними существует связь «один-к одному» (часто обозначается 1:1). Можно указать этот тип связи в ER-диаграмме линией с тире на каждом конце:

1:1

Но при определенных обстоятельствах целесообразнее создавать таблицы со связями 1:1. Если есть поле с необязательными данными, например «описание», которое не заполнено для многих записей, можно переместить все описания в отдельную таблицу, исключая пустые поля и улучшая производительность базы данных.

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

Связь «один-ко-многим»

Эта связи возникают, когда запись в одной таблице связана с несколькими записями в другой. Например, один клиент мог разместить много заказов, или у читателя может быть сразу несколько книг, взятых в библиотеке. Связи «один- ко-многим» (1:M) обозначаются так называемой «меткой ноги вороны», как в этом примере:

1:Mодной1

Связь «многие-ко-многим»

Когда несколько объектов таблицы могут быть связаны с несколькими объектами другой. Говорят, что они имеют связь «многие-ко-многим» (M:N). Например, в случае студентов и курсов, поскольку студент может посещать много курсов, и каждый курс могут посещать много студентов.

На ER-диаграмме эти связи отображаются с помощью следующих строк:

один-ко-многим

Для этого нужно создать между этими двумя таблицами новую сущность. Если между продажами и продуктами существует связь M:N, можно назвать этот новый объект «sold_products», так как он будет содержать данные для каждой продажи. И таблица продаж, и таблица товаров будут иметь связь 1:M с sold_products. Этот вид промежуточного объекта в различных моделях называется таблицей ссылок, ассоциативным объектом или таблицей связей.

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

Обязательно или нет?

Другим способом анализа связей является рассмотрение того, какая сторона связи должна существовать, чтобы существовала другая. Необязательная сторона может быть отмечена кружком на линии. Например, страна должна существовать для того, чтобы иметь представителя в Организации Объединенных Наций, а не наоборот:

один не может существовать без другого

Рекурсивные связи

Иногда при проектировании базы данных таблица указывает на себя саму. Например, таблица сотрудников может иметь атрибут «руководитель», который ссылается на другое лицо в этой же таблице. Это называется рекурсивными связями.

Лишние связи

Лишние связи — это те, которые выражены более одного раза

Как правило, можно удалить одну из таких связей без потери какой-либо важной информации. Например, если объект «ученики» имеет прямую связь с другим объектом, называемым «учителя», но также имеет косвенные отношения с учителями через «предметы», нужно удалить связь между «учениками» и «учителями»

Так как единственный способ, которым ученикам назначают учителей — это предметы.

Создание резервной копии и восстановление из бэкапа

Для создания резервной копии базы данных используется сложная команда:

pg_dump -h хост -U имя_роли -F формат_дампа -f путь_к_дампу имя_БД

Чтобы было проще разобраться, рассмотрим каждый параметр:

• хост – сервер, на котором располагается БД. Например, можно указать localhost, домен, IP-адрес.
• имя_роли – имя пользователя PostgreSQL, под которым мы работаем с базой данных.
• формат_дампа – формат, в котором дамп сохранится на сервере. Доступны следующие форматы: c (custom) – архив .tar.gz, t (tar) – архив .tar, p (plain) – текст без сжатия, обычно .sql.
• путь_к_дампу – путь, по которому будет сохранена резервная копия.
• имя_БД – название БД, для которой будет создана резервная копия.

Выглядит это примерно так:

pg_dump -h localhost -U mybase -F c -f /home/user/backups/dump.tar.gz mybase

Для выполнения этой команды нужно ввести пароль, который используется при входе в psql от имени указанной роли (mybase в приведенном примере).

Восстановление из резервной копии выполняется аналогичным образом: 

pg_restore -h хост -U имя_роли -F формат_дампа -d имя_базы путь_к_дампу

Параметры похожие, отличия минимальные

Важно знать хост, помнить формат и путь к бэкапу

Мы разобрались с основными действиями и настройками PostgreSQL. На этом все! 

Работа в MS Access 2010. Создание объектов базы данных

Прилагаются упражнения по практическому применению рассмотренных функций. Работа в MS Access. Создание объектов базы данных Запросы и отчеты к базе данных Контрольная работа

Просмотр содержимого документа «Работа в MS Access 2010. Создание объектов базы данных»

Упражнение 1. Работа в MS Access. Создание объектов базы данных.

Выберите шаблон Новая база данных. Введите имя файла Договор, укажите папку для размещения файла и нажмите кнопку создать.

В результате будет создана новая база данных с заданным именем, а в ней таблица с именем Таблица 1.

Перейдите в режим конструктора для описания структуры Таблицы 1. Для этого:

Щелкните на названии таблицы правой кнопкой мыши (Таблица 1), в появившемся выпадающем меню выберите пункт Конструктор.

В появившемся окнеСохранение введите новое название таблицы Страхование имущества и нажмите OK.

Опишите следующую структуру таблицы Страхование имущества:

Имя поля вводите с клавиатуры, нужный тип данных выбирайте из выпадающего меню. Поле Код клиента следует сделать ключевым, для этого щелкните правой кнопкой мыши на названии поля и в появившемся меню выберите пункт ключевое поле (напротив имени поля должно появиться изображение ключа).

Создайте и опишите структуру таблицы Наименование имущества:

Перейдите на закладку Создание, в группе Таблицы нажмите кнопку Таблица, в результате должна появиться новая таблица с именем Таблица 1.

Щелкните на названии таблицы правой кнопкой мыши (Таблица 1), в появившемся выпадающем меню выберите пункт Конструктор.

В появившемся окне Сохранение введите новое название таблицы Наименование имущества и нажмите OK.

Опишите следующую структуру таблицы Наименование имущества:

Установите связи в базе данных между таблицами Страхование имущества и Наименование имущества:

Предварительно закройте обе созданные таблицы, для этого щелкните правой кнопкой на соответствующем заголовке закладки (Страхование имущества затем Наименование имущества) и выберите пунктЗакрыть.

Выберите закладку Работа с базами данных, в группе Отношения нажмите Схема данных.

В появившемся окне Добавление таблиц курсором выделите обе таблицы (Страхование имущества и Наименование имущества), нажмите кнопку добавить и закройте окно Добавление таблиц.

Щелкните левой кнопкой мыши на названии поля Код клиента в таблице Наименование имущества и не отпуская ее переместите указатель мыши на поле Код клиента в таблице Страхование имущества.

В появившемся окне Изменение связей поставьте галочку напротив поля Обеспечение целостности данных и нажмите кнопку Создать (в результате будет установлено отношение между таблицами Один-ко-многим).

Закройте схему данных с сохранением( для этого щелкните правой кнопкой на заголовке закладки Схема данных).

Создайте экранную форму к таблице Наименование имущества:

Выделите левой кнопкой мыши название таблицы Наименование имущества.

На закладке Создание в группе Формы нажмите кнопку Форма(будет создана экранная форма для ввода данных в таблицу Наименование имущества, содержащая все поля этой таблицы)

Сохраните форму с именем Сведения о страховании, для этого нажмите Ctrl+S (или нажмите правой кнопкой на заголовке вкладки и из выпадающего меню выберите Сохранить) и в появившемся окне Сохранение в поле Имя формы введите новое имя формы.

Самостоятельно создайте форму для таблицы Страхование имущества и сохраните ее с именем Сведения об имуществе.

Введите данные в таблицу Страхование имущества в режиме формы:

Откройте форму Сведения об имуществе

Заполните поля следующими исходными данными: