VII Международная студенческая научная конференция Студенческий научный форум - 2015

ВВЕДЕНИЕ

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

Базами данных являются, например, различные справочники, энциклопедии.

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

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

Основным программным средством для реализации задания является приложение Mіcrosoft Access, из пакета офисных прикладных программ Mіcrosoft Office.

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

К основным возможностям СУБД Microsoft Access можно отнести следующие:

• проектирование базовых объектов – двумерные таблицы с полями разных типов данных;

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

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

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

Целью данной работы является освоение навыков работы с базами данных и создание в СУБД Microsoft Access реляционной базы данных о немом кино.

1 ЭТАП ИНФОЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

1.1 Описание предметной области для построения концептуальной модели

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

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

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

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

Разрабатываемая база данных «Немое кино» предназначена для хранения и работы с данными о знаменитых фильмах эпохи немого кино.

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

Основными сущностями в БД являются:

– режиссеры фильмов;

– главные актеры фильмов;

– жанры кино;

– страны, в которых родились актеры и режиссеры, а также были выпущены фильмы.

Для каждой сущности выделяются описательные и ключевые атрибуты.

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

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

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

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

В ходе анализа предметной области необходимо:

- уяснить и указать назначение базы данных;

- определить и выделить первоначальный набор сущностей и атрибутов предметной области.

Будущая база данных должна выполнять следующие задачи:

- систематизированное хранение информации;

- выдача информации по запросу пользователя;

- обеспечивать оперативный доступ, изменение и удаление информации.

Для каждой сущности ключевым атрибутом является уникальный ключ «Код», все остальные - побочные.

Сущность режиссеры содержит: атрибуты: имя, год рождения, год смерти и страна, в которой родился режиссер.

Рисунок 1 – Атрибуты сущности режиссеры

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

Рисунок 2 – Атрибуты сущности фильмы

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

Рисунок 3 – Атрибуты сущности актеры

Сущность жанры включает один атрибут – жанр произведения.

Рисунок 4 – Атрибуты сущности жанр

В сущности страны также присутствует один атрибут – название страны.

Рисунок 5 – Атрибуты сущности страна

1.2 Концептуальная модель предметной области

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

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

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

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

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

Тип – набор свойств и событий объекта, описанных как единый комплекс. При этом, в зависимости от уровня упрощений, может быть свойством типа другой тип.

Объект – совокупность типов и свойств, объединенных в один тип, способный описать объект реального мира.

Связь – это свойство типа или свойства типа, характеризующая взаимосвязь типов в дереве данных или способ изменения значения свойства объектного типа соответственно. Бывают три типа связей: включение в дереве данных, вставка из другого типа значения свойства типа и ссылка на экземпляр типа в дереве данных. Включение позволяет строить дерево данных.

Наследование – это способ описания дерева типов. Можно описать тип литературы, от которого будут наследованы следующие типы: книга, журнал, статья. При этом поддерживается полиморфизм. Так, если в литературе есть свойство автор, то произведя поиск по потомкам от литературы можно найти все книги, журналы и статьи этого автора.

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

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

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

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

ER-диаграмма, составленная для БД «Немое кино», представлена на рисунке 6.

Рисунок 6 – ER-диаграмма базы данных «Немое кино»

Количественный характер участия сущностей (один или многие) задается типом связи (или мощностью связи). Возможны следующие типы: «один к одному» (1:1), «один ко многим» (1:М), «многие к одному» (М:1), «многие ко многим» (М:М).

2 ЭТАП ЛОГИЧЕСКОГО ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

2.1 Выбор модели базы данных

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

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

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

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

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

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

Рисунок 7 – Структура иерархической базы данных

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

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

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

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

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

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

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

Первые системы управления базами данных использовали иерархическую модель данных. В настоящее время представителем иерархической СУБД является разработка фирмы IBM система IMS, также – СУБД System 2000.

2.1.2 Сетевая модель данных. Сетевая модель данных – модель, состоящая из записей, элементов данных и связей типа “один ко многим” (1:М), установленных между записями.

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

Рисунок 8 – Структура сетевой базы данных

Для описания схемы сетевой БД используется две группы типов: «запись» и «связь». Тип «связь» определяется для двух типов «запись»: предка и потомка. Переменные типа «связь» являются экземплярами связей.

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

Физическое размещение данных в базах сетевого типа может быть организовано практически теми же методами, что и в иерархических базах.

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

1. Поиск записи в БД;

2. Переход от предка к первому потомку;

3. Переход от потомка к предку;

4. Создание новой записи;

5. Удаление текущей записи;

6. Обновление текущей записи;

7. Включение записи в связь;

8. Исключение записи из связи;

9. Изменение связей и так далее.

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

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

Системы на основе сетевой модели не получили широкого распространения на практике.

2.1.3 Реляционная модель данных. Реляционная модель данных – логическая модель данных.

Впервые была предложена британским учёным сотрудником компании IBM Эдгаром Франком Коддом (E. F. Codd) в 1970 году в статье "A Relational Model of Data for Large Shared Data Banks". В настоящее время эта модель является фактическим стандартом, на который ориентируются практически все современные коммерческие СУБД.

В реляционной модели достигается гораздо более высокий уровень абстракции данных, чем в иерархической или сетевой. В упомянутой статье Е.Ф. Кодда утверждается, что «реляционная модель предоставляет средства описания данных на основе только их естественной структуры, то есть без потребности введения какой-либо дополнительной структуры для целей машинного представления». Другими словами, представление данных не зависит от способа их физической организации. Это обеспечивается за счет использования математической теории отношений (само название «реляционная» происходит от английского relation – «отношение»).

Кристофер Дейт определил три составные части реляционной модели данных:

1. Структурная;

2. Манипуляционная;

3. Целостная.

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

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

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

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

Именованное множество пар «имя атрибута – имя домена» называется схемой отношения. Мощность этого множества – называют степенью или «арностью» отношения. Набор именованных схем отношений представляет из себя схему базы данных.

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

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

2.2 Построение реляционной модели базы данных

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

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

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

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

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

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

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

На основании ER-диаграммы БД «Немое кино» составим реляционные отношения в виде двумерных таблиц.

В соответствии с ER-диаграммой в таблице «Режиссеры» имеется 5 полей. Ключевое поле «код» с типом данных «счетчик», позволяющий автоматически нумеровать добавляемые записи в таблицу уникальным идентификатором. Текстовое поле ФИО, которое будет хранить фамилию, имя и отчество режиссера. Два поля с типом данных «дата/время»: «дата рождения» и «дата смерти». Поле «страна» с помощью мастера подстановок будет предоставлять информацию из таблицы «Страны». Поле «фото» имеет тип данных «поле объекта OLE» и позволяет вставить фотографии режиссеров.

Рисунок 9 – Таблица «Режиссеры» в режиме конструктора

В таблице «Страны» всего два поля: ключевое поле «код» типа счетчик и текстовое – «страна».

Рисунок 10 – Таблица «Страны» в режиме конструктора

Таблица «Жанры» также включает уникальное поле «код» и текстовое поле «жанры».

Рисунок 11 – Таблица «Жанры» в режиме конструктора

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

Рисунок 12 – Таблица «Актеры» в режиме конструктора

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

Рисунок 13 – Таблица «Фильмы» в режиме конструктора

На основе ER-диаграммы создаются связи между таблицами. Существует четыре типа связей: «один-к-одному», «один-ко-многим», «многие-к-одному» и «многие-ко-многим».

Тип связи «один-к-однму» наиболее прост: любому экземпляру сущности А соответствует только один экземпляр сущности В, и наоборот.

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

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

В связи «многие ко многим» строке таблицы А может сопоставляться несколько строк таблицы Б, и наоборот. Такие связи создаются с помощью третьей таблицы, которая называется таблицей соединения, чей первичный ключ состоит из внешних ключей А и Б.

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

Рисунок 14 – Схема данных БД «Немое кино»

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

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

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

3 ЭТАП ФИЗИЧЕСКОГО ПРОЕКТИРОВАНИЯ БАЗЫ ДАННЫХ

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

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

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

Таблица «Режиссеры» заполняется данными самых известных режиссеров немого кино в соответствии с наименованиями ее полей.

Рисунок 15 – Таблица «Режиссеры» в режиме таблицы

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

Рисунок 16 – Таблица «Фильмы» в режиме таблицы

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

Рисунок 17 – Таблица «Страны» в режиме таблицы

В таблице «Жанры» указываются все типы фильмов, занесенных в БД.

Рисунок 18 – Таблица «Жанры» в режиме таблицы

Таблица «Актеры» заполняется данными известных актеров немого кино в соответствии с наименованиями ее полей.

Рисунок 19 – Таблица «Актеры» в режиме таблицы

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

Форма является объектом базы данных, который можно использовать для создания интерфейса пользователя для приложения базы данных.

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

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

Форма предоставляет возможности для:

– ввода и просмотра информации базы данных;

– изменения данных;

– печати;

– создания сообщений.

В программе Access формы создаются с помощью:

– конструктора форм - позволяет редактировать существующие формы или создавать новые любой сложности;

– мастера форм - позволяет создавать формы из заготовок, с заданным стилем.

Главной формой в БД «Немое кино» является форма для просмотра всех произведений определенного композитора. Для ее создания необходимо выбрать таблицу «Фильмы» и в меню «Создание» нажать кнопку «Форма». Автоматически будет создана форма, отображающая всю информацию из таблицы с кнопками управления, позволяющие перемещаться по записям.

Рисунок 20 – Форма «Актеры»

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

Рисунок 21 – Форма «Композиторы»

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

Для создания разделенной формы «Жанры» в меню «Создание» нужно нажать кнопку «Разделенная форма».

Рисунок 22 – Разделенная форма «Жанр»

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

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

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

Рисунок 23 – Отчет «Фильмы»

Создадим отчет для таблицы «Режиссеры», для чего выделим ее и нажмем на кнопку «Отчет».

Рисунок 24 – Отчет «Композиторы»

Для создания отчета таблицы «Фильмы» при помощи «Мастера отчетов», необходимо: меню «Создание» необходимо нажать кнопку «Мастер отчетов». Откроется окно, в нем необходимо выбрать поля, которые будут отображаться в отчете. После нажатия кнопки «Далее» указываются уровни полей. На самый верхний уровень поместим название фильма. На следующей странице настроек можно указать поле, по которому будет происходить сортировка данных. Нажав на кнопку «Далее» выбирается вид стиль отчета. После нажатия кнопки «Готово», откроется окно с готовым отчетом, отображающим данные в соответствии с выставленными настройками.

Рисунок 25 – Отчет «Фильмы1»

Запрос – это средство выбора необходимой информации из базы данных. Вопрос, сформированный по отношению к базе данных, и есть запрос. Применяются два типа запросов: по образцу (QBE – Query by example) и структурированный язык запросов (SQL – Structured Query Language).

QBE - запрос по образцу – средство для отыскания необходимой информации в базе данных. Он формируется не на специальном языке, а путем заполнения бланка запроса в окне Конструктора запросов.

SQL – запросы – это запросы, которые составляются программистами из последовательности SQL-инструкций. Эти инструкции определяют, что необходимо сделать с входным набором данных для генерации выходного набора. Все запросы Access строит на основе SQL-запросов, чтобы посмотреть их, необходимо в активном окне проектирования запроса выполнить команду Вид/SQL.

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

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

Рисунок 26 – Конструктор запроса «Французские режиссеры»

Рисунок 27 –Запрос «Французские режиссеры»

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

Рисунок 28 – Конструктор запроса «Драматические американские фильмы»

Рисунок 29 –Запрос «Драматические американские фильмы»

ЗАКЛЮЧЕНИЕ

Разработка БД является одним из актуальных направлений информационных технологий. Это обусловлено ускорением интеграции информационных систем во все сферы жизни.

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

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

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ

1. Буч Г. Объектно-ориентированное проектирование с примерами применения. / Г. Буч. – М., Радио и связь, 1992.

2. Горев А., Ахаян Р, Макашарипов С. Эффективная работа с СУБД. / А. Горев и др. – СПб.; Питер, 1997., – 700 с.

3. Вескес Дж., Гандерлоу М., Чипмен М. Access и SQL Server. Руководство разработчика. Пер. с англ. / Дж. Вескес и др. – М.: "ЛОРИ", 1997. – 362 с.

4. Дейт К. Дж. Введение в системы баз данных, 6-е изд.: Пер. с англ. / К. Дейт. – СПб.: Издательский дом "Вильямс", 2000.

5. Диго С. М. Проектирование баз данных. / С. М. Диго. – М.: Финансы и статистика, 1988.

6. Диго С. М. Создание баз данных в среде СУБД Access. / С.М. Диго. – М.: МЭСИ, 2000. – 105 с.

7. Мирошниченко Г.А. Реляционные базы данных: практические приемы оптимальных решений. / Г.А. Мирошниченко. – СПб.: БХВ – Петербург, 2005. – 367 с.

8. Мишенин А. И. Теория экономических информационных систем. / А.И. Мишенин. – М.: Финансы и статистика, 1999. – 240 с.

9. База данных MS Access [Электронный ресурс]:[справочный листок]. – Системы управления базами данных, 2009. - Режим доступа: http://revolution.allbest.ru/programming/00059989.html

10. Базы данных [Электронный ресурс]:[справочный листок]. - Проектирование баз данных Microsoft Office Access , 2003. - Режим доступа: http://www.twirpx.com/files/informatics/db

Код для цитирования: Скопировать