Введение в системы БД (542480), страница 14
Текст из файла (страница 14)
Начертите диаграмму "сушность-связь" для этой базы данных по образцу, представленному на рис. 1.5. Список литературы СогЫ Е.Р. Вага Моде!з ш ОагаЬазез Мапа8етепг 0 Ргос. %ог!сзЬор оп Васа АЬзггасгюп, ОагаЬазе апд Сопсергца! Моде!Нп8. — Ргпигее Раг!г, Со!о, )цпе, 1980. (АСМ 8!ОАКТ Хеез!ецег, — )апцагу, 1981, № 74; АСМ 8!ОМОВ Кесогд 11.— РеЬгцагу, 1981, № 2; АСМ 8!ОРЬАХ Хо!!сез 1б. — )апцагу, 1981, № ! .) Кодд является создателем реляционной модели, которую он впервые описал в !5.1!. Однако в этой работе он на самом деле не дал определения термину модель данных как таковому, оно было дано (гораздо позже) лишь в данной работе.
В ней рассматривается вопрос "Каково назначение моделей данных вообше н реляционной модели в частности?", а также приводятся факты, подтверждаюшие, что вопреки распространенному мнению реляционная модель фактически стала первой б1 Глава 1. Базы данных и управление ими Ответы к некоторым упражнениям Перечислим некоторые недостатки. 1.3. 1.б. Вариант а; тяг11ЧЕ РКОО11СЕК Е1пз апг(е! Вариант б: Ка1'апей1 Часть Х. Основные понятия !.2. 1.3. 1.4.
1.5. моделью данных, которая вообще была определена. (Иначе говоря, у Кодда есть право называться создателем концепции модели данных вообще, а также реляци- онной модели в частности.) Оаг яеп Н. %Ьаг а ОагаЬазе Кеайу 1з: Ргеб(сагез апд Ргорогййопз 0 Оаге С.1., Оагчгеп Н., апб Мсбочегап О. Ке!айопа! ОагаЬазе %г111пйз 1994-1997. — Кеаг((пй, Маках АгЫ(зоп-%ез!еу, 1998. В этой статье дается неформальное, но точное объяснение идеи (которая кратко обсуждалась в конце раздела 1.3), содержащей утверждение, что базу данных луч- ше представлять как набор истинных высказываний.
Оаге С.1. апб Норепей Р. Бгогайе 8ггпсгцгез апг! РЬугйса1 Оага 1пг(ерепг!епсе д Ргос. АСМ Б!ОГ!ОЕТ Мог!гзЬор оп Оага Оебппюп, Ассезз, апг( Сои!го!. — Бап О1ейо, СаИопца, НочегпЬег, 1971. Оаге С.1. апг( Нореггей Р. Рйе Оейп(г!оп апг! Ео81са! Оага !пг!ерепг!епсе 0 Ргос. АСМ Б!ОР(ОЕТ Мог!сзЬор оп Оага Оебп(1!оп, Ассезз, апд Сои!го!. — Кап О(ейо, СаИоппа, НочешЬег, 1971. Статьи [1.31, 11.41 являются первыми письменными работами, в которых было оп- ределено различие между физической и логической независимостью данных.
Оаге С.1. Ке!айоп ОагаЬазе %пп1пйз 1991-1994. — Кеаг(!п8, Маза.; АгЫ(зоп-%ез!еу, ! 995. ° Без надлежащего контроля зашита данных может оказаться ослабленной. ° Целостность данных может быть подвергнута риску (без надлежащего контроля). ° Может потребоваться дополнительное аппаратное обеспечение. ° Дополнительная нагрузка на вычислительную систему может оказаться весьма значительной. ° Успешное выполнение операции становится критически важным (предприятие может оказаться весьма уязвимым по отношению к сбоям системы).
° Система, вероятно, будет сложной (хотя такие сложности должны быть скрыты от конечного пользователя). Вариант е: Вариантж %'1ХЕ з'ЕАВ В!И№ СаЬ. Банч!Ноп 48 1993 1.7. Приведем решение только для п. ш "Компания КаГапе!Н является изготовителем вина с!пГапбеГ' или, более точно, "Некоторые ячейки содержат некоторые бутылки с вином УйпГапбе!, которое было изготовлено компанией Х!пГапбе! в некотором году, и онн будут готовы к употреблению в некотором году". Вариант ш добавление в таблицу СЕЬЬАК строки со значением 80 в поле 81М4.
1.8. Вариант б: удаление из таблицы СЕЬЬлК строк со значениями 45, 48, 64 и 72 в поле 81М4. Вариант е: количество бутылок (поле ВОТТЬЕЯ) устанавливается равным пяти для строки со значением 50 в поле 81М4. Вариантг: тоже, что и варианте. Кстати, обратите внимание, как удобно обрашаться к строкам по их первичному ключу !первичный ключ для таблицы СЕЬЬНК вЂ” поле 81М$) (подробности приводятся в главе 8). Ниже приведены соответствуюшие операторы. а) ЯЕЬЕСТ 8184, Н1МЕ, НОТТЬЕЯ РКОИ СЕЬЫК ННЕКЕ РКОООСЕК = 'Оеуаег РеаК' б) ЯЕЬЕСТ 8184, Н1МЕ РКОМ СЕЬЬАК ННЕКЕ ВОТТЬЕЯ > 5 ! в) ЯЕЬЕСТ 818$ РКОИ СЕЬЬКК ННЕКЕ Н1МЕ = 'СаЬ.
Яапчщпоп' ОК Н1МЕ = 'РЬпоб МоЬг' ОК Н1МЕ = '81пГапбе1' ОК НЬМЕ = 'Нукай' ОК ....... ! На этот вопрос нет краткого ответа, так как цвет вина не записан в базе данных в явном виде, и поэтому СУБД не знает, что, например, вино 'РТпоГ Мо1г' красное. Глава 1. Базы данных и управление ими Глава 2 Архитектура системы баз данных 2.1. Введение Теперь, после изучения вводной главы, можно познакомиться с архитектурой системы баз данных. Наша цель — заложить фундамент, на котором будет строиться дальнейшее изложение.
Именно на этот фундамент мы будем опираться при описании общих понятий и объяснении структуры специфических систем баз данных. Однако это вовсе не означает, что каждая система баз данных обязательно должна отвечать конкретному фундаменту или что предложенная конкретная архитектура является единственно возможным вариантом. Например, "малые" системы (см. главу !), весьма вероятно, не будут поддерживать все аспекты предложенной архитектуры. Тем не менее рассматриваемая архитектура с достаточной точностью описывает большинство систем (и не только реляционных). Более того, она практически полностью согласуется с архитектурой, предложенной исследовательской группой Аг!Б!!БРАКС (Бщбу Огопр оп Раза Мапаяещепг Бузгещз), — так называемой архитектурой АНБ!!БРАКС [2.1), [2.2!.
Однако здесь мы не будем придерживаться терминологии А!ЧБ!/БРАКС во всех деталях. Замечание. Материал этой главы подобен материалу предыдущей в том смысле, что он является основой, необходимой для полного понимания структуры и возможностей современных систем баз данных. По этой причине он также носит несколько абстрактный характер, а следовательно, он достаточно "сухой".
Учитывая это, как и в случае изучения главы 1, предварительно можно бегло просмотреть настояцзую главу, а затем, по мере освоения излагаемого в книге материала, возвращаться к отдельным ее разделам, непосредственно связанным с той или иной изучаемой вами темой. 2.2. Три уровня архитектуры Архитектура АХБ1!БРАКС включает три уровня: внутренний, внешний и концептуальный (рис. 2.1). В общих чертах они представляют собой следующее. ° Внутренний уровень (также называемый физическим) наиболее близок к физическому хранилищу информации, т.е. связан со способами сохранения информации на физических устройствах.
° Внешний уровень (также называемый пользовательским логическим) наиболее близок к пользователям, т.е. связан со способами представления данных для отдельных пользователей. ° Концептуальный уровень (также называемый общин логическим или просто логическим) является "промежуточным" уровнем между двумя первыми. 65 Глава 2. Архитектура системы баз данных Внешний уровень (представления отдельнык пользователей) Хонцептуальн (обобщенное и пользова Внутрени (предст физическо Рис. 2.
Е Три уровня архитектуры АХБББРАВС Если внешний уровень связан с индивидуальными представлениями пользователей, то концептуальный уровень связан с обобщенным представлением пользователей. Иначе говоря, может существовать несколько внешних представлений, каждое из которых состоит из более или менее абстрактного представления определенной части базы данных, и только одно концептуальное представление, состоящее из абстрактного представления базы данных в целом'. (Вспомните, что большинство пользователей интересует не вся база данных, а лишь ее некоторая ограниченная часть.) Также существует единственное внутреннее представление, отражающее способ физического хранения всей базы данных. Для лучшего понимания этих идей рассмотрим пример, представленный на рис. 2.2. Здесь отображено концептуальное представление простой базы данных о персонале, а также соответствующие ему внутреннее и два внешних представления (одно — для пользователя, применяющего язык РЕЛ, а другое — для пользователя, применяющего язык СОВО(.).
Конечно, этот пример полностью гипотетичен и мало похож на реальные системы, поскольку в нем умышленно опущены многие не относящиеся к делу детали. Рассматриваемый здесь пример нуждается в пояснениях. ° На концептуальном уровне база данных содержит информацию о типе сущности с именем ЕМРЬОХЕЕ (служащий). Каждый экземпляр сущности ЕМРЬОХЕЕ включает атрибуты номера служащего ЕМРЬОХЕЕ МОМВЕЕ (длиной шесть символов), номера отдела ОЕРЯЕТМЕМТ МОМВЕЕ (длиной четыре символа) и зарплаты служащего ЯИ АЕХ (пять десятичных цифр).
° На внутреннем уровне служащие представлены типом хранимой записи ЯТОЕЕО ЕМР, длина которой составляет 20 байт. Запись ЯТОЕЕО ЕМР содержит четыре хранимых поля; шестибайтовый префикс (возможно, содержащий управляющую информацию, такую как флаги или указатели) и три поля данных, соответствующие трем свойствам сущности, которая представляет служащего. Кроме того, записи ЯТОЕЕО ЕМР индексированы по полю ЕМР() с помощью индекса ЕМРХ, определение которого не показано. з Называя некоторое представление абстрактным, мы имеем в виду лишь то, что оно включает логическ~е конструкции, ориентированные на пользоеатеяя (например, логические записй или поля), и не включает машинно-ориентированные конструкции (например, биты или байтый Часть л'. Основные лоняуния Внешний (РЬ/1) Внешний (СОВОЬ 01 ЕМРС.
02 ЕМРНО Р1С Х(б). 02 ОЕРХНО Р1С Х(4). 0СЬ 1 ЕМРР, 2 ЕМР$ СНАЕ(6], З ВАЬ ГХХЕО ВХМ(З1)! Концепт альный ЕМРЬОХЕЕ ЕМРЬОХЕЕ НОМВЕН СНАЯАСХЕЕ (6) СНАЕАСХЕЕ (4) ОЕРАЕХМЕНХ НОМВЕН БАЬАНХ ИОМЕН1С (5) Вн т енний ВХХЕБ=20 ХХРЕ=ВХХЕ(б), ОГГЯЕХ=О ХХРЕнВХХЕ(б), 1НОЕХ=ЕМРХ ХХРЕ=ВХХЕ(4], ОГГВЕХ=12 ХХРЕ=ГОЬЬИОН0, ОГГЯЕХ=16 ЯХОЕЕО ЕМР РНЕГ1Х ЕМР$ ОГГЯЕХнб, ОЕРХ$ РАХ Рис. 2.2. Припер трех уровней представления базы данных ° Пользователь, применяюший язык Р1Л, имеет дело с соответствуюшим внешним представлением базы данных. В нем каждый сотрудник представлен записью на языке РЬ/1, содержашей два поля (номера отделов не представляют интереса для данного пользователя, поэтому в представлении они опушены). Тип записи опрелелен с помошью обычной структуры, соответствующей правилам языка РЬЬЬ ° Аналогично пользователь, применяющий язык СОВОЬ, имеет дело с собственным внешним представлением базы данных, в котором каждый сотрудник представлен записью на языке СОВОЬ, содержащей, опять же, два поля (в данном случае опушен размер оклада).
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
