
Проектирование базы данных "Ресторан"
Дипломная работа - Компьютеры, программирование
Другие дипломы по предмету Компьютеры, программирование
?ых ОСПриемлемоХорошоВозможности программированияПриемлемоОтличноХранимые процедуры и триггерыХорошоОтличноВнутренний язык программированияПриемлемоОтличноПостроение баз данныхХорошоОтличноЯзык SQLОтличноОтличноОбъектно-ориентированные системыПриемлемоОтличноТиражированиеОтличноОтличноРаспределенная обработка транзакцийОтличноОтличноДистанционное администрированиеХорошоОтличноОрганизация хранилищ данных и подготовка отчетовОтличноОтличноСредства загрузкиОтличноОтличноСредства анализаОтличноОтлично
3.2 Требования к СУБД
Выбор СУБД является одним из важных этапов при разработке приложений баз данных. Выбранный программный продукт должен удовлетворять как текущим, так и будущим потребностям предприятия, при этом следует учитывать финансовые затраты на приобретение необходимого оборудования, самой системы, разработку необходимого программного обеспечения на ее основе, а также обучение персонала. Кроме того, необходимо убедиться, что новая СУБД способна принести предприятию реальные выгоды. Очевидно, наиболее простой подход при выборе СУБД основан на оценке того, в какой мере существующие системы удовлетворяют основным требованиям создаваемого проекта информационной системы.
Более сложным и дорогостоящим вариантом является создание испытательного проекта на основе нескольких СУБД и последующий выбор наиболее подходящего. Но и в этом случае используются определенные критерии отбора. Перечень требований к СУБД может изменяться в зависимости от поставленных целей. Тем не менее можно выделить несколько групп критериев:
реализуемые режимы работы с БД ресторана и максимальное число пользователей одновременно обращающихся к базе, таких как заказчик, бухгалтер, повар;
модель данных (предусмотренные типы данных, средства поиска, реализация языка запросов, средства поддержания целостности базы данных);
особенности разработки приложений (средства проектирования, поддержка большого количества национальных языков, возможности разработки Web-приложений, поддерживаемые языки программирования);
производительность (Рейтинг TPC (Transactions per Cent) т. е. отношение количества запросов, обрабатываемых за некий промежуток времени, к стоимости всей системы, возможности параллельной обработки данных, возможности оптимизирования запросов);
надежность (сохранность информации при сбоях, обеспечение защиты данных от несанкционированного доступа);
требования к рабочей среде (минимальные требования к оборудованию, максимальный размер адресуемой памяти, операционные системы, под управлением которых способна работать СУБД);
требуемый уровень квалификации персонала ресторана;
смешанные критерии (качество и полнота документации, стоимость, стабильность производителя, распространенность СУБД).
4.Даталогическая (реляционная) модель БД
Даталогическая модель БД - модель логического уровня, представляющая собой отображение логических связей между элементами данных, независимо от их содержания и среды хранения.
На данном этапе даталогического проектирования строится логическая структура БД нашего ресторана. При этом происходит преобразование исходной инфологической модели (рис.2) в модель данных, которая поддерживается конкретной СУБД. После этого производится проверка адекватности даталогической модели, отображаемой предметной области. Конечным результатом даталогического проектирования является описание структуры БД на языке описания данных конкретных СУБД. Пример модели данных приведен на рис. 4.
Рисунок 4 - Даталогическая модель данных
5.Обеспечение целостности данных
.1 Типы ограничений целостности
Категорная целостность (целостность сущностей) значения первичного ключа любого отношения должны быть уникальны. СУБД должна отклонить любую попытку ввести в базу данных кортеж со значением первичного ключа, повторяющим уже имеющееся значение. Отношение, кроме первичного ключа, может содержать альтернативные ключи, значения которых также должны быть уникальными.
Обязательные данные. Некоторые атрибуты не могут иметь пустого значения.
1. Ограничения для доменов атрибутов. Каждый атрибут имеет домен, представляющий собой набор его допустимых значений. К ограничениям такого рода относятся:
. В заданном отношении для каждого кортежа между значениями полей А и В должно всегда выполняться условие, что первое больше второго. Ограничение специфицируется специальным выражением.
. Значения, которые принимает некоторый атрибут, должны быть ограничены специальным диапазоном. Ограничение специфицируется специальным выражением.
. Для некоторого атрибута или их комбинации может существовать конечный, весьма ограниченный набор допустимых значений. Ограничение специфицируется специальным выражением при описании данных.
. Значение некоторого атрибута должно удовлетворять определенному формату. Ограничение специфицируется специальной фразой при описании атрибута.
. Множество значений одного из атрибутов отношения должно удовлетворять статистическому условию. Например, конкретное значение не должно быть больше среднего более чем в два раза и т. п. Ограничение реализуется СУБД при контроле выполнения операций, в которых используются агрегатные функции. Множество значений некоторого столбца отношения является подмножеством значений другого