Войти в мой кабинет
Регистрация
ГОТОВЫЕ РАБОТЫ / КУРСОВАЯ РАБОТА, ИНФОРМАЦИОННЫЕ ТЕХНОЛОГИИ

Разработка базы данных «Кинотеатр»

one_butterfly 44 руб. КУПИТЬ ЭТУ РАБОТУ
Страниц: 37 Заказ написания работы может стоить дешевле
Оригинальность: неизвестно После покупки вы можете повысить уникальность этой работы до 80-100% с помощью сервиса
Размещено: 07.05.2021
Целью курсового проекта является изучение основ проектирования баз данных в организационно-управленческих приложениях. В процессе изучения дисциплины и выполнения курсовой работы студенты должны усвоить теоретические основы организации баз данных. Включая принципы построения на концептуальном, логическом и физическом уровнях, научиться ставить и решать практические задачи проектирования и эксплуатации баз данных. ЦЕЛЬ ИССЛЕДОВАН ИЯ Разработать базу данных кинотеатра на SQL Server, чтобы посмотреть, как происходит процесс покупки и продажи билетов, распределения мест. ПОСТАНОВКА ЗАДАЧИ Кинотеатры (информация для зрителей): • фильмы: название, описание, жанр, длительность, популярность, в каких кинотеатрах показывается, цены на билеты; • кинотеатры: название, адрес, схема проезда, описание, число мест, акустическая система, формат. ОБЪЕКТ ИССЛЕДОВАНИЯ Объектом исследования является кинотеатр. ПРЕДМЕТ ИССЛЕДОВАНИЯ Предметом исследования база данных кинотеатр
Введение

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

ВВЕДЕНИЕ 3 ЦЕЛЬ ИССЛЕДОВАН ИЯ 4 ПОСТАНОВКА ЗАДАЧИ 4 ОБЪЕКТ ИССЛЕДОВАНИЯ 4 ПРЕДМЕТ ИССЛЕДОВАНИЯ 4 ГЛАВА 1. ОБЗОР ПРЕДМЕТНОЙ ОБЛАСТИ 5 1.1. ОСНОВНЫЕ ПОНЯТИЯ РЕЛЯЦИОННОЙ БД 5 1.2. ОТСУТСТВИЕ КОРТЕЖЕЙ-ДУБЛИКАТОВ, ПЕРВИЧНЫЙ И ВОЗМОЖНЫЕ КЛЮЧИ ОТНОШЕНИЙ 9 1.3. ОТСУТСТВИЕ УПОРЯДОЧЕННОСТИ КОРТЕЖЕЙ 11 ГЛАВА 2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 13 2.1. ТЕОРИЯ О ПРОЕКТИРОВАНИИ БД (ERD) 13 2.2 ПОСТРОЕНИЕ ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ 14 2.3 ПОСТРОЕНИЕ ДИАГРАММЫ КЛАССОВ 16 2.4. ПРОЕКТИРОВАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ БАЗЫ ДАННЫХ 16 2.5. МАПИРОВАНИЕ РЕЛЯЦИОННОЙ МОДЕЛИ В МЕТАМОДЕЛЬ 18 2.6. ПОСТРОЕНИЕ ДИАГРАММЫ КЛАССОВ ДЛЯ МЕТАМОДЕЛИ 19 2.7. ПРОЕКТИРОВАНИЕ МЕТАМОДЕЛИ БАЗЫ ДАННЫХ 20 ГЛАВА 3. ОПИСАНИЕ СОЗДАНИЯ ОБЪЕКТОВ БД 22 3.1. ЛОГИЧЕСКАЯ РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ 22 ЗАКЛЮЧЕНИЕ 26 СПИСОК ЛИТЕРАТУРЫ 27 КОД ПРОГРАММНОЙ РЕАЛИЗАЦИИ 35
Список литературы

Отрывок из работы

ГЛАВА 1. ОБЗОР ПРЕДМЕТНОЙ ОБЛАСТИ 1.1. Основные понятия реляционной бд Основными понятиями реляционныхбаз данныхявляются тип данных, домен, атрибут, кортеж, первичный ключ и отношение. В реляционной модели данных информация хранится в одной или нескольких связанных таблицах. Отдельная таблица обычно представляет совокупность (группу) либо реальных объектов, либо некоторых абстрактных концепций, либо событий одного типа. Каждая запись в таблице идентифицирует один объект группы. Таблица состоит из строк и столбцов, называемых соответственно записями и полями. Таблицы обладают следующими свойствами. 1. Каждая ячейка таблицы представляет собой один элемент данных, совокупность значений в одном столбце одной строки недопустима. 2. Все столбцы в таблице однородные. Это означает, что элементы столбца имеют одинаковую природу. Столбцам присвоены имена. 3. В таблице нет двух одинаковых строк. 4. Порядок размещения строк и столбцов в таблице может быть произвольным. В операциях с такой таблицей ее строки и столбцы могут просматриваться в любом порядке безотносительно к их информационному содержанию и смыслу. Таблицы, обладающие такими свойствами, являются точным прообразом математического двухмерного множества - отношения (relation). Но эти два понятия не эквивалентны. Отношение - это абстрактный математический объект, а таблица - конкретное изображение этого абстрактного объекта. Различие проявляется в их свойствах. В отношении строки и столбцы не могут быть упорядочены, а в таблице строки упорядочены сверху вниз, столбцы - слева направо. В таблице могут повторяться строки, а в отношении - нет. В реляционной модели каждая строка таблиц уникальна. Это обеспечивается применением ключей, которые содержат одно или несколько полей таблицы, Ключи хранятся в упорядоченном виде, обеспечивающем прямой доступ к записям таблицы во время поиска. Связь между таблицами осуществляется посредством значений одного или нескольких совпадающих полей (преимущественно ключевых). . Рисунок 1.1. – Заголовок главной страницы игры Понятиетип данныхв реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres). В нашем примере мы имеем дело с данными трех типов: строки символов, целые числа и "деньги". Понятиедомена более специфично для баз данных, хотя и имеет некоторые аналогии с подтипами в некоторых языках программирования. В самом общем виде домен определяется заданием некоторого базового типа данных, к которому относятся элементы домена, и произвольного логического выражения, применяемого к элементу типа данных. Если вычисление этого логического выражения дает результат "истина", то элемент данных является элементом домена. Наиболее правильной интуитивной трактовкой понятия домена является понимание домена как допустимого потенциального множества значений данного типа. Например, домен "Имена" в нашем примере определен на базовом типе строк символов, но в число его значений могут входить только те строки, которые могут изображать имя (в частности, такие строки не могут начинаться с мягкого знака). Следует отметить также семантическую нагрузку понятия домена: данные считаются сравнимыми только в том случае, когда они относятся к одному домену. В нашем примере значения доменов "Номера пропусков" и "Номера групп" относятся к типу целых чисел, но не являются сравнимыми. Заметим, что в большинстве реляционных СУБД понятие домена не используется, хотя в Oracle V.7 оно уже поддерживается. Схема отношения - это именованное множество пар {имя атрибута, имя домена (или типа, если понятие домена не поддерживается)}. Степень или "арность" схемы отношения - мощность этого множества. Степень отношения сотрудники равна четырем, то есть оно является 4-арным. Если все атрибуты одного отношения определены на разных доменах, осмысленно использовать для именования атрибутов имена соответствующих доменов (не забывая, конечно, о том, что это является всего лишь удобным способом именования и не устраняет различия между понятиями домена и атрибута). Схема БД (в структурном смысле) - это набор именованных схем отношений. Кортеж, соответствующий данной схеме отношения, - это множество пар {имя атрибута, значение}, которое содержит одно вхождение каждого имени атрибута, принадлежащего схеме отношения. "Значение" является допустимым значением домена данного атрибута (или типа данных, если понятие домена не поддерживается). Тем самым, степень или "арность" кортежа, т.е. число элементов в нем, совпадает с "арностью" соответствующей схемы отношения. Попросту говоря, кортеж - это набор именованных значений заданного типа. Отношение - это множество кортежей, соответствующих одной схеме отношения. Иногда, чтобы не путаться, говорят "отношение-схема" и "отношение-экземпляр", иногда схему отношения называют заголовком отношения, а отношение как набор кортежей - телом отношения. На самом деле, понятие схемы отношения ближе всего к понятию структурного типа данных в языках программирования. Было бы вполне логично разрешать отдельно определять схему отношения, а затем одно или несколько отношений с данной схемой. Однако в реляционных базах данных это не принято. Имя схемы отношения в таких базах данных всегда совпадает с именем соответствующего отношения-экземпляра. В классических реляционных базах данных после определения схемы базы данных изменяются только отношения-экземпляры. В них могут появляться новые и удаляться или модифицироваться существующие кортежи. Однако во многих реализациях допускается и изменение схемы базы данных: определение новых и изменение существующих схем отношения. Это принято называть эволюцией схемы базы данных. Обычным житейским представлением отношения является таблица, заголовком которой является схема отношения, а строками - кортежи отношения-экземпляра; в этом случае имена атрибутов именуют столбцы этой таблицы. Поэтому иногда говорят "столбец таблицы", имея в виду "атрибут отношения". Когда мы перейдем к рассмотрению практических вопросов организации реляционных баз данных и средств управления, мы будем использовать эту житейскую терминологию. Этой терминологии придерживаются в большинстве коммерческих реляционных СУБД. Реляционная база данных - это набор отношений, имена которых совпадают с именами схем отношений в схеме БД. Как видно, основные структурные понятия реляционной модели данных (если не считать понятия домена) имеют очень простую интуитивную интерпретацию, хотя в теории реляционных БД все они определяются абсолютно формально и точно. 1.2. Отсутствие кортежей-дубликатов, первичный и возможные ключи отношений То свойство, что тело любого отношения никогда не содержит кортежей-дубликатов, следует из определения тела отношения как множества кортежей. В классической теории множеств по определению любое множество состоит из различных элементов. Именно из этого свойства вытекает наличие у каждого значения отношения первичного ключа – минимального множества атрибутов, являющегося подмножеством заголовка данного отношения, составное значение которых уникально определяет кортеж отношения. Действительно, поскольку в любое время все кортежи тела любого отношения различны, у любого значения отношения свойством уникальности обладает, по крайней мере, полный набор его атрибутов. Однако в формальном определении первичного ключа требуется обеспечение его «минимальности», т. е. в набор атрибутов первичного ключа не должны входить такие атрибуты, которые можно отбросить без ущерба для основного свойства – однозначного определения кортежа. Немного позже мы покажем, почему свойство минимальности первичного ключа является критически важным. Понятно, что если у любого отношения существует набор атрибутов, обладающий свойством уникальности, то существует и минимальный набор атрибутов, обладающий свойством уникальности. Конечно, могут существовать значения отношения с несколькими несовпадающими минимальными наборами атрибутов, обладающими свойствами уникальности. Например, если вернуться к предположениям лекции 1 об уникальности значений атрибутов слу_номер и слу_имя отношения служащие, то для каждого значения этого отношения мы имеем два множества атрибутов, претендующих на звание первичного ключа – {слу_номер} и {слу_имя}. В этом случае проектировщик базы данных должен решить, какое из альтернативных множеств атрибутов назвать первичным ключом, а остальные минимальные наборы атрибутов, обладающие свойством уникальности, называются возможными ключами1). Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных. Заметим, что хотя формально существование первичного ключа значения отношения является следствием того, что тело отношения – это множество, на практике первичные (и возможные) ключи переменных отношений появляются в результате явных указаний проектировщика отношения. Определяя переменную отношения, проектировщик моделирует часть предметной области, данные из которой будет содержать база данных. И конечно, проектировщик должен знать природу этих данных. Например, ему должно быть известно, что никакие два служащих ни в какой момент времени не могут иметь удостоверение с одним и тем же номером. Поэтому он может (и даже должен, как будет показано немного позже) явно объявить {слу_номер} возможным ключом. Если на предприятии установлено, что у всех служащих должны быть разные полные имена, то проектировщик может (и опять же должен) объявить возможным ключом и {слу_имя}. Затем проектировщик должен оценить, какой из возможных ключей является более надежным (свойство его уникальности никогда не будет отменено) и выбрать наиболее надежный возможный ключ в качестве первичного (в нашем случае естественным выбором был бы ключ {слу_номер}, потому что решение об уникальности полных имен служащих выглядит искусственным и может быть легко отменено руководством предприятия). Теперь поясним, почему проектировщику следует явно объявлять первичный и возможные ключи переменных отношений2). Дело в том, что в результате этого объявления СУБД получает информацию, которая в дальнейшем будет использоваться как ограничения целостности3). СУБД никогда не допустит появления в переменной отношения значения-отношения, содержащего два кортежа с одинаковым значением атрибута слу_номер (определение первичного ключа для данной переменной отношения отменить нельзя). Появление двух кортежей с одинаковым значением атрибута слу_имя будет также невозможно до тех пор, пока остается в силе определение {слу_имя} как возможного ключа. Тем самым объявления первичного и возможных ключей дают СУБД возможность поддерживать целостность базы данных даже в случае попыток занесения в нее некорректных данных. Наконец, вернемся к свойству минимальности первичного и возможных ключей. Как отмечалось выше, это свойство является критически важным, и важность проявляется именно при трактовке первичного и возможных ключей как ограничений целостности. В нашем примере с отношением служащие свойством уникальности будет обладать не только множество атрибутов {слу_номер}, но и, например, множество {слу_номер, слу_отд_номер}. Но если бы мы выставили в качестве ограничения целостности требование уникальности {слу_номер, слу_отд_номер}, то СУБД гарантировала бы отсутствие кортежей с одинаковым значением атрибута слу_номер не во всем значении отношения служащие, а только в группах кортежей с одним и тем же значением атрибута слу_отд_номер. Понятно, что это не соответствует смыслу моделируемой предметной области. Забегая вперед, заметим, что во многих практических реализациях реляционных СУБД допускается нарушение свойства уникальности кортежей для промежуточных отношений, порождаемых неявно при выполнении запросов. Такие отношения являются не множествами, а мультимножествами, что в ряде случаев позволяет добиться определенных преимуществ, но часто приводит к серьезным проблемам. Мы остановимся на этом подробнее при обсуждении языка SQL. 1.3. Отсутствие упорядоченности кортежей Конечно, формально свойство отсутствия упорядоченности кортежей в значении отношения также является следствием определения тела отношения как множества кортежей. Однако на это свойство можно взглянуть и с другой стороны. Да, то обстоятельство, что тело отношения является множеством кортежей, облегчает построение полного механизма реляционной модели данных, включая базовые средства манипулирования данными – реляционные алгебру и исчисление. Но, на мой взгляд, основная причина не в этом. Достаточно часто у пользователей реляционных СУБД и разработчиков информационных систем вызывает раздражение тот факт, что они не могут хранить кортежи отношений на физическом уровне в нужном им порядке. И ссылки на требования реляционной теории здесь не очень уместны. Можно было бы разработать другую теорию, в которой допускались бы упорядоченные «отношения». Однако хранить упорядоченные списки кортежей в условиях интенсивно обновляемой базы данных гораздо сложнее технически, а поддержка упорядоченности влечет за собой существенные накладные расходы. Отсутствие требования к поддержанию порядка на множестве кортежей отношения придает СУБД дополнительную гибкость при хранении баз данных во внешней памяти и при выполнении запросов к базе данных. Это не противоречит тому, что при формулировании запроса к БД, например, на языке SQL можно потребовать сортировки результирующей таблицы в соответствии со значениями некоторых столбцов. Такой результат, вообще говоря, является не отношением, а некоторым упорядоченным списком кортежей, и он может быть только окончательным результатом, к которому уже нельзя адресовать запросы. ГЛАВА 2. ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ 2.1. Теория о проектировании бд (erd) Проектирование баз данных — процесс создания схемы базы данных и определения необходимых ограничений целостности. Рисунок 2.1 - Пример концептуальной схемы Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности. Конкретный вид и содержание концептуальной модели базы данных определяется выбранным для этого формальным аппаратом. Обычно используются графические нотации, подобные ER-диаграммам. Чаще всего концептуальная модель базы данных включает в себя: • описание информационных объектов или понятий предметной области и связей между ними. • описание ограничений целостности, то есть требований к допустимым значениям данных и к связям между ними. Рисунок 2.2 - Пример логической схемы для реляционной модели данных. Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи. Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. Этот этап может быть в значительной степени автоматизирован. На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД. Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д. 2.2 Построение диаграммы вариантов использования На первом этапе пред проектные исследования выяснено, что основная задача разрабатываемой системы - сопровождение процесса. Диаграмма вариантов использования представлена на картинке ниже: Рисунок 2.3 — Диаграмма вариантов использования Как видно из диаграммы, у посетителя есть возможность заказать билет. При этом у него есть возможность просмотреть каталог фильмов и список кинотеатров, в которых показывают соответствующий фильм. Либо выбрать из списка удовлетворяющий критериям кинотеатр, и просмотреть, какие фильмы в нем показывают. Ниже представлена диаграмма последовательности действий: Рисунок 2.4 — Диаграмма последовательности действий Через интерфейс можно получить любую интересующую информацию по фильму или кинотеатру. Выбрав фильм, можно получить всю информацию о нем (жанр, рейтинг, цену на билет, продолжительность), а так же список кинотеатров, в которых показывают данный фильм. Из списка можно так же выбрать подходящий кинотеатр и узнать всю информацию о нем (адрес, название, число мест, акустическая система, формат экрана). 2.3 Построение диаграммы классов На рисунке ниже представлена диаграмма классов: Рисунок 2.5 — Диаграмма классов Исходя из диаграммы последовательности действий, мы получим 2 класса: Фильм и Кинотеатр. В класс Фильм входят 6 атрибутов, из которых атрибут ID_фильма является идентификационным номером фильма. Класс Кинотеатр имеет также 6 атрибутов, в котором ID_кинотеатра является его идентифицирующим номером. Классы соединены между собой отношением «Многие ко многим». 2.4. Проектирование реляционной модели базы данных Возьмем за правило считать классы сущностями. Объектной модели можно сопоставить модели данных из-за постоянного характера классов. Стойкие классы могут выступать в качестве постоянного хранения данных во время работы приложения. Следовательно, для всех постоянных классов можно применить утверждение, что они могут использовать однозначное отображение в сущностях. Этот процесс называется «Маппирование» (от. англ. Mapping). Тогда отношения Фильм и Кинотеатр, выявленные на этапе построения концептуальной модели характеризуются следующими атрибутами (табл. 2.5.1) Таблица 2.1 - Атрибуты отношения «Фильм» Атрибут Описание ID_фильма Первичный ключ Название_фильма Название фильма Длительность Жанр Рейтинг Цена билета Длительность фильма Жанр фильма Рейтинг фильма Цена билета Отношению Фильм соответствует полная ФЗ: ID_фильма > Название фильма, длительность, жанр, рейтинг, цена билета. Все поля кроме «ID_фильма» не могут быть первичным ключом. Таблица 2.2 - Атрибуты отношения «Кинотеатр» Атрибут Описание ID_кинотеатра Первичный ключ Адрес Адрес кинотеатра Название_кинотеатра Число_мест Акустическая_система Формат_экрана Название кинотеатра Число мест Акустическая система Формат экрана Отношению Кинотеатр соответствует полная ФЗ: ID_кинотеатра > адрес, название кинотеатра, число мест, акустическая система, формат экрана. Все поля кроме «ID_кинотеатра» не могут быть первичным ключом. Анализ функциональных зависимостей, которые имеют место для отношений Фильм и Кинотеатр показывает, что они полные. Следовательно, универсальное отношение Кинотеатр-Фильм нормализовано. Сущности Фильм и Кинотеатр соединены связью «многие ко многим» (М:N). Мощность связи многие-ко-многим означает неоднозначность связи экземпляров сущностей. Для разрешения этой проблемы вводим составную сущность ids. Она состоит из первичных ключей соединяемых сущностей. Окончательная реляционная модель базы данных выглядит следующим образом: Рисунок 2.6 – Реляционная модель базы данных 2.5. Мапирование реляционной модели в метамодель Классической методикой проектирования баз данных является создание отдельной таблицы для каждой описываемой моделью данных сущности. Такой подход хорошо работает для БД с относительно небольшим количеством описываемых объектов и при несложных и статичных связях между ними. Однако любое изменение структуры хранимых данных приводит к внесению изменений в структуру таблиц, отображающих эти данные. Несложная на этапе разработки, эта операция становится крайне проблематичной при больших объемах данных и при отсутствии у разработчика непосредственного доступа к БД (например, если она находится у заказчика).
Не смогли найти подходящую работу?
Вы можете заказать учебную работу от 100 рублей у наших авторов.
Оформите заказ и авторы начнут откликаться уже через 5 мин!
Похожие работы
Курсовая работа, Информационные технологии, 40 страниц
480 руб.
Курсовая работа, Информационные технологии, 84 страницы
1000 руб.
Курсовая работа, Информационные технологии, 41 страница
500 руб.
Курсовая работа, Информационные технологии, 24 страницы
350 руб.
Курсовая работа, Информационные технологии, 28 страниц
336 руб.
Служба поддержки сервиса
+7(499)346-70-08
Принимаем к оплате
Способы оплаты
© «Препод24»

Все права защищены

Разработка движка сайта

/slider/1.jpg /slider/2.jpg /slider/3.jpg /slider/4.jpg /slider/5.jpg