Введение
1. Понятие базы данных и системы управления базой данных
1.1. Классификация системы управления базой данных
2. Реляционные БД
2.1. Проектирование реляционной БД
2.1.1. Создание БД в MS Access
3. Практическая часть
3.1 Инфологическое проектирование
3.1.1. Описание предметной области для построения концептуальной мо-дели
3.1.2. Концептуальная модель
3.2. Логическое проектирование БД
3.2.1. Выбор модели БД
3.2.2. Создание реляционной модели БД
3.3. Физическое проектирование БД
Заключение
Список литературы
Введение
Сейчас большинство компаний применяют компьютеры с целью со-хранения и обрабатывания служебных сведений. Эти сведения содержатся в базах данных, которые представляют особую значимость в современном мире. Всё, с чем мы каждый день встречаемся в жизни, вероятнее всего, зафиксировано в той либо другой базе. Один из основных навыков в рабо-те с ПК- это уметь функционировать с базами данных, ведь работники данной области постоянно будут востребованы.
Основные мысли современных информационных технологий бази-руются на концепции, в соответствии с ней информация должна быть сформирована в базы данных для того, чтобы отображать меняющийся реальный мир и удовлетворять информационным потребностям пользова-телей. Базы данных образовываются и действуют под правлением специа-лизированных программных комплексов (совокупностей языков програм-мирования и программных средств), которые называют системами управ-ления базами данных (СУБД). Сама база данных является хранилищем для значительного числа систематизированных сведений, с коими возможно осуществлять определенные воздействия: добавление, удаление, измене-ние, копирование, упорядочивание.
Повышение объёма хранимой информации, увеличение количества пользователей информационными системами привело к популяризации более практичных и относительно несложных для осознания реляционных систем. С целью обеспечивания единовременного допуска к сведениям большинства юзеров, зачастую находящихся довольно не близко друг к другу и также далеко к месту сохранения баз данных, сделаны сетевые пользовательские версии баз данных, которые основаны на реляционных структурах. В них тем либо другим методом решают характерные трудно-сти синхронных процессов, единства (точности) и защищенности сведений и, кроме того, санкционирования допуска.
В течение последних нескольких лет прослеживаются тенденции к усложнению структуры данных. Обычные виды сведений, представимых в форме чисел и текстовых строк, не утратили собственной значительности и расширяются с помощью добавления многочисленных мультимедийных документов, графических образов, хронологических рядов, процедурных, или активных, данных и мириад других информационных конфигура-ций.[14] Так возникла единая целая плеяда крайне изощрённых систем управления базами данных, которые поддерживают новейшие собрания сведений и способны осуществить достоинства нынешних аппаратных средств. Одной из данных систем считается MS Access, которая входит в пакет программ Microsoft Office, и также является популярной реляцион-ной системой управления базами данных для локальных ПК.
Актуальность темы исследования обусловлена тем, что в сегодняш-нее время невозможно представить современную организацию, будь то ав-тосервис, больница, гостиница, аэропорт или даже ресторан без специаль-ного программного обеспечения обработки информации, так называемых систем управления базами данных (СУБД). С каждым годом происходит прибавление пользователей и их запросов, в соответствии с запросами пользователей происходит пропорциональное увеличение и усложнение хранения и обслуживания данных.
Цель курсовой работы- применить на практике знания, которые бы-ли получены при изучении курса «Базы данных», и приобрести практиче-ские навыки при проектировании реляционной базы данных в MS Access.
Объект исследования – базы данных.
Предмет исследования – реляционные базы данных. (особенности проек-тирования реляционных бд)
В рамках выполнения работы предстоит решить ряд следующих за-дач:
1) изучить базы данных, системы управления базами данных и рас-смотреть их классификацию;
2) изучить понятия реляционной базы данных;
3) изучить проектирование реляционной базы данных;
4) рассмотреть технологию создания реляционных баз данных в Access;
5) приобрести практические навыки по созданию реляционной БД и проектированию ее объектов: запросы, формы, отчеты.
Данная курсовая работа состоит из введения, трех глав, заключения и списка литературы. Кроме того, сформирована реляционная БД в Access, которая состоит из таблиц, на основании которых созданы формы, отчёты и запросы на выборку.
Для написания курсовой работы использовались работы наикруп-нейших мыслителей, учебная и справочная литература, и также итоги фак-тических изучений представительных российских и иностранных писате-лей.
Основными авторы, в научных произведениях которых рассматри-валась проблема исследования являются О.Л. Голицына, И.П. Карпова, Т.Л. Партыка, И.Г. Семакин, И.И. Попов и другие.
1. Понятие базы данных и системы управления базой дан-ных
Посылом к возникновению новейшей информационной технологии интегрированного сохранения и обрабатывания сведений – концепций БД стало формирование вычислительной техники. Основным определением тут считается банк данных, который обозначает систему, содержащую намеренно созданные сведения и, кроме того, программные, языковые и средства, цель коих это концентрированное накапливание и общественное универсальное применение сведений [10].
В основе этого технологического процесса лежит система передачи программе, которая обрабатывает только лишь таких сведений, какие ей необходимы. Форма предоставления сведений вводится предварительно и описывается на логичном уровне. Модель предоставления данных являет-ся логической структурой сведений, которые хранятся в базе.
База данных является именованной совокупностью данных, которые отражают состояния объектов и отношения меж ними в изучаемой пред-метной сфере. Характерной особенностью базы данных считается стабиль-ность:
1. Сведения в базе данных всегда копятся и применяются;
2. Состав и структура задачи в пределах определенной базы данных неизменны и постоянны в течение времени;
3. База данных всегда сохраняет важные сведения [3].
По сути система управления базами данных предполагает собой со-вокупность языковых и программных средств, которая предназначена для формирования, общего применения базы данных огромным количеством юзеров и ведения.
Описанная модель представления изображена на рис. 1. [18] 
Рисунок 1 – Общие понятия базы данных
Главные элементы каждой системы БД изображены на рис.2. [18]
Рисунок 2 – Элементы системы БД
1. Первым компонентом являются «Данные»
Каждая база данных сохраняет в себе некий комплект неизменных сведений. Также есть ещё и транзитные данные, которые представляют со-бою выходные и входные данные и промежуточные итоги.
Входные данные являются информацией, поступающей в систему, к примеру, набирается на клавиатуре. Такие сведения имею все шансы счи-таться предпосылкой изменения стабильных сведений, но практически не считаются частью базы данных.
Выходные данные являются результатом и сообщением, выдающим-ся системой. В основной массе ситуаций они принимаются из неизменных сведений и, кроме того, не считаются частью базы данных.
Помимо сведений, которые характеризуют настоящую сферу, базы данных сохраняют сведения о методах и способах обработки данных либо о том, в каком месте отыскать сведения – познания о месторасположении информации, представление источников, оценки данных сведений и т.д. Эти данные именуются метаинформацией [7]. Концентрированное сохра-нение метаинформации предполагает собою словарь сведений, что отоб-ражает качество самодокументированности базы данных.
Сведения в каждой базе данных обязаны являться интегрированны-ми и едиными. Единые сведения осуществляют вероятность применения единичных комплектов данных из единой базы разными компаниями юзе-ров с целью решить те или иные вопросы.
Сведения, которые собраны из различных источников и обладающие единым способом допуска являются интегрированными данными.
Данные 2 качества данных считаются достоинством применения си-стемы базы данных коллективной степени, а интеграция отображает до-стоинство при применении индивидуальных систем.
2. Вторым компонентом является «Аппаратное обеспечивание»
Выделяются 2 группы свойств, какие более значимы для каждой си-стемы базы данных: устройства сохранения и устройства обработки дан-ных. В малых системах сохранение и обрабатывание имеют все шансы яв-ляться выполненными в одном ПК. Но большее количество больших баз данных используют разнообразные виды концепций сохранения и, кроме того, единое большое число серверов, которые отвечают за обрабатывание сведение.
3. Третьим компонентом является «Программное обеспечивание»
Программное обеспечение (ПО) — все средства, которые позволяют окончательным юзерам функционировать с данными. Также программное обеспечение решает и прочие вопросы, к примеру, гарантирует защищен-ность сведений, осуществляет технологию единовременного допуска и т.д. Всю представленную совокупность программ общепринято именовать СУБД, что означает система управления базами данных [17].
Предоставление юзеру возможности функционировать с базой дан-ных, не входя в элементы уровня аппаратного обеспечивания, является ос-новной функцией. Помимо системы управления базой данных к составля-ющему ПО принадлежат и иные элементы, такие как пользовательское прикладное программное обеспечение, разнообразные утилиты и генера-торы отчетов.
4. Четвертым компонентом является «Пользователи»
Всех пользователей базы данных можно разделить на категории:
— Люди, которые работают с базой данных напрямую с терминала либо рабочей станции, их называют конечными пользователями. Они имеют право применять созданное намеренно для них прикладное про-граммное обеспечение либо встроенные средства систем управления база-ми данных. Непосредственно с целью поддержки работы подобных юзе-ров и формируется вся система базы данных;
— Люди, которые взаимодействуют с базой данных и отвечают за разрабатывание и реализование прикладного программного продукта, их называют прикладными программистами. Созданные продукты обраща-ются с запросами к системе управление базами данных, а потом получают итоги и дают их юзеру. Задачей оперативных приложений и программ па-кетной обработки является поддержание деятельности конечного пользо-вателя, который имеет интерактивный допуск к системе;
— Люди, которые отвечают за сведения компании, их называют адми-нистраторами данных. Непосредственно они решают, какую информацию необходимо внести в базу данных, и кто и к каким сведениям может быть допущен;
— Технические специалисты, которые отвечают за реализованность решений администратора данных, их называют администраторами базы данных. [15].
1.1. Классификация системы управления базами данных
Как рассказывалось ранее, модель представления данных является логической структурой сведений, которые хранятся в базе данных БД. Есть ведущие модели представления, такие как:
1. Реляционная модель
Реляционная модель, которая подразумевает под собою наипро-стейшую и более обычную форму представления сведений в виде таблицы. Теория множества содержит особенный математический аппарат для функционирования с подобной моделью – реляционная алгебра и реляци-онное исчисление.
В основании этой модели находится понятие отношения- множество элементов, именуемых кортежами. В обычным представлении, кортеж яв-ляется строкой таблицы (рис.3). Атрибут является столбцом таблицы. Ба-зисный состав этой модели построен на декартовом произведении доме-нов. Домен- множество значений, что способен принимать компонент дан-ных [11].
Рисунок 3 – Реляционная модель данных
Есть ещё и постреляционная модель сведений, которая расширяет описанную. Она убирает лимитирование нераздельности сведений, какие сохраняются в записях таблицы. Также эта модель разрешает применение неодноначных полей, при этом набор значений этих полей является еди-ничной независимой таблицей, что встроена в главную.
Достоинства реляционной модели данных:
— простота организации – табличная форма хранения является есте-ственной и понятной для пользователя;
— четкое следование правилам математического аппарата;
— независимость данных в процессе изменения структуры таблицы;
— отсутствие необходимости знания организации БД для построения запросов.
Недостатки модели:
— большой объем необходимой памяти;
— малая скорость доступа к данным;
— трудность понимания структуры в случаях большого числа таблиц [16].
2. Иерархическая модель
Иерархическая модель данных подразумевают под собою дерево (рис.4) [4].
Рисунок 4 – Иерархическая модель данных
Любое дерево складывается из комплекта типов, один из каких- ко-рень. Тип, у которого есть подвластные виды, при этом он не считается подтипом является корневым. Подтип является потомком согласно взаи-моотношению к типу-предку. Потомки 1 вида считаются близнецами со-гласно взаимоотношению друг к другу.
Любой тип, который входит в дерево, подразумевает под собою обычный либо составляющий тип записи. Поля записи, называемые атри-бутами, сохраняют числовые либо символьные значения, какие и считают-ся охватываемым базы данных.
Достоинство этой модели- высочайшие характеристики периода ис-полнения ключевых действий над сведениями и результативное примене-ние памяти ЭВМ.
Основным недостатком является трудность для осознания и массив-ность в плане обрабатывания данных с трудными логичными связями.
3. Сетевая модель
Сетевая модель отражает взаимоотношения компонентов базы дан-ных в виде графа (рис.5) [4].
Рисунок 5 — Сетевая модель данных
Главными компонентами этой модели считаются связи и записи. На создание связи не возлагается специальных ограничений – записи-потомки имеют все шансы обладать неограниченным числом записей-предков.
Преимуществом этой модели- возможность результативного осу-ществления согласно показателю своевременности и затратов памяти.
Недостатком является жёсткость схемы базы данных и высочайшая трудность. Также в сетевой модели смягчен надзор единства связей из-за допустимости установки случайных взаимоотношений [1].
В этой главе мы рассмотрели главные определения теории баз дан-ных, также изучили элементы концепции базы данных и классификацию системы управления базой данных в зависимости от употребляемой моде-ли данных. Далее рассмотрим понятие реляционной модели данных и её проектирование.
2. Реляционные БД
Реляционная модель данных некой предметной области подразуме-вает под собою набор отношений, которые изменяются в течении времени. При формировании информационной системы совокупность отношений дает возможность сохранить данные об объектах предметной области и смоделировать взаимосвязи среди них.
Реляционная БД является хранилищем сведений, которое содержит набор 2-умерных таблиц [2]. Сведения в таблице обязаны удовлетворять таким принципам, как:
1. Значение атрибутов должно являться атомарным (другими слова-ми, любое значение, которое содержится на пересечении строки и колонки, должно являться не расчленяемым на некоторое количество значений).
2. Значение любого из атрибутов должно принадлежать к одному типу.
3. Каждые записи в таблице уникальны.
4. Каждые поля имеют уникальное имя.
5. Последовательность полей и записей в таблицах не существенна.
Отношение считается наиважнейшим понятием и подразумевает под собою 2умерную таблицу, которая содержит некие сведения.
Сущность является объектом всей природы, сведения о коем сохра-няется в БД. Сведения о сущности сохраняются в отношении.
Атрибуты подразумевают под собою свойства, которые характери-зуют сущность. В структуре таблицы любой атрибут имеет имя и ему дол-жен соответствовать заголовок некоего столбца таблицы.
Ключ отношения — совокупность его атрибутов, однозначно иденти-фицирующих любой из кортежей отношения. Другими словами, множе-ство атрибутов К, которое является ключом отношения, имеет свойство уникальности. Последующее свойство ключа — неизбыточность. Т.е. ни-какое из собственных подмножеств множества К не имеет свойство уни-кальности.[20] Каждое отношение имеет комбинацию атрибутов, какая способна быть ключом. Её наличие обеспечивается принципом три реляционной мо-дели базы данных. Весь комплекс атрибутов имеет свойство уникальности.
Возможен случай, когда отношение содержит ряд комбинаций атри-бутов, каждый из коих конкретно устанавливает все кортежи отношения. Все эти комбинации атрибутов считаются вероятными ключами отноше-ния. Каждый из вероятных ключей способен являться выбранным как пер-воначальный.
Ключи как правило применяют с целью достижения:
• исключения дублирования значений в ключевых атрибутах (другие атрибуты в расчёт не берутся);
• упорядочения кортежей. Допустимо регулирование согласно возрастанию либо убыванию значений всех основных атрибутов, и, кроме того, смешанное упорядочение (по одним — возрастание, а по иным — убывание);
• организации связывания таблиц.
Наиболее важным считается определение внешнего ключа. Внешний ключ можно понять как множество атрибутов отношения R2, значения ко-их обязаны соответствовать значениям вероятного ключа иного отношения R1.
Атрибуты отношения К2, которые составляют наружный ключ, не считаются основными для этого отношения. При помощи наружных клю-чей формируются взаимосвязи меж взаимоотношениями.
Ограничения целостности реляционной модели возможно поделить на 2 группы — ограничение целостности сущностей и ограничение целост-ности ссылок.
Ограничения целостности сущностей состоят в требовании уникаль-ности кортежей отношения (записей таблицы). Отсюда следуют ограниче-ния:
• недостаток кортежей-дубликатов (это условие предъявляется только к атрибутам первоначальных ключей);
• недостаток атрибутов с множественным характером значений.
Ограничения целостности ссылок состоят в том, что для каждой за-писи с определенным значением наружного ключа обязана непременно быть запись сопряженной таблицы-отношения с соответствующим значе-нием изначального ключа.
К отношениям возможно использовать систему операций, которая позволяет извлекать одни отношения из других. К примеру, итогом запро-са к реляционной базе данных способно являться новейшее отношение, ко-торое вычислено на базе существующих отношений. По этой причине воз-можно поделить обрабатываемые сведения на сохранимую и вычисляемую части.
Главное единицей обработки сведений в реляционных базах данных считается отношение, а не его кортежи (записи) по отдельности.
Отсутствие упорядоченности записей в таблице затрудняет поиски. На практике с целью стремительного нахождения необходимой записи вводят индексирование полей (обычно ключевых). Формирование индекс-ных массивов состоит в построении добавочной упорядоченной информа-ционной структуры для стремительного допуска к записям[6].
2.1. Проектирование реляционной БД
Проектирование базы данных считается более сложной и ответствен-ной задачей, которая связана с формированием АИС.
Проектирование БД является процессом, какой предполагает приме-нение конкретной технологии. Нет таких, кто имел бы сомнения в том, что в ситуации нарушения технологии производства печатной платы, к приме-ру, данная плата или вовсе не станет функционировать, или не будет отве-чать заявленным характеристикам. Однако считается, что придерживаться технологии проектирования базы данных и ПО вовсе не обязательно. И приступают к работе по созданию реляционной базы данных с формиро-вания таблиц. Полученная в ходе этого «проектирования» БД не ненадёж-на, неэффективна и сложна в сопровождении. Исключением могут являться ситуации обычных предметных областей, кои возможно отобразить в БД, которая состоит из трех-четырех таблиц. По этой причине при формиро-вании БД нужно следовать определенной технологии проектирования базы данных. [9] Так, процесс проектирования содержит в себе такие шаги, как:
1. Установление задач, которые стоят перед БД.
2. Получение и исследование бумаг, которые относятся к исследуе-мой предметной сфере.
3. Представление отличительных черт, какие дают возможность определить связи и зависимости среди объектов (субъектов) предметной сферы.
4. Формирование модели предметной сферы.
5. Установление групп пользователей и списка задач, которые стоят перед всеми группами.
6. Подбор аппаратной и программной платформы для осуществле-ния базы данных.
7. Подбор системы управления базой данных.
8. Формирование логической схемы базы данных.
9. Формирование схемы отношения, установление типов данных ат-рибутов и ограничений целостности.
10. Нормализация отношений (до 3 или 4 НФ).
11. Установление прав доступа пользователя к объектам базы дан-ных.
12. Написание текста формирования главных объектов БД на языке SQL в синтаксисе выбранной системы управления базой данных (пользо-ватель, таблица и другое).
13. Написание текста формирования вспомогательных объектов БД (представление, индекс, триггер, роль и так далее),
Данные шаги возможно соединить в пять стадий:
1. Этап инфологического проектирования (с 1 по 5 шаги).
2.Этап определения требования к операционной обстановке, в коей станет работать информационная система (шаг 6).
3. Этап выбора СУБД и иных инструментальных программных средств (шаг 7).
4. Этап логического проектирования базы данных (с 8 по 11 шаги).
5.Этап физического проектирования базы данных (с 12 по 13 шаги). [8] Сегодня не бывает формальных способов моделирования реально-сти, но инфологический подход закладывает базу методологии проектиро-вания БД как модели предметной сферы.
Проектирование реляционной БД протекает в порядке, что и плани-рование базы данных иных моделей, но обладает своими особенностями.
Проектирование схемы базы данных обязано выполнять задачи ми-нимизации дублирования сведений и упрощения операций их обновления и обрабатывания. При неверно созданной схеме базы данных может по-явиться аномалия модификации сведений. Аномалия обусловлена отсут-ствием средств очевидного представления типа множественных связей сре-ди объектов ПрО а также не развитостью средств отображения ограниче-ний единства на уровне модели данных. Для разрешения таких задач необходимо проводить нормализацию отношений.
Нормализация является разбиением таблицы на 2 либо больше, вла-деющих наилучшими качествами при изменении, удалении и включении сведений. Окончательной целью нормализации является получение этакого проекта БД, в коем любой факт возникает только в 1 месте, то есть исклю-чена избыточность данных. Данное производится для исключения вероят-ной противоречивости сохраняемых сведений, а не только для экономии памяти.
Механизм, позволяющий по формальным признакам всякое отноше-ние преобразовать к 3 НФ был разработан Э.Ф. Коддом и называется он механизмом нормализации реляционных отношений. [19].
Нормализация схемы отношения производится путём декомпозиции схемы. 1 НФ принадлежит к термину обычного и непростого (сложного либо неоднозначного) атрибута.
Отношение считается приведенным к первой нормальной форме, в случае если все его атрибуты простые. Чтобы привести к первой нормаль-ной форме отношение, которое содержит непростые атрибуты, необходи-мо:
— Разделить сложные атрибуты на обычные;
— Создать декартово произведение всех неоднозначных атрибутов с кортежами, к коим они принадлежат.
Для идентификации кортежа в такой ситуации необходим составной ключ, который включает первичный ключ начального отношения и все неоднозначные атрибуты.
Отношение располагается во второй нормальной форме, если оно приведено к первой нормальной форме и все не ключевые атрибуты функ-ционально всеполно зависят от составного первоначального ключа. Так, если отношение в первой нормальной форме обладает простым первич-ным ключом, то оно сразу же располагается во 2НФ. Чтобы привести от-ношение ко второй нормальной форме, необходимо:
— Создать его проекцию, исключая при этом атрибуты, какие не рас-полагаются в функционально всеполной зависимости от составного перво-начального ключа;
— Создать добавочную 1 либо более проекций на часть составного ключа и атрибуты, которые функционально зависят от данной части клю-ча.
Отношение располагается в третьей нормальной форме, если оно располагается во второй нормальной форме и любой не ключевой атрибут нетранзитивно находится в зависимости от первоначального ключа. Чтобы привести отношение к третьей нормальной форме, необходимо:
— Создать проекцию, исключая при этом транзитивно зависящие от ключа атрибуты;
— Создать добавочную 1 либо более проекций на детерминанты пер-воначального отношения и атрибуты, которые функционально зависят от них.
Отношение располагается в четвертой нормальной форме, если оно располагается в третьей нормальной форме и в нём отсутствуют нетриви-альные неоднозначные зависимости. Чтобы привести отношение к четвер-той нормальной форме, необходимо создать 2 либо несколько проекций первоначального отношения, любая из коих содержит ключ и 1 из неодно-значных зависимостей.[19]
2.1.1. Создание БД в MS Access
БД MS Access считается реляционной. Она сделана из связанных ре-ляционных таблиц. На этапе проектирования БД необходима быть опреде-ленной логическая структура БД для выбранной предметной сферы. Про-ект логической структуры базы данных определяет состав реляционных таблиц, их структуру и логические связи среди таблиц. При формирова-нии структуры любой таблицы определяется совокупность столбцов (по-лей), для любого из коих дается описание размера данных, типа и иных свойств. Также обязан быть обозначен уникальный ключ таблицы- он мо-жет складываться из 1 либо некоторого количества полей.
При проектировании БД, которая отвечает требованиям нормализа-ции, меж таблиц определяют логические связи типа один ко многим. Эти связи позволяют реализовывать в программе автоматическое поддержание связной целостности и непротиворечивости сведений.
Для создания БД нужно иметь описание избранной предметной сфе-ры, оно обязано включать настоящие процессы и объекты, устанавливать все нужные источники данных для обеспечивания запроса пользователей и выполняемых в приложении задач. Зачастую БД проектируются средства-ми системы управления базой данных в сфере организационного и эконо-мического управления[12].
Установление структуры данных и состава, какие обязаны быть за-груженными в БД, исполняется на основании исследования предметной сферы. Структура данных способно быть отображенной информационно-логической моделью (ИЛМ). Если при создании подобной модели гаран-тировано условие нормализации сведений и она изображена в канониче-ском виде, то свободно определяется проект логической структуры норма-лизованной БД. На базе канонической модели возможно сформировать реляционную БД без дублирования сведений.
При создании модели данных предметной сферы возможно исполь-зование двух подходов. В 1ом подходе, который называется аналитиче-ским либо процессным изначально формулируются главные проблемы, для разрешения коих формируется база, обнаруживаются информацион-ные необходимости вопросов приложения пользователей, а также устанав-ливается структура и состав информационных объектов модели и взаимо-связи меж ними. При 2ом подходе, который называется интуитивным определяются типовые объекты предметной сферы и их связи. Более раци-онально сочетание двух подходов, так как на первоначальном этапе не имеется данных обо всех задачах. Применение подобной технологии тем наиболее оправдано, то что гибкие средства формирования реляционной БД в MS Access предоставляют возможность на каждом из этапов разра-ботки внести перемены в БД и изменить её структуру без вреда для вве-дённых прежде сведений[21].
В ходе создания канонической модели сведений предметной сферы для формирования реляционной БД нужно обозначить информационные объекты, которые соответствуют условиям нормализации данных, и уста-новить взаимосвязи между ними с типом отношений 1:М.
При установлении проекта логической структурой реляционной БД все информационные объекты канонической модели предметной сферы адекватно отражаются в реляционной таблице, а взаимосвязям меж ин-формационными объектами соответствуют логические взаимосвязи меж парой соответствующих таблиц. Подобные связи определяются по уни-кальному ключу одной из данных таблиц, какая считается основной в свя-зи. Во 2ой таблице, какая считается подчинённой, поле связи может яв-ляться или частью её уникального ключа, или являться не ключевым.
В ходе формирования БД на ПК изначально исполняется конструи-рование её таблиц средствами MS Access. Затем формируется схема дан-ных, в коей определяются логические взаимосвязи таблиц. В схеме данных базы могут являться заданными параметры поддержания связной целост-ности сведений, если модель данных являлась разработанной в соответ-ствии с условиями нормализации.
Связная целостность сведений значит, что в БД определены и пра-вильно поддерживаются связи меж записями различных таблиц при до-бавлении, удалении и загрузке записей в связных таблицах, и, кроме того, при изменении значений ключевых полей. При обеспечивании связной це-лостности в подчинённой таблице не существует запись, для каковой не имеется взаимосвязанная запись в основной таблице.[13] После создания в MS Access схемы данных возможно приступить к введению сведений в базу — загрузке документов предметной сферы, ко-торые являются источниками сведений. В практических приложениях пользователей как правило не применяется введение напрямую в таблицы, а используются формируемые специальные экранные формы, которые вы-полняют роль интерфейса пользователей.
Формирование БД, основанное на создании нормализованной моде-ли данных предметной сферы, дает возможность свободно приобрести ло-гическую структуру реляционной БД MS Access, в коtй автоматически поддерживается целостность и непротиворечивость сведений[5].
Несомненно, что исходным пунктом в процессе работы с каждой си-стемой управления базой данных считается формирование файла либо группы файлов БД. На рис. 6 представлено окно, какое возникает после формирования новой базы.
Рисунок 6 — Главное окно БД в MS Access
Главные разделы основного окна соответствуют типам объектов, ка-кие может включать БД: запросы, таблицы, отчёты, модули и макросы.
В данной главе курсовой работы было рассмотрено понятие реляци-онных БД и их проектирование. Далее перейдем к практической части по созданию базы данных в MS Access.
3. Практическая часть
3.1 Инфологическое проектирование
3.1.1. Описание предметной области для построения концепту-альной модели
Создаваемая БД «Безмолвный кинематограф» предназначена для со-хранения и работы с информацией об известных кинофильмах эпохи без-молвного кинематографа. База данных складывается из сущностей. Сущ-ностью являются любые различимые объекты, сведения о которых нужно сохранять в БД.
Главные сущности в базе данных- основные актёры; режиссёры ки-нофильмов; страны, где были рождены актёры и режиссёры, и, кроме того, были изданы кинофильмы; жанры кинофильмов. Для любой сущности вы-деляют описательные и ключевые атрибуты. Атрибут является поимено-ванной характеристикой сущности.
БД обязана осуществлять выполнение следующих задач:
— Систематизированное сохранение данных;
— Предоставление данных исходя из запроса пользователей;
— Обеспечение оперативным доступом, изменением и удалением све-дений.
Для любой сущности ключевой атрибут- уникальный ключ «Код», другие являются побочными. Сущность «Режиссёры» включает в себя та-кие атрибуты, как: ФИО, дата рождения и смерти, страна рождения, и фо-то (рис. 7).
Рисунок 7 – Схема атрибутов «Режиссёры»
Сущность «Фильмы» включает в себя: наименование, жанр, кино-компания, год выпуска, страна, длительность кинофильма, актёры, режис-сёр (рис.8).
Рисунок 8 – Схема атрибутов «Фильмы»
Сущность «Актёры» включает в себя: ФИО, страна рождения, дата рождения и смерти (рис. 9).
Рисунок 9 – Схема атрибутов «Актёры»
Сущность «Жанры» имеет атрибут «Жанр произведения» (рис.10).
Рисунок 10 – Схема атрибутов «Жанр»
Сущность «Страны» имеет атрибут «Наименование» (рис.11).
Рисунок 11 – Схема атрибутов «Страна»
3.1.2. Концептуальная модель
Концептуальная модель является отражением предметной области, для коей создается БД. Целиком изложить концептуальную схему настоя-щей сферы дает возможность ER-модель, используемая при высоком уровне описания проектирования БД. Диаграмма сущность-связь (ER-диаграмма)- стандартная графическая нотация, с ее помощью возможно визуализировать ER-модель.
Множества сущностей представляются в варианте прямоугольника, которые содержат имена, которые выражаются существительными. Имя сущности уникально в рамках модели. Связь сущности, которая участвует в отношении, обозначается линией. Степень конца связи обозначается гра-фически, множественность связи указывается в виде ∞ на конце связи. Если же отношение не считается неотъемлемым, то линия указывается пунктир-ной.
Атрибуты изображены в варианте овала и связаны линиями с отно-шением либо с сущностью. Из числа атрибутов выделяют ключ сущности, который является набором атрибутов, значения коих считаются уникаль-ными для любого экземпляра сущности. Наименование этих атрибутов выделяют подчёркнутым текстом. ER-диаграмма, которая составлена для нашей базы данных изображена на рис.12.
Рисунок 12 – ER-диаграмма БД
Численный вид роли сущностей (1 либо многие) задаётся видом вза-имосвязи (или мощностью взаимосвязи). Есть 4 вида связи: «1:1», «1:М», «М:1» и «М: М». В создаваемой БД мы использовали тип 1:М.
3.2. Логическое проектирование БД
3.2.1. Выбор модели БД
Модель данных является интегрированным набором определений для отображения и обрабатывания сведений, взаимосвязей среди них и ограничений, которые накладываются на информацию.
Модель — представление «настоящего мира» предметов и происше-ствий, и, кроме того, имеющихся среди них связей. Это определенная аб-стракция, где упор производится на наиболее значимых и необходимых нюансах работы фирмы, а все остальные свойства игнорируются.
Итак, модель данных подразумевает под собою саму компанию. Она обязана отображать главные концепции, которые представлены в вариан-те, какой даст возможность проектировщику и пользователю БД делиться определенными и ясными суждениями о роли сведений в компании.
Для создания БД «Безмолвный кинематограф» будем использовать реляционную модель.
3.2.2. Создание реляционной модели БД
При создании логической структуры реляционной БД необходимо определить состав таблиц с целью сохранения исходных данных. Для лю-бой из таблиц надо указывать её наименование, первоначальный ключ и список полей. Определяются взаимосвязи среди таблиц.
На этапе логического проектирования базы данных имеют все шансы определяться лимитирования единства, восприниматься постановления о формировании индексов. Зачастую для решения упомянутых задач при-меняется переход от концептуальной модели, которая представлена в ва-рианте ER-диаграммы к логической модели БД.
На основе ER-диаграммы базы данных безмолвного кино (рис.12) сформируем реляционные отношения в варианте 2-умерных таблиц. Таб-лица «Режиссёры» имеет пять полей (рис.13), в соответствии с ER-диаграммой. Ключевое поле «Код» имеет тип данных «счетчик», который позволяет автоматом пронумеровывать прибавляемую информацию в таб-лицу уникальным идентификатором. Поле «ФИО» содержит данные ре-жиссёра. Поле «Дата смерти» и «Дата рождения» имеют тип данных «Да-та/Время». Поле «Страна» при помощи мастера подстановок предоставля-ет сведения из таблицы «Страны». В поле «Фото» можно прикрепить фото режиссёров, так как здесь задан такой тип данных, как «поле объекта OLE».
Рисунок 13 – Таблица «Режиссёры» в конструкторе
Таблица «Страны» имеет 2 поля: текстовое поле «страна» и ключе-вое поле «код» (рис.14).
Рисунок 14 – Таблица «Страны» в конструкторе
Таблица «Жанры» имеет ключевое поле «код» и текстовое поле «жанры» (рис.15).
Рисунок 15 – Таблица «Жанры» в конструкторе
В таблице «Актёры» (рис.16) есть ключевое поле «код», которое иг-рает роль неповторимого ключа, с целью конкретной идентификации запи-си в таблицах. Поле «ФИО» содержит данные актёра.
Рисунок 16 – Таблица «Актёры» в конструкторе
В таблице «Фильмы» (рис.17) есть ключевое поле «код», которое иг-рает роль неповторимого ключа, с целью конкретной идентификации запи-си в таблицах. Поле «название» содержит наименования фильмов. Поле «год выпуска» содержит сведения о годах выпуска фильмов. Поле «про-должительность» содержит сведения о длительности фильма. Поле «кино-компания» содержит наименование кинокомпании, которая выпустила фильмы.
Рисунок 17 – Таблица «Фильмы» в конструкторе
На основании ER-диаграммы формируются взаимосвязи меж табли-цами. В данном случае между таблицами установим связь 1: М (рис.18).
Для поддержки базы данных в крепком пребывании применяются механизмы — средства поддержки целостности. С целью реализации един-ства, следует, чтобы любому определенному значению наружного ключа отвечал кортеж сопряженной таблицы с надлежащим значением изначаль-ного ключа. Лимитирование целостности исполняется на уровне наружных и изначальных ключей.
Рисунок 18 – Схема данных
Нормализация является разбиением таблицы на 2 либо больше, вла-деющих наилучшими качествами при изменении, удалении и включении сведений либо процессом поочередной смены таблицы её абсолютными декомпозициями.
Нормализация таблиц базы данных безмолвного кинематографа не нужна, потому что все таблицы созданной базы данных удовлетворяют условию, что в позиции скрещивания любой строчки и столбика таблицы постоянно располагается только одно значение и существовать множества этих значений не может.
3.3. Физическое проектирование БД
На данном этапе выбирается способ осуществления базы данных. Цель физического проектирования, которое подразумевает под собою ме-ханизм размещения сведений в наружной памяти — описать способ физиче-ского осуществления логической модели.
Если применяется реляционная системы управления базой данных, в таком случае в ее сфере обязан быть сформирован набор ограничений и таблиц и должна быть определена конкретная структура сохранения све-дений и способы допуска к информации. Итоги данного этапа протоколи-руются в форме схемы сохранения на языке установления сведений.
Введений информации происходит в табличном порядке либо с ис-пользованием формы. Кортеж, табличная строка, запись, которая состоит из дискретного комплекта значений согласно полей таблиц- единичный элемент сведений. Таблицу «Режиссёры» заполним сведениями наиболее популярных режиссёров безмолвного кинематографа в соответствии с названиями её полей (рис.19). Фильмы режиссёров перечислим в таблице «Фильмы» и укажем дополнительные сведения (рис.20).
Рисунок 19 – Таблица «Режиссёры»
Рисунок 20 – Таблица «Фильмы»
В таблицу «Страны» внесем наименования стран, где появились на свет режиссёры и композиторы, и те государства, в каких изготавливались кинофильмы (рис.21). В таблице «Жанры» укажем типы фильмов, которые занесены в базу данных (рис.22).
Рисунок 21 – Таблица «Страны»
Рисунок 22 – Таблица «Жанры»
Таблицу «Актёры» заполним сведениями о популярных актерах без-молвного кинематографа в соответствии с названиями её полей (рис.23).
Рисунок 23 – Таблица «Актёры»
MS Access дает вероятность внедрять сведения равно как напрямую в таблицу, так и при помощи форм. Форма в базе данных является струк-турированным окном, какое возможно показать таким образом, что оно повторяет форму бланка. Формы делаются из комплекта раздельных ком-понентов управления. Форма- объект БД, какой возможно применять с це-лью формирования интерфейса пользователей для приложения БД.
Основная форма в нашей базе данных – это форма для просмотра абсолютно всех творений конкретного композитора. Приведем пример со-зданной формы таблицы «Фильмы» (рис. 24) и также создадим форму таблицы «Актеры» и «Режиссеры».
Рисунок 24 – Форма «Фильмы»
Созданная форма отображает все данные из таблицы и имеет кнопки управления, которые позволяют перемещаться по записям. Кроме того, возможно формировать разделённые формы, которые содержат едино-временно сведения об одной записи из таблицы и перечень всех существу-ющих компонентов, с перспективой поиска нужной информации. Создадим разделенную форму таблицы «Жанры» (рис.25) и «Страны».
Ознакомиться с интересующей информацией в абсолютном размере возможно при помощи отчётов. Отчёт является форматированным представ-лением сведений, которые выводятся на печать или экран, либо в файл. Они дают возможность достать из основы необходимые сведения и показать их в варианте, который удобен для воспринятия, и, кроме того, дают широкую возможность для анализа и обобщения информации. Развернутый отчёт со-держит все данные из запроса или таблицы, но включает заголовки и разделен на странички с указанием верхнего и нижнего колонтитула. Создадим полный отчет таблицы «Фильмы» (рис.26), а также для таблицы «Актеры».
Рисунок 25 – Разделённая форма «Жанр»
Рисунок 26 – Отчёт «Фильмы»
Сделаем отчёт таблицы «Актеры» при помощи «Мастера отчетов» и зададим определенный порядок, например, ФИО, дата рождения, страна рождения (рис.27). Запрос является средством выбора нужных сведений из БД. Есть такие типы запросов, как на обновление и добавление, на удале-ние и выборку, а также перекрёстный запрос и формирование таблицы. Сделаем запрос на выборку таблицы «Актеры» с условием того, что они родились в Великобритании (рис. 28). Ещё сделаем запрос на выборку режиссёров из США и фильмов, произведенных в США жанра «Драма».
Рисунок 27 – Отчет «Актеры1»
Рисунок 28 – Запрос «Актеры из Великобритании»
Так, мы разработали реляционную БД, в которой формируемые за-просы, отчеты и формы дают возможность извлекать ответы на вопросы, моментально и результативно обновлять и исследовать сведения, распеча-тывать диаграммы и отчеты, а также реализовывать отбор нужной инфор-мации.
Заключение
В рамках написания данной курсовой работы в первой главе была раскрыта тема определения базы данных и системы управления базой данных. База данных — это комплекс взаимозависимых сведений, какие сформированы в соответствии со схемой базы данных так, что с ними мо-гут функционировать пользователи. С целью управления БД применяются специальные системы – СУБД, состоящие из следующих компонентов: данные; аппаратное и программное обеспечивание; пользователи.
Основной функцией системы управления базой данных является предоставление пользователям возможности функционировать с базой данных, не думая о деталях уровня аппаратного обеспечивания.
Создание базы данных считается актуальным направлением информационных технологий. Данное обуславливается ускорением интеграции информативных систем во все без исключения области жизни.
Мир баз данных делается всё наиболее общим, с формированием Intranet- и Internet- технологий возникла вероятность допуска к удалённым базам данных, это повергло к нужности формирования обычного языка, какой смог бы применяться таким образом, чтоб работать в огромном числе разных типов компьюторных сфер. Стандартный язык предоставил бы пользователю, знающему 1 набор команд, применять их, чтоб формировать, искать, передавать и менять сведения вне зависимости от того, функционируют ли они на индивидуальном либо универсальном ПК или общесетевой рабочей станции.
Так Американский Национальный Институт Стандартов разработал стандарт языка SQL, что означает структурированный язык запросов. При том структурированный язык запросов не создавался институтом стандартов. Данное по сути открытие IBM. Но иные организации подцепили структурированный язык запросов и мгновенно, организация Oracle точно, которая приобрела разрешение на рыночную реализацию SQL-продуктов. Но уже позднее возникли определенные трудности, какие появились из-за типизации институтом стандартов языка в виде определенных ограничений. Определенные проекты БД как правило предоставляют институту стандартов SQL вспомогательные характерные черты и зачастую смягчают многочисленные ограничения эталона.
В настоящее время реляционные базы данных- самые распростра-ненные, в следствии собственной простоты и наглядности, равно как в ходе формирования, так и на пользовательском уровне.
Их основное достоинство- это сочетаемость с наиболее распростра-ненным структурированным языком запросов. При помощи одного запро-са на данном языке возможно объединить некоторое количество таблиц во временную таблицу и вырезать из неё необходимые столбцы и строки (проекция и селекция). Т.к. структура таблицы реляционной БД подсозна-тельно ясна пользователю, то и структурированный язык запросов счита-ется обычным и лёгким для изучения.
В ходе написания курсовой работы, при формировании базы данных были использованы и зафиксированы навыки работы с БД в системе управления базой данных MS Access. Созданная база данных дает воз-можность моментально и результативно извлекать сведения пользовате-лям.
Список литературы
1. Мезенцев К.Н. Автоматизированные информационные системы: учебник для студ. учреждений сред. проф. образования — 4-е изд., стер. — М.: Издательский центр «Академия», 2013. — 176 с.
2. С.Д. Кузнецов. Базы данных. – М.: Академия, 2012. – 496 с.
3. О.Л. Голицына, Н.В. Максимов, И.И. Попов. Базы данных. Учебное по-собие. – М.: ДРОФА, 2014. – 400 с.
4. Петров Г.А., Тихов С.В., Яковлев В.П. Базы данных: учебное посо-бие /
СПбГТУ РП. — СПб. 2015. – 74 с.
5. О.Л. Голицына, Т.Л. Партыка, И.И. Попов. Основы проектирования баз данных. – М.: Форум, 2012. – 416 с.
6. Л.И. Шустова, О.В. Тараканов. Базы данных. Учебник. – М.: Инфра-М, 2016. – 304 с.
7. Гущин А.Н. Базы данных. 2-е изд., испр. и доп.: учебно-методическое пособие. М.-Берлин: Директ-Медиа, 2015. – 311 с.
8. Диго С.М. Базы данных. Проектирование и создание. – УМК: ЕАОИ, 2011. – 171 с.
9. И.П. Карпова. Проектирование реляционных баз данных: Метод. указания к курсовому проектированию по курсу «Базы данных» / Москов-ский государственный институт электроники и математики; 2010. – 32 с.
10. Елинова Г.Г. Информационные технологии в профессиональной дея-тельности: Краткий курс лекций. Оренбург: ГОУ ОГУ, 2014. – 39 с.
11. Карпова И.П. Базы данных: Учебное пособие. – СПб.: Питер, 2013. – 240 с.
12. И.Г. Семакин. Основы программирования и баз данных. Учебник. – М.: Academia, 2014. – 224 с.
13. Макарова Н.В. Информатика: Учебник для вузов / Н.В. Макарова, В.Б. Волков. – СПб.: Питер, 2011. – 576 с.
14. С.В. Симонович Информатика: Базовый курс: Учебник для вузов. — 3-е изд. Стандарт третьего поколения. — СПб.: Питер, 2011. — 640 с.
15. Нестеров С.А. Базы данных: учеб. пособие. – СПб.: Изд-во Политех. ун-та, 2013. – 150 с.
16. Петров Г.А., Тихов С.В., Яковлев В.П. Базы данных: учебное посо-бие / СПбГТУ РП. – СПб. 2015. – 74 с.
17. Радыгин В.Ю. Базы данных и СУБД: учебно-методическое пособие. – М.: МГИУ, 2011. – 72 с.
18. Саак А.Э. Информационные технологии управления: Учебник для вузов. 2-е изд. / А.Э. Саак, Е.В. Пахомов, В.Н. Тюшняков. – СПб.: Питер, 2012. – 320 с.
19. Борис Лысиков. Технологии баз данных и знаний. – М.: Palmarium Academic Publishing, 2014. – 192 с.
20. Игорь Дьяков. Базы данных. – М.: LAP Lambert Academic Publishing, 2012. – 128 с.
21. Брешенков Александр. Базы данных. – М.: LAP Lambert Academic Pub-lishing, 2011. – 404 с.