 |
Программные системы бронирования и базы данных
|
|
|
|
Правильная и своевременная обработка информации о резервировании имеет решающее значение для успеха как цепей гостиниц, так и для независимых предприятий. Резервирование может производиться для индивидуальных постояльцев, групп, тур агентств и для организации конференций. Каждый запрос на размещение требует точного ответа в соответствии с указанным в запросе типом комнаты, ценой номера и датой заселения – компьютерные системы позволяют эффективно выполнять все эти задачи за минимальное время.
Компьютерные системы для служб по работе с гостями на различных предприятиях ИГ могут значительно отличаться друг от друга, так как на их конфигурацию оказывают влияние особенности функционирования того или иного конкретного предприятия - гостиницы, мотеля и т.д. Программы, входящие в состав компьютерной системы, объединены в структурные единицы - модули. Модуль - это группа программ, выполняющая операции, относящиеся к определенной процедуре работы гостиничного предприятия (резервирование, поселение, расчет и т.д.). Одним из основных модулей по работе с гостями является модуль «Бронирование».
Модуль «Бронирование» («Резервирование») создан для выполнения функции бронирования гостиничных мест и работает в режиме подтверждение/отказ с привязкой ко времени. Модуль «Бронирование» позволяет службе приема заказов быстро обрабатывать информацию в соответствии с запросами гостей, вовремя готовить комнаты, а также составлять прогнозы и заполнять отчеты о прибыли. Заказы на резервирование номеров, полученные либо через центральную систему резервирования, либо непосредственно от клиента, могут быть обработаны, подтверждены и соответствующим образом оформлены даже до того, как работник службы резервирования закончит телефонный разговор о заказе номера. Информация о наличии мест отражается на дисплеях компьютерной сети гостиницы, которая может быть включена в общую систему бронирования гостиничной цепи или работать автономно. Система управления гостиничным предприятием вне зависимости от конфигурации осуществляет накопление данных в автоматическом режиме и способна в доли секунды выдавать по желанию оператора информацию о свободных и занятых номерах и доходе на определенную заявленную оператором дату как в прошлом, так и в будущем. Когда гостиница использует модуль «Бронирование», служба резервирования либо вводит новые данные, либо получает их от компьютера центральной системы резервирования. После этого данные, находящиеся в записях файлов о клиентах, файлов прогнозов загруженности, ожидаемой прибыли тотчас же обновляются[6].
|
|
|
Внутренние системы резервирования (то есть такие системы, которые непосредственно работают на гостиничных предприятиях) специально разработаны с учетом специфических нужд гостиничной индустрии. Эти системы управляют деятельностью отеля, с уважением относясь к нуждам гостей, сотрудников и менеджмента. Специфическими нуждами и требованиями каждого отдельного отеля определяется, закупается ли оборудование для системы резервирования отдельно, или же оно закупается и затем работает как часть общей системы управления отелем.
Модуль резервирования компьютерной системы управления отелем позволяет сотрудникам быстро и четко отвечать на телефонные звонки с заявками на размещение. Модуль значительно сокращает бумажную работу, необходимость физической обработки информации и другие канцелярские процедуры. Это дает возможность сотрудникам уделять больше персонального внимания позвонившим и для продвижения различных услуг, предлагаемых отелем. Доступ к информации намного ускоряется, а многие процедуры, связанные с обработкой заявок, модификацией информации и получением подтверждений - упрощаются[7].
|
|
|
Первоначальная процедура составления запроса создает запись о резервировании, которая является началом отельного цикла гостя. Запись о резервировании идентифицирует гостя и его нужды до того, как он прибудет в отель, и позволяет отелю персонифицировать сервис и оптимизировать график работы персонала. Кроме того, Модуль резервирования может составлять отчеты, необходимые для менеджеров. Ниже перечислены наиболее типичные функции, присваиваемые модулю резервирования. К этим функциям относятся:
. Запросы на резервирование
. Обоснование готовности номеров к сдаче
. Создание записей о резервировании
. Подтверждение резервирований
. Поддержание записей о резервировании
. Создание отчетов
Заявка на резервирование может быть получена лично, по телефону, по почте или через интерфейс внешней системы резервирования. Вне зависимости от происхождения, заявка на резервирование переформулируется работником службы бронирования в запрос на резервирование. Этот запрос обычно содержит следующую информацию:
. Дата прибытия
. Тип и количество требующихся комнат
. Количество ночей
. Код расценки номера (стандартный, специальный, пакет услуг и т.д.)
. Количество человек в номере
Сотрудник, принимающий резервирование, вводит эти данные в компьютер в соответствии с четко определенной процедурой запроса. Одновременность обработки данных позволяет достичь совместимости с реальным временем. Это означает, что сотрудник, принимающий заявку, получает необходимую информацию от системы для того, чтобы ответить на заявку позвонившего клиента в течение телефонного разговора. Во многих модулях резервирования совместимость с реальным временем создана для того, чтобы обеспечить быстрый ответ (в пределах пяти секунд) и, таким образом, дать возможность сотруднику отредактировать, изменить или улучшить запрос, пока позвонивший еще может дать свои комментарии. Как только запрос согласован с данными о номерах, доступных к продаже, PMS (property management system – система управления гостиничным предприятием) записывает и блокирует этот номер, исключая его из файла номеров, доступных к продаже.
|
|
|
В момент введения в компьютер запрос на резервирование сравнивается с данными о наличии свободных номеров в соответствии с алгоритмом, заданным системе. Алгоритм - это компьютерная формула, созданная для продажи номеров в соответствии со специфическим образцом (по зонам, этажам, блокам и т.д.).
На запрос о резервировании система может дать следующие ответы, которые появятся на экране дисплея:
. Принятие или отказ в принятии запроса на резервирование
. Предложение альтернативных вариантов типа номеров или расценки
. Предложение остановиться в другом отеле
Как только заявка на резервирование получена и номер заблокирован, система требует, чтобы работник службы бронирования заполнил запись о резервировании, введя необходимую информацию, такую как:
. Персональные данные гостя (имя, адрес, номер телефона)
. Время прибытия
. Классификация резервирования (предварительное, подтвержденное, гарантированное)
. Данные позвонившего (агентство или секретарь)
. Специальные требования (усовершенствование условий, детская кроватка, зона для некурящих и т.д.)
В неавтоматизированных отелях обычно требуется, чтобы эта информация была получена раньше в процессе резервирования. Однако, компьютеризированная система резервирования не требует лишней работы при сборе этой второстепенной информации. Часто это оказывается удобнее как для лиц, совершающих заказ, так и для персонала отеля. Например, если после получения всей этой информации система отказала в принятии заказа, окажется, что работник службы бронирования и гость потратили время на сбор информации, которая затем не пригодилась.
Система управления отелем может автоматически составлять письма о подтверждении резервирования в день получения заказа на резервирование.
Информация может быть получена из записи о резервировании и распечатана на специальном бланке отеля. Хотя, вероятно, существует столько видов письма о подтверждении, сколько существует автоматизированных отелей, письмо о подтверждении обычно содержит следующую информацию:
|
|
|
. Имя и адрес гостя
. Время и дату прибытия
. Тип, количество и стоимость номеров
. Количество ночей
. Количество человек в группе
. Классификация резервирования (предварительное, подтвержденное, гарантированное)
. Специальный сервис, необходимый гостям
. Требование депозита или предоплаты
. Изменение первоначального резервирования (дополнительное подтверждение, изменение или отмена)
. Возможность отмены заказа
. Цена за номер за ночь
Подтверждения резервирования могут быть отпечатаны в любое время.
Однако, обычно они печатаются как часть потока продукции, производимой во время ежедневной модификации системы. Обновление данных в системе выполняет многие функции ночного аудита, производимого в неавтоматизированных отелях. Модификация системы проводится ежедневно с целью составления отчетов, реорганизации системных файлов, поддержания системы и обеспечения временных рамок конца дня.
Записи о резервировании хранятся в электронных файлах, разделенных по времени прибытия гостей (год, месяц, день), названию группы, имени гостя. Такая организация файлов и метод исправления файлов наиболее подходит для оптимизации работы модуля резервирования, поскольку гости часто приезжают раньше установленной даты, изменяют дату, отменяют заказ или подтверждают его повторно. Например, если клиент хочет отменить заказ, работник службы бронирования должен быстро получить доступ к нужной записи о резервировании, изменить ее и сделать отмену[8].
Информация из записей о резервировании может быть использована для создания бланков предварительной регистрации.
Кроме того, модуль резервирования может взаимодействовать с другими функциями службы приема. Информация о резервировании может быть использована следующим образом:
. Распечатана на карточках для увеличения скорости процедуры прописки
. Использована как база для распечатывания фолио гостей для внутреннего пользования отеля и листа информации о гостях
(который может быть составлен в алфавитном порядке или в соответствии с номерами комнат)
. Переправлена для дальнейшей обработки в файл о комиссионных для агентов
. Переформатирована для включения в файл истории гостя
Так же как и многие другие компьютерные программы, количество и вид отчетов по модулю резервирования функционально связаны с нуждами пользователя, возможностями программного обеспечения и содержанием базы данных. Внутренний модуль резервирования отеля разрабатывается с целью максимизации продажи номеров путем тщательного мониторинга количества свободных номеров и предоставления детального прогноза дохода от сдачи номеров. Компьютерный отчет о количестве свободных номеров показывает ежедневное количество свободных номеров каждого типа (оставшиеся номера в каждой категории).
|
|
|
Отчет о предполагаемых доходах показывает будущие доходы, умножая предсказываемую занятость в будущем на существующие в отеле расценки.
Заменивший неавтоматизированную систему резервирования, модуль резервирования может так же составлять и другие отчеты:
. Отчет о сделках по резервированию
. Список предполагаемых прибытий и отбытий
. Отчет о комиссионных агентам
. Статистика отказов
Отчет о сделках по резервированию предоставляет информацию о ежедневных записях по принятию, изменению или отмене резервирования. Модуль резервирования может также составлять дополнительные специализированные отчеты, например, отчет об отказах, отчет о заблокированных номерах, отчет о не появившихся клиентах.
Список предполагаемых прибытий и отбытий - это ежедневный отчет, который показывает количество гостей, которые должны прибыть или выехать из отеля, количество гостей, продливших свое пребывание в отеле (отдельно от списка прибытий и отбытий), а также имена гостей, соответствующие каждой сделке.
Отчет о комиссионных агентам обрисовывает сделки по резервированию и суммы комиссионных, которые следует выплатить агентам с этих сделок.
Агенты, связанные контрактными соглашениями с отелем, могут зарабатывать комиссионные на сделках по резервированию, совершенных в пользу отеля.
Отчет по отказам показывает количество номеров, снятых за ночь с продажи из-за того, что номера не были подготовлены к сдаче. Этот отчет особенно полезен для отелей, имеющих планы на расширение своей деятельности.
В заключении третьего параграфа можно сказать, что программные системы бронирования значительно облегчают работу менеджеров, позволяют быстро и точно обрабатывать заявки, создавать отчеты, что в итоге дает возможность быстро и качественно обслужить клиентов гостиницы. Однако, все программные системы требуют определенной доработки и усовершенствования, о чем будет рассказано в третьей главе.
База данных - это совокупность описаний объектов реального мира и связей между ними, актуальных для конкретной прикладной области. В дальнейшем мы будем исходить из этого определения, уточняя его по ходу изложения.
Одним из основных преимуществ реляционного подхода к организации баз данных (БД) является то, что пользователи реляционных БД получают возможность эффективной работы в терминах простых и наглядных понятий таблиц, их строк и столбцов без потребности знания реальной организации данных во внешней памяти.
Реляционная модель данных, содержащая набор четких предписаний к базовой организации любой реляционной системы управления базами данных (СУБД), позволяет пользователям работать в ненавигационной манере, т.е. для выборки информации из БД человек должен всего лишь указать список интересующих его таблиц и те условия, которым должны удовлетворять выбираемые данные. СУБД скрывает от пользователя выполняемые ей последовательные просмотры таблиц, выполняя их наиболее эффективным образом. Очень важная особенность реляционных систем состоит в том, что результатом выполнения любого запроса к таблицам БД является также таблица, которую можно сохранить в БД и/или по отношению к которой можно выполнять новые запросы.
Базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции.
В базах данных используются таблицы, запросы, поля.
Таблицы - это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).
Запросы. Эти объекты служат для извлечения данных из таблиц и предоставления их пользователю в удобном виде. С помощью запросов выполняют такие операции как отбор данных, их сортировку и фильтрацию. С помощью запросов можно выполнять преобразования данных по заданному алгоритму, создавать новые таблицы, выполнять автоматическое наполнения таблиц данными, импортированными из других источников, выполнять простейшие вычисления в таблицах и многое другое.
Поля базы данных не просто определяют структуру базы - они еще определяют групповые свойства данных, записываемых в ячейки, принадлежащие каждому из полей. Ниже перечислены основные свойства полей таблиц баз данных на примере СУБД Microsoft Access.
Имя поля - определяет, как следует обращаться к данным этого поля при автоматических операциях с базой (по умолчанию имена полей используются в качестве заголовков столбцов таблиц).
Тип поля - определяет тип данных, которые могут содержаться в данном поле.
Размер поля - определяет предельную длину (в символах) данных, которые могут размещаться в данном поле.
Формат поля - определяет способ форматирования данных в ячейках, принадлежащих полю.
Маска ввода - определяет форму, в которой вводятся данные а поле (средство автоматизации ввода данных).
Подпись - определяет заголовок столбца таблицы для данного поля (если подпись не указана, то в качестве заголовка столбца используется свойство Имя поля).
Значение по умолчанию - то значение, которое вводится в ячейки поля автоматически (средство автоматизации ввода данных).
Условие на значение - ограничение, используемое для проверки правильности ввода данных (средство автоматизации ввода, которое используется, как правило, для данных, имеющих числовой тип, денежный тип или тип даты).
Сообщение об ошибке - текстовое сообщение, которое выдается автоматически при попытке ввода в поле ошибочных данных.
Обязательное поле - свойство, определяющее обязательность заполнения данного поля при наполнении базы.
Пустые строки - свойство, разрешающее ввод пустых строковых данных (от свойства Обязательное поле отличается тем, что относится не ко всем типам данных, а лишь к некоторым, например к текстовым).
Индексированное поле - если поле обладает этим свойством, все операции, связанные с поиском или сортировкой записей по значению, хранящемуся в данном поле, существенно ускоряются. Кроме того, для индексированных полей можно сделать так, что значение в записях будут проверяться по этому полю на наличие повторов, что позволяет автоматически исключить дублирование данных.
Поскольку в разных полях могут содержаться данные разного типа, то и свойства у полей могут различаться в зависимости от типа данных. Так, например, список вышеуказанных свойств полей относится в основном к полям текстового типа. Поля других типов могут иметь или не иметь эти свойства, но могут добавлять к ним и свои. Например, для данных, представляющих действительные числа, важным свойством является количество знаков после десятичной запятой. С другой стороны, для полей, используемых для хранения рисунков, звукозаписей, видео клипов и других объектов OLE, большинство вышеуказанных свойств не имеют смысла.
Понятие тип данных в реляционной модели данных полностью адекватно понятию типа данных в языках программирования. Обычно в современных реляционных БД допускается хранение символьных, числовых данных, битовых строк, специализированных числовых данных (таких как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Достаточно активно развивается подход к расширению возможностей реляционных систем абстрактными типами данных (соответствующими возможностями обладают, например, системы семейства Ingres/Postgres).
Текстовые базы данных
Объектами хранения в текстовых БД являются тексты. Под текстом будут пониматься неструктурированные данные, построенные из строк. Основной целью любой текстовой БД является хранение, поиск и выдача документов, соответствующих запросу пользователя. Такие документы принято называть релевантными. Ввиду того, что автоматизированный поиск документов на естественных языках достаточно затруднен, возникает вопрос о проектировании некоторых формальных языков, предназначенных для отображения основного смыслового содержания документов и запросов в БД. Такие языки называют информационно-поисковыми. В настоящее время разработано достаточно большое количество информационно-поисковых языков, которые отличаются не только по своим изобразительным свойствам, но и по степени семантической силы. В основе подхода к построению классификационных языков лежит представление о том, что накопленные знания могут быть разделены на взаимоисключающие классы и подклассы. Существует система правил, которой должен подчиняться любой язык классификационного типа, в частности:
- Деление отраслей знаний на классы и подклассы проводится по одному
основанию;
- Подклассы должны исключать друг друга;
- При делении классов на подклассы должна соблюдаться непрерывность.
Информационно – поисковые языки, получившие название дескрипторных, основаны на применении принципов координатного индексирования, при котором смысловое содержание документа может быть с определенной степенью точности и полноты задано списком ключевых слов, содержащихся в тексте. Дескрипторные языки привязаны к лексике текстов. Ключевые слова из текстов выбираются исходя из разных целей, соответственно, критерии выбора могут различаться. Для построения дескрипторного языка критерием отбора ключевых слов, как правило, служат информативность слова и частота его встречаемости в тексте.
Универсальными структурами дескрипторного языка являются лексические единицы, парадигматические и синтагматические отношения.
Лексическая единица – наименьшая смысловая единица, задаваемая при построении языка. В большинстве автоматизированных информационных систем при индексировании документов и запросов применяется контроль с помощью тезауруса. Контроль может осуществляться в автоматизированном или ручном режиме. По сути дела тезаурус представляет собой словарь – справочник, в котором присутствуют все лексические единицы дескрипторного информационно поискового языка с введенными парадигматическими отношениями. Парадигматические отношения могут задаваться как:
· Отношения вид – род (вышестоящий дескриптор);
· Отношения род – вид (нижестоящие дескрипторы);
· Синонимы;
· Ассоциативные связи
В тезаурусы помещаются дескрипторы и недескрипторы, хотя существуют тезаурусы только из дескрипторов. Как дескрипторы, так и недескрипторы приводят к единой грамматической форме. Как правило, дескрипторы употребляются в форме существительных или именныхсловосочетаний. Тезаурус может быть построен по принципу дескрипторных статей, состоявших из заглавного дескриптора и списка дескрипторов и недескрипторов с обозначением парадигматических отношений. Тезаурус может быть двуязычным. В этом случае эквивалентный дескриптор на иностранном языке должен быть обозначен.
Парадигматические отношения представляют собой внетекстовые отношения между лексическими единицами. На их основании происходит группировка лексических единиц в парадигмы.
Синтагматические отношения представляют собой отношения лексических единиц в тексте, т.е. они выражают семантику контекста. При переводе основного смыслового содержания документов и запросов с естественного языка на дескрипторный информационно – поисковый язык существуют определенные правила, называемые системой индексирования. Результатом перевода документа является поисковый образ документа, а запроса – поисковый образ запроса. Из перечисленных информационно – поисковых языков именно дескрипторные языки наилучшим образом приспособлены для описания документов и запросов при автоматизированном поиске в текстовых БД. Языки эти обладают таким преимуществом, как гибкость, открытость, близость к естественному языку; это языки двухуровневые (уровень ключевых слов и уровень дескрипторов). Дескрипторные информационно – поисковые языки позволяют формулировать документы и запросы в разных терминах. К основным недостаткам языков данного класса можно отнести недостаточную полноту описания смыслового содержания документов и запросов. Системы, контролируемые тезаурусом, содержат процедуры как морфологического, так и синтаксического анализа текстов. Однако при проектировании ряда БД возникает необходимость в добавлении еще одного этапа анализа текста на естественном языке – анализа его семантической структуры. Примером таких баз могут быть БД, ориентированные на поиск по образцам. В подобных семантических системах пытаются моделировать процесс понимания законченных описаний фрагментов действительности, например патентов, рассказов, эпизодов и др., выраженных в виде текстов. Как правило, понимание текста трактуется как процесс извлечения из него существенной с точки зрения системы информации. Извлеченная информация вводится в базу знаний, представляющую собой динамическую информационную модель реального мира. Затем система способна отвечать на запросы относительно событий, фактов, явлений, изложенных в текстах. Пакеты прикладных программ, предназначенные для ввода, обработки, поиска и обновления текстов, называют информационно-поисковой системой (ИПС).
Сетевые базы данных.
Одним из наиболее эффективных методов представления знаний являются сетевые модели. В основе моделей лежит понятие сети, вершинами которой являются понятия, соответствующие объектам, событиям, процессам, явлениям, а дугами – отношения между этими понятиями. Узлы и связи можно наглядно изображать в виде диаграмм. Если вершины сети не имеют своей внутренней структуры, то сеть будет простой Если же вершины обладают некоторой структурой в виде сети, то сеть называется иерархической. Если отношения между вершинами одинаковые, то сеть однородна, в противном случае – сеть неоднородна. Характер отношений, приписываемый дугам, может быть различен. В соответствии с этим выделяют следующие типы сетей:
· Функциональные сети отражают декомпозицию определенной вычислительной или информационной процедуры, а дуги показывают функциональную связь между декомпонированными частями; этот язык недостаточно богат для представления знаний;
· Сценарии, представляющие собой однородные сети с единственным отношением в виде нестрогого порядка. Семантика отношений может быть различной. Отношение может трактоваться как классифицирующее, временное и т.п. Сценарии часто используются при формировании допустимых планов по достижению цели;
· Семантические сети используют отношения разных типов, а вершины в них могут иметь разную интерпретацию, По сути дела семантическая сеть является классом, в который включаются как сценарии, так и функциональные сети. Наиболее часто используются в сети связи типа «это есть». Они позволяют построить в виде сети иерархию понятий, в которых узлы низших уровней наследуют свойства узлов более высоких уровней. Именно таким механизмом переноса свойств обусловлена эффективность семантических сетей.
Реляционные базы данных. Базы данных называются реляционными, если управление ими основано на математической модели, использующей методы реляционной алгебры и реляционного исчисления. С. Дейт дает следующее неформальное определение реляционных баз данных:
· Вся информация в базе данных представлена в виде таблиц.
· Поддерживаются три реляционных оператора – выбора, проектирования и объединения, с помощью которых можно получить любые необходимые данные, заложенные в таблицы. Доктор И.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «12 правилами Кодда», требует введения сложной терминологии и выходит за рамки дипломной работы. Тем не менее можно назвать некоторые правила Кодда для реляционных систем. Чтобы считаться реляционной по Кодду, система управления базами данных должна:
· Представлять всю информацию в виде таблиц;
· Поддерживать логическую структуру данных, независимо от их физического представления;
· Использовать язык высокого уровня для структурирования, выполнения запросов и изменения информации в базах данных;
· Поддерживать основные реляционные операции (выбор, проектирование и объединение), а также теоретико-множественные операции, такие как объединение, пересечение и дополнение;
· Поддерживать виртуальные таблицы, обеспечивая пользователям альтернативный способ просмотра данных в таблицах;
· Различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных;
· Обеспечивать механизмы для поддержки целостности, авторизации, транзакций и восстановления данных.
Первое правило Кодда гласит, что вся информация в реляционных базах данных представляется значениями в таблицах. В реляционных системах таблицы состоят из горизонтальных строк и вертикальных столбцов. Все данные представляются в табличном формате – другого способа просмотреть информацию в базе данных не существует. Набор связанных таблиц образует базу данных. Таблицы в реляционной базе разделены, но полностью равноправны. Между ними не существует никакой иерархии. Каждая таблица состоит из строк и столбцов. Каждая строка описывает отдельный объект или сущность – ученика, предмет, день недели или что-нибудь другое. Каждый столбец описывает одну характеристику объекта – имя или фамилию ученика, его адрес, оценку, дату. Каждый элемент данных, или значение, определяется пересечением строки и столбца. Чтобы найти требуемый элемент данных, необходимо знать имя содержащей его таблицы, столбец и значение его первичного ключа, или уникального идентификатора. В реляционной базе данных существует два типа таблиц – пользовательские таблицы и системные таблицы. Пользовательские таблицы содержат информацию, для поддержки которой собственно и создавались реляционные базы данных. Системные таблицы обычно поддерживаются самой СУБД, однако доступ к ним можно получить так же, как и к любым другим таблицам. Возможность получения доступа к системным таблицам, по аналогии с любыми другими таблицами, составляет основу другого правила Кодда для реляционных систем. Реляционная модель обеспечивает независимость данных на двух уровнях – физическом и логическом. Физическая независимость данных означает с точки зрения пользователя, что представление данных абсолютно не зависит от способа их физического хранения. Как следствие этого, физическое перемещение данных никоим образом не может повлиять на логическую структуру базы данных.
Другой тип независимости, обеспечиваемый реляционными системами - логическая независимость – означает, что изменение взаимосвязей между таблицами и строками не влияет на правильное функционирование программных приложений и текущих запросов. В определении системы управления реляционными базами данных упоминаются три операции по выборке данных – проектирование, выбор и объединение, которые позволяют строго указать системе, какие данные необходимо показать. Операция проектирования выбирает столбцы, операция выбора – строки, а операция объединения собирает вместе данные из связанных таблиц.
Виртуальные таблицы можно рассматривать как некоторую перемещаемую по таблицам рамку, через которую можно увидеть только необходимую часть информации. Виртуальные таблицы можно получить из одной или нескольких таблиц базы данных (включая и другие виртуальные таблицы), используя любые операции выбора, проектирования и объединения. Виртуальные таблицы, в отличие от «настоящих», или базовых таблиц, физически не хранятся в базе данных. В то же время необходимо осознавать, что виртуальные таблицы это не копия некоторых данных, помещаемая в другую таблицу. Когда вы изменяете данные в виртуальной таблице, то тем самым изменяете данные в базовых таблицах. В идеальной реляционной системе с виртуальными таблицами можно оперировать как и с любыми другими таблицами. В реальном мире на виртуальные таблицы накладываются определенные ограничения, в частности на обновление. Одно из правил Кодда гласит, что в истинно реляционной системе над виртуальными таблицами можно выполнять все «теоретически» возможные операции. Большинство современных систем управления реляционными базами данных не удовлетворяют этому правилу полностью. В реальном мире управления информацией данные часто являются неизвестными или неполными: неизвестен телефонный номер, не захотели указать возраст. Такие пропуски информации создают «дыры» в таблицах. Проблема, конечно, состоит не в простой неприглядности подобных дыр. Опасность состоит в том, что из-за них база данных может стать противоречивой. Чтобы сохранить целостность данных в реляционной модели, так же, как и в правилах Кодда, для обработки пропущенной информации используется понятие нуля.
«Нуль» не означает пустое поле или обычный математический нуль. Он отображает тот факт, что значение неизвестно, недоступно или неприменимо. Существенно, что использование нулей инициирует переход с двухзначной логики (да/нет) на трехзначную (да/нет/может быть). С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее они являются составной частью большинства официальных стандартов различных реляционных СУБД.
Целостность – очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы – проблемы с аппаратным обеспечением, ошибки в программном обеспечении или логической ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями. Другой тип целостности, называемый объектной целостностью, связан с корректным проектированием базы данных. Объектная целостность требует, чтобы ни один первичный ключ не имел нулевого значения. Третий тип целостности, называемой ссылочной целостностью, означает непротиворечивость между частями информации, повторяющимися в разных таблицах. Например, если вы изменяете неправильно введенный номер карточки страхового полиса в одной таблице, другие таблицы, содержащие эту же информацию, продолжают ссылаться на старый номер, поэтому необходимо обновить и эти таблицы. Чрезвычайно важно, чтобы при изменении информации в одном месте, она соответственно изменялась и во всех других местах. Кроме того, по определению Кодда, ограничения на целостность должны:
· Определяться на языке высокого уровня, используемом системой для всех
других целей;
· Храниться в словаре данных, а не в программных приложениях.
Эти возможности в том или ином виде реализованы в большинстве систем.
|
|
|
