![]() Студопедия КАТЕГОРИИ: АвтоАвтоматизацияАрхитектураАстрономияАудитБиологияБухгалтерияВоенное делоГенетикаГеографияГеологияГосударствоДомЖурналистика и СМИИзобретательствоИностранные языкиИнформатикаИскусствоИсторияКомпьютерыКулинарияКультураЛексикологияЛитератураЛогикаМаркетингМатематикаМашиностроениеМедицинаМенеджментМеталлы и СваркаМеханикаМузыкаНаселениеОбразованиеОхрана безопасности жизниОхрана ТрудаПедагогикаПолитикаПравоПриборостроениеПрограммированиеПроизводствоПромышленностьПсихологияРадиоРегилияСвязьСоциологияСпортСтандартизацияСтроительствоТехнологииТорговляТуризмФизикаФизиологияФилософияФинансыХимияХозяйствоЦеннообразованиеЧерчениеЭкологияЭконометрикаЭкономикаЭлектроникаЮриспунденкция |
Операторыманипулирования данными. Операторы DML (Data Manipulation Language) - операторы манипулирования данными
· SELECT - отобрать строки из таблиц · INSERT - добавить строки в таблицу · UPDATE - изменить строки в таблице · DELETE - удалить строки в таблице · COMMIT - зафиксировать внесенные изменения · ROLLBACK - откатить внесенные изменения INSERT INTO P (PNUM, PNAME) VALUES (4, "Иванов");
UPDATE P SET PNAME = "Пушников" WHEREP.PNUM = 1;
DELETE FROM P WHERE P.PNUM = 1;
SELECT * FROMP;
| 4.Организация безопасности данных в базе данных.Безопасность и секретность. Под безопасностью данных понимают защиту данных от случайного или преднамеренного доступа к ним лиц, не имеющих на это права, от неавторизованной модификации данных или их разрушения. Секретность определяется как право отдельных лиц или организаций решать, когда, как и какое количество соответствующей информации может быть передано другим лицам или организациям.Ниже перечислены положения, особенно важные с точки зрения обеспечения безопасности данных в базе данных:1.Данные должны быть защищены от искажения, хищения и других форм разрушения.2.Данные должны быть восстанавливаемыми, так как иногда, несмотря на тщательную предосторожность, могут иметь место различного рода случайные сбои.3.Данные должны быть контролируемыми. Нарушения проверочных средств в вычислительных системах могут привести к катастрофе.4.Система должна быть недоступной для вмешательства; обычные программисты не должны располагать возможностью обхода системы контроля.5.В настоящее время еще нет систем, полностью изолированных от возможности вмешательства, но осуществление вмешательства в систему должно быть предельно трудным. Должна быть установлена процедура идентификации пользователя базы данных, которая обеспечивает возможность доступа к базе только после правильного ее выполнения.6.В системе должен быть предусмотрен контроль действий пользователя с точки зрения санкционирования их выполнения.7.Контроль над работой пользователя должен осуществляться так, чтобы его ошибочные действия были с большой вероятностью обнаружены.
10.Простые и сложные сетевые структуры. Во многих сетевых структурах, задающих связи между типами записей или типами агрегатов данных, представление отношений между исходными и порожденными элементами аналогично представлению отношений в случае дерева: отношение исходный-порожденный является сложным, а отношение порожденный-исходный – простым (рис.3.6).
![]() ![]() ![]()
Накладные-товары
б) Накладные
Рис. 1. Структуры данных реляционной и постреляционной моделей Как видно из рисунка, по сравнению с реляционной моделью в постреляционной модели данные хранятся более эффективно, а при обработке не требуется выполнять операцию соединения данных из двух таблиц. Помимо обеспечения вложенности полей постреляционная модель поддерживает ассоциированные многозначные поля (множественные группы). Совокупность ассоциированных полей называется ассоциацией. При этом в строке первое значение одного столбца ассоциации соответствует первым значениям всех других столбцов ассоциации. Аналогичным образом связаны все вторые значения столбцов и т. д. На длину полей и количество полей в записях таблицы не накладывается требование постоянства. Это означает, что структура данных и таблиц имеют большую гибкость. Поскольку постреляционная модель допускает хранение в таблицах ненормализованных данных, возникает проблема обеспечения целостности и непротиворечивости данных. Эта проблема решается включением в СУБД механизмов, подобных хранимым процедурам в клиент-серверных системах. Для описания функций контроля значений в полях имеется возможность создавать процедуры (коды конверсии и коды корреляции), автоматически вызываемые до или после обращения к данным. Коды корреляции выполняются сразу после чтения данных, перед их обработкой. Коды конверсии, наоборот, выполняются после обработки данных. Достоинством постреляционной модели является возможность представления совокупности связанных реляционных таблиц одной постреляционной таблицей. Постреляционная модель обеспечивает инфраструктуру, наилучшим образом обеспечивающую решение сложных аналитических задач, требующих обработки больших объемов информации. Она сокращает требуемые размеры памяти и позволяет на той же самой конфигурации связать больше пользователей с базой данных, чем реляционные базы данных.Недостатком постреляционной модели является сложность решения проблемы обеспечения целостности и непротиворечивости хранимых данных. К числу СУБД, основанных на постреляционной модели данных, относятся системы uniVers, Bubba и Dasdb.
21.Связь объектно-ориентированных СУБД с общими понятиями объектно-ориентированного подхода.В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях: -объекта и идентификатора объекта; -атрибутов и методов; -классов; -иерархии и наследования классов. Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта. Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы (находяться) в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов. Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.Допускается порождение нового класса на основе уже существующего класса - наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько. Если в языке или системе поддерживается единичное наследование классов, набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф с корнем, называемый решеткой классов. Объект подкласса считается принадлежащим любому суперклассу этого класса. Одной из более поздних идей объектно-ориентированного подхода является идея возможного переопределения атрибутов и методов суперкласса в подклассе (перегрузки методов). Эта возможность увеличивает гибкость, но порождает дополнительную проблему: при компиляции объектно-ориентированной программы могут быть неизвестны структура и программный код методов объекта, хотя его класс (в общем случае - суперкласс) известен. Для разрешения этой проблемы применяется так называемый метод позднего связывания, означающий, по сути дела, интерпретационный режим выполнения программы с распознаванием деталей реализации объекта во время выполнения посылки сообщения к нему. Введение некоторых ограничений на способ определения подклассов позволяет добиться эффективной реализации без потребностей в интерпретации. Как видно, при таком наборе базовых понятий, если не принимать во внимание возможности наследования классов и соответствующие проблемы, объектно-ориентированный подход очень близок к подходу языков программирования с абстрактными (или произвольными) типами данных. С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход весьма близок к подходу семантического моделирования данных (даже и по терминологии). Фундаментальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентированном подходе. На абстракции агрегации основывается построение сложных объектов, значениями атрибутов которых могут быть другие объекты. Абстракция группирования - основа формирования классов объектов. На абстракциях специализации/обобщения основано построение иерархии или решетки классов. Видимо, наиболее важным новым качеством ООБД, которого позволяет достичь объектно-ориентированный подход, является поведенческий аспект объектов. В прикладных информационных системах, основывавшихся на БД с традиционной организацией (вплоть до тех, которые базировались на семантических моделях данных), существовал принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, верифицировать и т.д., а поведенческая часть создавалась изолированно. В частности, отсутствовали формальный аппарат и системная поддержка совместного моделирования и гарантирования согласованности этих структурной (статической) и поведенческой (динамической) частей. В среде ООБД проектирование, разработка и сопровождение прикладной системы становится процессом, в котором интегрируются структурный и поведенческий аспекты. Конечно, для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему. Специфика применения объектно-ориентированного подхода для организации и управления БД потребовала уточненного толкования классических концепций и некоторого их расширения. Это определяется потребностями долговременного хранения объектов во внешней памяти, ассоциативного доступа к объектам, обеспечения согласованного состояния ООБД в условиях мультидоступа и тому подобных возможностей, свойственных базам данных. Выделяются три аспекта, отсутствующие в традиционной парадигме, но требующиеся в ООБД. Первый аспект касается потребности в средствах спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.). Второй аспект - потребность в механизме определения разного рода семантических связей между объектами вообще говоря разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи сиспользовании ООБД в сфере автоматизированного проектирования и инженерии. Наконец, третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа и класса объектов. Как мы отмечали во введении, в сообществе исследователей ООБД и разработчиков систем отсутствует полное согласие, но в большинстве практических работ используется некоторое расширение объектно-ориентированного подхода. 26.Нормальные формы отношений. Нормальная форма — свойство отношения в реляционной модели данных, характеризующее его с точки зрения избыточности, которая потенциально может привести к логически ошибочным результатам выборки или изменения данных. Нормальная форма определяется как совокупность требований, которым должно удовлетворять отношение. Процесс преобразования базы данных к виду, отвечающему нормальным формам, называется нормализацией. Нормализация предназначена для приведения структуры базы данных к виду, обеспечивающему минимальную избыточность, то есть нормализация не имеет целью уменьшение или увеличение производительности работы или же уменьшение или увеличение объёма БД. Конечной целью нормализации является уменьшение потенциальной противоречивости хранимой в БД информации. Устранение избыточности производится, как правило, за счёт декомпозиции отношений таким образом, чтобы в каждом отношении хранились только первичные факты (то есть факты, не выводимые из других хранимых фактов). 23. Базовые понятия РБДосн понятиями РБД явл-ся: -тип д-х, -домен, -атрибут, -кортеж, -первич.ключ, -отношения. Тип д-х: понятие типа д-х в РБД полностью адекв. понятию типа д-х в языках прогр-я. Обычно в соврем. РБД допуск-ся хран-е символ-х, числ-х д-х, битовых строк, специализ. числ-х д-х, а также спец-х темпорал-х д-х (дата, время, врем.инт-л). Дост. активно развив-ся подход к расшир-ю возм-тей реляц-х систем абстракт-ми типами д-х. Домен: В РМД с понятием типа д-х тесно связ. понятие домена, кот.можно счит. уточ-ем типа д-х. Домен-семантич. понятие. Домен можно рассм-ть как подмн-во знач-й некот. типа д-х, имеющих опред. смысл. Домен хар-ся след.св-вами: 1.домен имеет уникал. имя; 2.домен опр-н на некот. простом типе д-х или на др. домене; 3.домен может иметь некот. логич. усил-е, позвол-е описать подмн-во д-х допуст-х для данн. домена; 4.домен несет опред. смысл-ю нагрузку. Понятие домена помогает прав-но моделир-ть предмет.обл-ть. Отнош-е: 1. Атрибут отн-я есть пара вида <имя_атрибута:имя_домена>. Имена атрибутов должны быть уникал. в пределах отнош-я. Часто имена атриб-в отн-я совпад. с именами соотв-х доменов. 2.Отн-я к R, опред-е на мн-ве доменов Д1,Д2,...Дп содержит 2 части: заголовок и тело. Заголовок отн-я содерж. фиксир-е кол-во атриб-в отн-я (<А1:Д1>, <А2:Д2>, ... , <Ап:Дп>). Тело отн-я содерж. мн-во кортежей отн-я. Кажд. кортеж отн-я предст. собой мн-во пар вида <имя_атрибута:знач-е_атрибута> (Тело: <A1:Val1>, <A2:Val2>, … ,<An:Valn>), таких что знач-е Vali атрибута Ai принадл. домену Di. Отн-е обычно запис-ся в виде R(<А1:Д1>, <А2:Д2>, ... , <Ап:Дп>), или короче R(A1, A2, … , An), или просто R. Число атриб-в в отн-и наз. степенью или R-тью отн-я. Мощ-ть мн-ва кортежей отн-я наз. мощ-тью отн-я. Выводы: 1)-заголовок отн-я опис. декартово произв-е доменов, на кот. задано отн-е. –заголовок статичен, он не мен-ся во время работы с БД. –если в отн-и изм-ны, добав-ны или удалены атрибуты, то в рез-те получим уже др.отн-е, пусть даже с преж.именем. 2)тело отн-я предст. собой набор кортежей, т.е. подмн-во декарт. произв-я доменов. Т.о. тело отн-я собственно и явл-ся отн-ем в матем. смысле слова. 3.РБД наз-ся набор отн-й. 4. Схемой РБД наз. набор заголовков отн-й,вх-х в БД. 30. 3НФ.Атрибуты наз. взаимозавис-ми, если ни 1 из них не явл. функц. завис.от др.Отн-е R нах. в 3НФ <=> отн-е нах-ся в 2НФ и все неключ. атрибуты взаимно независ.Отн-е «сотр-отделы» не нах-ся в 3НФ, т.к. имеется функц. завис-ть неключ. атриб-в (№тел-адрес-№отдела): №отдела->тел. Для того, чтобы устран. завис-ть неключ. атриб-в, необх. произвести декомпоз-ю отн-я на неск-ко отн-й, при этом те неключ. атрибуты, кот. явл-ся завис. вынос-ся в отд. отнош-е. Отн-е «Сотр-отделы» декомпоз. на сотр и отд.«Сотр»: (№, фамилия, №отдела). В этом отн-и есть функц. завис-ть, а именно завис-ть атриб-в, хар-х сотр-ка, от табел. номера сотр-ка: номер_сотр->фамилия, номер_сотр->номер_отдела, номер_сотр->тел. Т.о. мы можем предст. отн. «Сотр» в табл. форме:№сотр | фамилия | №отдела: 1-Ив-1, 2-петр-1, 3-Сид-2.«Отделы»: (№отдела, тел). В этом отн-и есть функц. завис-ть: №отдела->тел. Также можно предст. в табл. форме:№отдела | тел: 1-1111, 2-1122.Обратим вним-е на то, что атрибут «номер_отдела», не явл-ся ключ-м в отн-и «сотр-отдел», стан-ся потенц. ключом в отн-и «отделы». Именно засчет этого устран-ся избыт-ть, связ. с многократ. хран-ем 1 и тех же №№ тел-в.Т.о. все обнаруж-е аномалии обновл-я устранены. Реляц. модель, сост-я из 4х отн-й (сотр, отделы, проекты, задания), нах-ся в 3НФ, явл-ся адекват. опис-ймодели предм.обл. и требует налич. только тех тригеров, кот. поддерж. ссылоч. целост-ть. Такие тригеры явл-ся стандарт.и не требуют больших усилий в разраб-ке. Отн-е в 3НФ явл-ся самыми «хорошими» с т.з. выбр-х нами критериев.
37. Основные понятия ER-диаграмм. Сущность- класс однотип. объектов, инфо о кот. должна быть учтена в модели. Кажд. сущ-ть должна иметь наим-е, выраж-е сущ-ным в ед. числе. Кажд сущ-ть в модели изобр-ся в виде прямоуг-ка с наим-ем: (прямоуг-к, раздел.пополам, сверху надпись «сотрудник», нижний пуст; аналогич. прямоуг-к «отдел»). Экземпляр сущ-ти – конкрет. предст-ль данн. сущ-ти. Экз-ры сущ-ти должны быть различимы, т.е. иметь некот. св-ва, уникал. для кажд. экз-ра эт. сущ-ти. Атрибут сущ-ти – именов-я хар-ка, явл-ся некот. св-вом сущ-ти. (Для сущ-ти «Сотр-к» - Фамилия, имя, отдел, з/п итд). Атрибуты изобр-ся в пределах пр-ка, опред-го сущ-ть: (прямоуг-к, раздел.пополам, сверху надпись «Сотр-к», в ниж. части Фамилия, Имя, Отдел, з/п). Ключ сущ-ти – неизбыт. набор атриб-в, знач-е кот.в совокуп-ти явл. уникал. для любого экз-ра сущ-ти. Неизбыт-ть закл. в том, что удал-е любого атрибута из ключа нарушает его уникал-ть. Сущ-ть может иметь неск-ко различ. ключей. Ключ-е атрибуты изобр-ся в диагр-х подчерк-ем (обычно запис-ся самым первым). Связь – некот. ассоциация м/у 2мя сущ-тями. 1 сущ-ть м.б. связ. с др. сущ-тью или сама с собой. Графически связь изобр-ся линией, соед-й 2 сущ-ти:
42. Опер-ры опред-я объектов БД.Опер-ры DDL – это опер-ры опред-я объектов БД. (createschema – опер-р созд-я сх. БД; dropschema – опер-р удал-я сх. БД; createtable – опер-р созд-я табл.; droptable – опер-р удал-я табл.; altertable – опер-р измен-я табл.; createview – опер-р созд-я предст-я; dropview – опер-р удал-я предст-я). пример: вставка 1 строки в табл. insert into P(pnum, pname) values(4,”Иванов”)
обновл-е неск-ких строк в табл. update P set pname=”Иванов” wherep.pnum=1
удал-е неск-ких строк в табл delete from P where P.pnum=1
удал-е всех строк в табл. deletefromp
38.Типы связи сущность-связь.Каждая связь может иметь один из следующих типов связи: ]
39.Модальность связи.Каждая связь может иметь одну из двух модальностей связи:
|
Последнее изменение этой страницы: 2018-04-12; просмотров: 239.
stydopedya.ru не претендует на авторское право материалов, которые вылажены, но предоставляет бесплатный доступ к ним. В случае нарушения авторского права или персональных данных напишите сюда...