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

Содержание проектирования баз данных и этапность

Замысел проектирования основывается на какой-либо сформулированной общественной потребности. У этой потребности есть среда её возникновения и целевая аудитория потребителей, которые будут пользоваться результатом проектирования. Следовательно, процесс проектирования баз данных начинается с изучения данной потребности с точки зрения потребителей и функциональной среды её предполагаемого размещения. То есть, первым этапом становится сбор информации и определение модели предметной области системы, а также – взгляда на неё с точки зрения целевой аудитории. В целом, для определения требований к системе производится определение диапазона действий, а также границ приложений БД.

Далее проектировщик, уже имеющий определённые представления о том, что ему нужно создать, уточняет предположительно решаемые приложением задачи, формирует их список (особенно, если в проектной разработке большая и сложная БД), уточняет последовательность решения задач и производит анализ данных. Такой процесс – тоже этапная проектная работа, но обычно в структуре проектирования эти шаги поглощаются этапом концептуального проектирования – этапом выделения объектов, атрибутов, связей.

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

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

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

Это обстоятельство определяет возникновение следующего этапа – появления обеспеченной средствами конкретной СУБД концептуальной модели. Данный шаг соответствует этапу логического проектирования (создания логической модели).

Наконец, финальным этапом проектирования БД становится физическое проектирование – этап увязки логической структуры и физической среды хранения.

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

• инфологического проектирования,
• формирования требований к операционной обстановке
• выбора системы управления и программных средств БД,
• логического проектирования,
• физического проектирования

Ключевые из них ниже будут рассмотрены подробнее.

2.4. Microsoft Access 2007

2.4.5. Создание запросов и поиск информации в базе данных

В СУБД Access 2007 можно создавать queries для отображения требуемых полей из записей одной или нескольких таблиц.

В СУБД Access 2007 применяются различные типы запросов: на выборку, на обновление, на добавление, на удаление, перекрестный query, выполнение вычислений, создание таблиц. Наиболее распространенным является query на выборку. Применяются два типа запросов: query по образцу (QBE) и query на основе структурированного языка запросов (SQL).

Запросы на выборку используются для отбора требуемой пользователю информации, содержащейся в нескольких таблицах. Они создаются только для связанных таблиц. Queries могут основываться как на нескольких таблицах, так и существующих запросах. СУБД Access 2007 включает такие средства создания запросов, как Мастер и Конструктор.

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

На скриншоте (рисунок 1) средства сортировки и фильтрации выделены скругленным прямоугольником красного цвета.

Рис. 1.

Рассмотрим создание запроса на выборку с помощью Конструктора

Для создания нового пустого запроса в режиме конструктора надо щелкнуть на пиктограмме Конструктор запросов (рисунок 2).

Рис. 2.

Откроется активное окно диалога Добавление таблицы (рисунок 3) на фоне неактивного окна «Запрос1». В этом окне можно выбрать таблицы и queries для создания новых запросов.

Рис. 3.

В окне Добавление таблицы следует выбрать несколько таблиц из представленного списка таблиц, на основе которых будет проводиться выбор данных, и щелкнуть на кнопке Добавить. После этого закрыть окно Добавление таблицы, а окно «Запрос1» станет активным (рисунок 4).

Рис. 4.

Окно Конструктора состоит из двух частей – верхней и нижней. В верхней части окна размещается схема данных запроса, которая содержит список связанных таблиц. В нижней части окна находится Бланк построения запроса QBE, в котором каждая строка выполняет определенную функцию.

Переместим имена полей с таблиц-источников в Бланк. Из таблицы Группы студентов переместим поле Название в первое поле Бланка, из таблицы Студенты переместим поле Фамилии во второе поле, а из таблицы Успеваемость переместим поле Оценка в третье поле и из таблицы Дисциплины переместим поле Название в четвертое поле Бланка запросов.

При необходимости можно задать принцип сортировки (по возрастанию или по убыванию) результатов запроса. В строке «Вывод на экран» автоматически устанавливается флажок просмотра информации.

Условия ограниченного поиска или критерий поиска информации вводится в строке «Условия» отбора и строке «Или». Например, введем критерий поиска — «5/A» в строке «Условия» для поля Оценка. В этом случае в результате выполнения запроса на экране будут отображаться все фамилии студентов, которые получили оценку 5/A (рисунок. 5).

Рис. 5.

Далее надо закрыть окно запроса Запрос1, появится окно диалога Сохранить, ответить — Да и ввести имя запроса, например «Успеваемость студентов». Для запуска запроса дважды щелкнем на query «Успеваемость студентов», откроется таблица с результатами выполненного запроса (рис. 6).

Рис. 6.

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

Закрыть окно запроса на выборку. На вопрос о сохранении изменения ответить — Да и ввести имя запроса, например «Параметрический query». Запустим Параметрический query, дважды щелкнув на нем. В открывшемся на экране окне диалога «Введите значение параметра» надо ввести фамилию студента, информацию об успеваемости которого необходимо получить (рис. 8).

Рис. 7.

Затем надо щелкнуть на кнопке ОК, откроется таблица с результатами выполненного запроса (рис. 8).

Рис. 8.

В некоторых случаях для создания запросов можно использовать Мастер запросов. После создания запросов на выборку информации из БД Access 2007 можно приступать к формированию форм.

Далее >>> Раздел: 2.4.6. Создание форм для ввода данных в таблицы базы данных Access 2007

Анализ предметной области

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

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

В каждой из аптек регистрируется покупка каждой единицы препарата и все покупки, совершённые одним клиентом в одной аптеки в один момент времени, прикрепляются к корзине покупок.

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

Требуемыми функциями системы, использующей базу данных, являются:

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

Основные элементы реляционных баз данных.

Одним
из основных типов баз данных является
реляционная – т.е. представление данных
в виде таблицы (практически все типы
баз данных можно представить в виде
таблицы)

В
любой таблице можно выделить такие
элементы как записи и поля.

Свойства
полей базы данных.

Поля
базы данных не просто определяют
структуру базы — они еще определяют
групповые свойства данных, записываемых
в ячейки, принадлежащие каждому из
полей. Ниже перечислены основные свойства
полей таблиц баз данных на примере СУБД
Microsoft Access.

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

Тип
поля — определяет тип данных, которые
могут содержаться в данном поле.

• Размер
поля — определяет предельную длину (в
символах) данных, которые могут размещаться
в данном поле.

• Формат
поля — определяет способ форматирования
данных в ячейках, принадлежащих полю.

• Маска
ввода — определяет форму, в которой
вводятся данные в поле (средство
автоматизации ввода данных).

• Подпись
— определяет заголовок столбца таблицы
для данного поля (если подпись не указана,
то в качестве заголовка столбца
используется свой-ство Имя поля).

• Значение
по умолчанию — то значение, которое
вводится в ячейки поля автоматически
(средство автоматизации ввода данных).

• Условие
на значение — ограничение, используемое
для проверки правильности ввода данных
(средство автоматизации ввода, которое
используется, как правило, для данных,
имеющих числовой тип, денежный тип или
тип даты).

• Сообщение
об ошибке — текстовое сообщение, которое
выдается автоматически при попытке
ввода в поле ошибочных данных (проверка
ошибочности выполняется автоматически,
если задано свойство Условие на значение).

• Обязательное
поле — свойство, определяющее
обязательность заполнения данного поля
при наполнении базы;

• Пустые
строки — свойство, разрешающее ввод
пустых строковых данных (от свойства
Обязательное поле отличается тем, что
относится не ко всем типам данных, а
лишь к некоторым, например к текстовым).

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

2.1. Этапы проектирования бд

Современные
информационные системы характеризуются
огромными объемами хранимых данных,
большой скоростью их обработки и
актуализации, высокой эффективностью
обработки запросов пользователей. В
широком смысле слова база данных – это
совокупность сведений о конкретных
объектах реального мира в какой-то
предметной области.

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

Проектирование
базы данных состоит в построении
комплекса взаимосвязанных данных. На
рисунке 1 условно отображены этапы
процесса проектирования базы данных.

Рис.1 — Этапы процесса
проектирования базы данных

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

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

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

—
обследование предметной области,
изучение ее информационной структуры;

—
выявление всех фрагментов, каждый из
которых характеризуется пользовательским
представлением, информационными
объектами, свя­зями между ними и
процессами;

·-
моделирование и интеграция всех
представлений.

Результат
данного этапа – концептуальная модель,
ин­вариантная к структуре Базы данных,
часто представляется в виде модели
«сущ­ность-связь».

Логическое
проектирование– преобразование
требований к данным в структуры данных.
Результат – СУБД-ориентированная
структура Базы данных и спецификации
прикладных программ. На этом этапе часто
мо­делируют Базы данных применительно
к различным СУБД и проводят сравнительный
анализ моделей.

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

Построение
логической и физиче­ской моделей
данных является основной частью
проектирования Базы данных.

Способ 5: вытянуть аккумулятор

В мир плавных форм от точных прямоугольников

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

Мощь и объективность реляционных отношений — бесспорна, но разве динамика колонок и строк наносит ущерб их репутации? Таблица — это просто данные, которые могут иметь шапку (список колонок) или не иметь строк. Пусть таблица — это просто совокупность данных, не обязательно именованная.

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

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

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

• входной информационный поток;
• преобразования и движение информации внутри базы данных;
• выборка данных для использования.

Понятия структуры таблицы отсутствует. Нет ни строк, ни столбцов. Есть абстракция — данное, определенной структуры удовлетворяющее конкретной точке в алгоритме. Если более конкретно, то функция обработки информации требует определенную информацию в конкретном объеме.

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

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

Варианты создания баз данных в Microsoft Access

Пустую базу данных можно создать в проводнике Windows, щелкнув правой кнопкой на пустом пространстве и выбрав «Создать… Базу данных Microsoft Access». Появится пустой файл (ему сразу же можно присвоить подходящее имя), который следует открыть двойным щелчком. Однако в современных версиях программы предусмотрены более эффективные способы выполнения этого действия.

Работа с шаблонами

Можно создать новую БД:

• из стандартного шаблона: несколько готовых шаблонов поставляются вместе с программой;
• из шаблона с сайта Office.com: там имеется обширная коллекция заготовок для баз данных различного назначения; их можно загружать по сети с помощью меню (вкладка «Создать»).

Рисунок 1. Варианты создания новой базы данных в MS Access. Автор24 — интернет-биржа студенческих работ

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

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

Замечание 2

С сайта Office.com можно загружать не только целые шаблоны, но и так называемые «части приложения» — связанные между собой компоненты, например, таблица и построенная на ее основе форма.

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

Создание пустой базы данных

Для создания пустой БД следует на вкладке «Файл» выбрать пункт «Создать» и вариант «Пустая база данных», затем указать имя файла. Access создаст БД с незаполненной таблицей «Таблица1». Она сразу же будет открыта в режиме таблицы. Для добавления данных нужно просто вводить их, отложив оптимизацию структуры колонок. Процесс ввода данных похож на работу с листом Excel.

Замечание 3

Файл Blank.accdb в папке :\Program Files\Microsoft Office\Templates\1049\Access. используется как шаблон для всех новых локальных пустых баз данных. Все новые базы данных наследуют содержимое этого файла. Это отличный способ распространения содержимого по умолчанию.

Фундаментальные знания и жесткие конструкции

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

Алгоритм не может быть фиксированным. Все должно быть определено в динамике. Заслуги квалифицированных разработчиков несомненны, но лежат они вовсе не в изящных формах решений от Oracle, MySQL или ограниченного в возможностях Access. Иная таблица Excel может обеспечить динамичный контент и не требовать участия программиста более менее приличное время после завершения работ.

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

Построение концептуальной модели данных

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

Для изучения предметной области разработчик использует следующие способы:

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

На втором этапе проектирования разработчик должен выделить сущности предметной области. Сущностью предметной области называется абстрактное представление группы объектов с одинаковыми свойствами. Например, молоко, сыр, сметана – это конкретные продукты, но все вместе они относятся к сущности «продукция молокозавода» или «товар». Сущности предметной области описываются атрибутами. Атрибуты сущности – это абстрактные характеристики сущности, конкретные значения которых определяют конкретный экземпляр сущности. Например, сущность «продукция молокозавода» может описываться следующими атрибутами: наименование продукции, тип упаковки, вес, жирность. Если задать этим атрибутам конкретные значения, то мы получим описание конкретного продукта, выпускаемого молокозаводом. Например, молоко в тетрапаке весом 0.5л. и жирностью 3.2%.

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

1. Один поставщик может поставлять много товаров.
2. Один товар может поставляться многими поставщиками.

Приведем еще один пример. Рассмотрим сущности «автомобили» и «владельцы автомобилей». Между ними имеется отношение «владения автомобилем». Его описание будет выглядеть так:

1. Один владелец может владеть многими автомобилями.
2. Один автомобиль может принадлежать только одному владельцу.

Подобные описания отношений между сущностями называются ограничениями предметной области.

Замечание 1

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

2.2.2. Этапы проектирования баз данных

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

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

Рис 2.2. Этапы проектирования базы данных

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

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

Физическое проектирование БД

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

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

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

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

Литература

• Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
• Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
• Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
• Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.
• Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4.
• Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X.

Типы отношений

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

Мощность (cardinality), или количество элементов, отношения показывает, сколько экземпляров одной сущности может соотноситься с экземпляром другой сущности. Тот факт, что бинарное отношение отражает взаимоотношения между двумя сущностями, вовсе не означает, что между ними всегда существует отношение типа “один к одному”.

Отношения между сущностями могут представлять собой и отношения типа “один к од- ному”, и “один ко многим”, и “многие ко многим” или отношения еще какого-то другого типа. Чаще всего встречаются отношения следующих типов (при условии наличия двух сущностей, A и B).

• Один ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с несколькими членами другой сущности B. Например, сущность под названием Клиент может брать много книг из библиотеки, но каждая книга за раз может выдаваться только одному единственному Клиенту. Соответственно получается, что между сущностями Клиент и Книга должно существовать отношение типа “один ко многим”. Разумеется, такое отношение может и не существовать при наличии Клиента, который еще не брал никакой Книги. То есть фактически отношение должно гласить следующее: “один Клиент может брать ноль, одну или более Книг”.
• Один к одному. В таких отношениях только один экземпляр любой из сущностей может иметь отношение с экземпляром другой сущности. Например, у каждого человека может быть только один действительный номер карточки социального страхования (Social Security Number — SSN), а каждый номер карточки социального страхования может ссылаться только на одного человека.
• Многие ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с одним и более экземплярами сущности B, а каждый экземпляр сущности B — с одним и более экземплярами сущности A. В качестве примера возьмем сущность под названием Кинозвезда и сущность под названием Кинофильм. Каждая кинозвезда может сниматься в нескольких Кинофильмах, и в каждом Кинофильме может принимать участие несколько Кинозвезд. В реальной жизни отношения типа “многие ко многим” обычно разбиваются на более простые отношения типа “один ко многим”, которые, как сложилось, являются наиболее распространенной формой отношений между сущностями.

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