Кинотеатр база данных: База данных Access “Кинотеатр” – пример курсовой работы

Разработка базы данных «Кинотеатр» – Информационные технологии, Курсовая работа

ГЛАВА 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. Мапирование реляционной модели в метамодель Классической методикой проектирования баз данных является создание отдельной таблицы для каждой описываемой моделью данных сущности. Такой подход хорошо работает для БД с относительно небольшим количеством описываемых объектов и при несложных и статичных связях между ними. Однако любое изменение структуры хранимых данных приводит к внесению изменений в структуру таблиц, отображающих эти данные. Несложная на этапе разработки, эта операция становится крайне проблематичной при больших объемах данных и при отсутствии у разработчика непосредственного доступа к БД (например, если она находится у заказчика).

Курсовая на тему Проектирование и разработка БД «Кинотеатр»

Реальная база готовых
студенческих работ

Цены в 2-3 раза ниже

Мы работаем
7 дней в неделю

Только проверенные эксперты

Готовые работы / Курсовые работы / Базы данных и экспертные системы / Проектирование и разработка БД «Кинотеатр»

Что найти?

---

---

Введение

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

---

Похожие работы

Краткое описание предметной области
Курсовая, Базы данных и экспертные системы

Смотреть

Разработка реляционной базы данных «Библиотека»
Курсовая, Базы данных и экспертные системы

Смотреть

Разработка базы данных
Курсовая, Базы данных и экспертные системы

Смотреть

Разработка базы данных «Продажа билетов»
Курсовая, Базы данных и экспертные системы

Смотреть

Разработка базы данных «Продажа билетов»
Курсовая, Базы данных и экспертные системы

Смотреть

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

1 000 +

Новых работ ежедневно

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

109826
рейтинг

2702
работ сдано

1237
отзывов

103723
рейтинг

5277
работ сдано

2375
отзывов

74482
рейтинг

1858
работ сдано

1172
отзывов

62710
рейтинг

1046
работ сдано

598
отзывов

Тип работыВыберите тип работыКонтрольнаяРешение задачКурсоваяРефератОнлайн-помощьТест дистанционноЛабораторнаяЧертежЭссеОтветы на билетыПеревод с ин. языкаДокладСтатьяБизнес-планПодбор литературыШпаргалкаПоиск информацииРецензияДругое

Антон

ПГУ

Спасибо Вам, Екатерина, работа выполнена досрочно на оценку 4, побольше бы таких исполнителей?

Лиза

МПГУ

Отличный, не первый, опыт работы с Анастасией! Все быстро, четко и качественно! Спасибо ог. ..

Ксения

Университет им.Пушкина

Благодарна за помощь в работе, уже не первый раз ,Виктория выручает меня!!! Спасибо!

Спасибо Вам, Екатерина, работа выполнена досрочно на оценку 4, побольше бы таких исполнителей?

---

Антон

ПГУ

Отличный, не первый, опыт работы с Анастасией! Все быстро, четко и качественно! Спасибо огромное!

---

Лиза

МПГУ

Благодарна за помощь в работе, уже не первый раз ,Виктория выручает меня!!! Спасибо!

---

Ксения

Университет им.Пушкина

Ежедневно эксперты готовы работать над 1000 заданиями. Контролируйте процесс написания работы в режиме онлайн

2 минуты назад

3 минуты назад

10 минут назад

10 минут назад

10 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

11 минут назад

Закажи индивидуальную работу за 1 минуту!

---

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

Кинотеатры – Сокровища кино

• Кинотеатры
• Select country…—United StatesUnited KingdomCanadaAustralia—AfghanistanAlbaniaAlgeriaAmerican SamoaAndorraAngolaAntigua and BarbudaArgentinaArmeniaArubaAustraliaAustriaAzerbaijanBahamasBahrainBangladeshBarbadosBelarusBelgiumBelizeBeninBermudaBhutanBoliviaBosnia and HerzegovinaBotswanaBrazilBrunei DarussalamBulgariaBurkina FasoCambodiaCameroonCanadaCape VerdeCayman IslandsChadChileChinaChristmas IslandCocos (Keeling) IslandsColombiaComorosCongo (Kinshasa)Cook IslandsCosta RicaCroatiaCubaCyprusCzech RepublicCôte d’IvoireDenmarkDjiboutiDominicaDominican RepublicEcuadorEgyptEl SalvadorEritreaEstoniaEthiopiaFalkland IslandsFaroe IslandsFijiFinlandFranceFrench GuianaFrench PolynesiaGabonGambiaGeorgiaGermanyGhanaGibraltarGreeceGreenlandGrenadaGuadeloupeGuamGuatemalaGuernseyGuineaGuinea-BissauGuyanaHaitiHondurasHong KongHungaryIcelandIndiaIndonesiaIranIraqIrelandIsle of ManIsraelItalyJamaicaJapanJerseyJordanKazakhstanKenyaKiribatiKuwaitKyrgyzstanLaosLatviaLebanonLibyaLiechtensteinLithuani aLuxembourgMacedoniaMadagascarMalaysiaMaldivesMaliMaltaMarshall IslandsMartiniqueMauritiusMexicoMicronesiaMoldovaMonacoMongoliaMontenegroMoroccoMozambiqueMyanmarNamibiaNepalNetherlandsNetherlands AntillesNew CaledoniaNew ZealandNicaraguaNigeriaNorfolk IslandNorth KoreaNorthern Mariana IslandsNorwayOmanPakistanPalestinePanamaPapua New GuineaParaguayPeruPhilippinesPolandPortugalPuerto RicoQatarReunionRomaniaRussian FederationRwandaSaint Helena, Ascension, and Tristan da CunhaSaint Kitts and NevisSaint LuciaSamoaSan MarinoSaudi ArabiaSenegalSerbiaSeychellesSingaporeSlovakiaSloveniaSomaliaSouth AfricaSouth KoreaSpainSri LankaSudanSurinameSwazilandSwedenSwitzerlandSyriaTaiwanTajikistanTanzaniaThailandTimor-LesteTogoTongaTrinidad and TobagoTunisiaTurkeyTurks and Caicos IslandsUgandaUkraineUnited Arab EmiratesUnited KingdomUnited StatesUruguayUzbekistanVanuatuVenezuelaVietnamVirgin Islands (British)Virgin Islands (U. S.) ЙеменЗамбияЗимбабве

Мы создаем крупнейший в мире путеводитель по кинотеатрам.

У нас более 58 000 кинотеатров от Соединенные Штаты, Соединенное Королевство, Австралия,
Канада, и десятки других стран мира.

Найдите ближайший к вам кинотеатр:

Сети популярных кинотеатров

Просмотреть все 1391 сеть кинотеатров »

Популярные кинотеатры

Просмотреть все 57 837 кинотеатров »

Кинотеатры для автомобилей

Просмотреть все 5 902 кинотеатра »

Фотографии кинотеатров

Изучите нашу огромную базу фотографий кинотеатров:

Просмотреть все 322 953 фотографии кинотеатра »

Популярные страны с кинотеатрами

Великобритания, Канада, Австралия, Новая Зеландия, Франция, Германия, Китай, Бразилия

Популярные города с кинотеатрами

Нью-Йорк, Лос-Анджелес, Чикаго, Сиэтл, Сидней, Лондон, Париж, Берлин, Остин

Дополнительные способы просмотра кинотеатров

Стили

Арт-деко, Искусство модерн, Атмосферный, изящные искусства, Египетский

Архитекторы

Джон Эберсон, Томас Лэмб, С. Чарльз Ли, Роберт О. Боллер, Юджин ДеРоса

Архитектурная фирма

Рэпп и Рэпп, Братья Боллер, Кантин и Кантин, Пфлюгер Архитекторы

Функции

Живые выступления, Живой театр, Исполнительское искусство, Ночной клуб, Розничная торговля

Статус

Открытым, Ремонт, восстановление, Закрыто, Снесен, Показ фильмов

Количество экранов

Один экран, Близнец, Триплекс, Четырехместный, 5, 6, 7, 8, 9, 10, 12, 14, 18, 20, 24, 30

Количество мест

1-999, 1000-1999, 2000-2999, 3000-3999, 4000-4999, 5000-5999, 6000-6999

Цепи

АМС, Кармайк, Синема, Киноплекс, Ориентир, Кинотаверна, Одеон

База данных полнометражных фильмов – Cineuropa

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