Модель
<<  Модель технологии печати КИМ в аудиториях ППЭ Некоторые известные структурные модели  >>
Лекция 4. Реляционная модель данных
Лекция 4. Реляционная модель данных
Атомарность значений атрибутов Значения всех атрибутов являются
Атомарность значений атрибутов Значения всех атрибутов являются
Служебные сведения
Служебные сведения
Лекция 4. Реляционная модель данных
Лекция 4. Реляционная модель данных
Лекция 4. Реляционная модель данных
Лекция 4. Реляционная модель данных
Связь «многие ко многим» также автоматически возникает между таблицами
Связь «многие ко многим» также автоматически возникает между таблицами
Картинки из презентации «Реляционная модель данных. Связи в РБД» к уроку информатики на тему «Модель»

Автор: . Чтобы познакомиться с картинкой полного размера, нажмите на её эскиз. Чтобы можно было использовать все картинки для урока информатики, скачайте бесплатно презентацию «Реляционная модель данных. Связи в РБД.ppt» со всеми картинками в zip-архиве размером 1031 КБ.

Реляционная модель данных. Связи в РБД

содержание презентации «Реляционная модель данных. Связи в РБД.ppt»
Сл Текст Сл Текст
1Лекция 4. Реляционная модель данных. 16Иванова. 112,000. 315. Сотр_номер.
Связи в РБД. В реляционной модели данных Сотр_имя. Сотр_зарп. Сотр_отд_номер.
информация хранится в одной или нескольких 17Наиболее распространенная трактовка
связанных таблицах. Отдельная таблица реляционной модели данных, по-видимому,
(отношение) обычно представляет принадлежит Дейту, который воспроизводит
совокупность (группу) либо реальных ее (с различными уточнениями) практически
объектов, либо некоторых абстрактных во всех своих книгах. Согласно Дейту,
концепций, либо событий одного типа. реляционная модель состоит из трех частей,
Каждая запись в таблице идентифицирует описывающих разные аспекты реляционного
один объект группы. Таблица состоит из подхода: структурной части,
строк и столбцов, называемых манипуляционной части и целостной части. В
соответственно записями и полями структурной части модели фиксируется, что
(кортежами и атрибутами). единственной структурой данных,
2Таблицы обладают следующими используемой в реляционных БД, является
свойствами: Каждая ячейка таблицы нормализованное n-арное отношение. (E.F.
представляет собой один элемент данных, Codd) Кодд разработал язык манипулирования
совокупность значений в одном столбце данными, представленными в виде отношений.
одной строки недопустима. 2. Все столбцы в Он предложил два эквивалентных по своим
таблице однородные. Это означает, что выразительным возможностям варианта языка
элементы столбца имеют одинаковую природу. манипулирования данными: реляционная
Столбцам присвоены имена. 3. В таблице нет алгебра и реляционное исчисление.
двух одинаковых строк. 4. Порядок 18Реляционная алгебра. Это процедурный
размещения строк и столбцов в таблице язык, так как отношение, являющееся
может быть произвольным. В операциях с результатом запроса к реляционной БД,
такой таблицей ее строки и столбцы могут вычисляется при выполнении
просматриваться в любом порядке последовательности реляционных операторов,
безотносительно к их информационному применяемых к отношениям. Операторы
содержанию и смыслу. состоят из операндов, в роли которых
3Таблицы, обладающие такими свойствами, выступают отношения и реляционные
являются точным прообразом математического операции. Результатом реляционной операции
двухмерного множества - отношения является отношение. Операции можно
(relation). Но эти два понятия не разделить на две группы. Первую группу
эквивалентны. Отношение - это абстрактный составляют операции над множествами, к
математический объект, а таблица - которым относятся операции объединения,
конкретное изображение этого абстрактного пересечения, разности, деления и декартова
объекта. Различие проявляется в их произведения. Вторую группу составляют
свойствах. В отношении строки и столбцы не специальные операции над отношениями:
могут быть упорядочены, а в таблице строки проекция, выборка и соединение.
упорядочены сверху вниз, столбцы - слева 192. Реляционное исчисление. Это
направо. В таблице могут повторяться непроцедурный язык описательного или
строки, а в отношении - нет. В реляционной декларативного характера, содержащий лишь
модели каждая строка таблиц уникальна. Это информацию о желаемом результате. Процесс
обеспечивается применением ключей, которые получения этого результата скрыт от
содержат одно или несколько полей таблицы, пользователя. К языкам такого типа
Ключи хранятся в упорядоченном виде, относятся SQL и QBE. Первый основан на
обеспечивающем прямой доступ к записям реляционном исчислении кортежей, второй -
таблицы во время поиска. Связь между на реляционном исчислении доменов. С
таблицами осуществляется посредством помощью этих языков можно извлекать
значений одного или нескольких совпадающих подмножество столбцов и строк таблицы,
полей (преимущественно ключевых). создавая таблицы меньшей размерности, а
4Основными понятиями реляционных баз также объединять связанные данные из
данных являются тип данных, домен, нескольких таблиц, создавая при этом
атрибут, кортеж, первичный ключ и таблицы большей размерности. Результат
отношение. Понятие тип данных в каждой (реляционной) операции над
реляционной модели данных полностью отношениями также является отношением. Это
адекватно понятию типа данных в языках реляционное свойство получило название
программирования. Обычно в современных свойства замкнутости. Следовательно,
реляционных БД допускается хранение различные пользователи могут выделять в
символьных, числовых данных, битовых реляционной БД различные наборы данных и
строк, специализированных числовых данных связей между ними. Этот способ
(таких как "деньги"), а также представления данных наиболее удобен для
специальных "темпоральных" конечного пользователя. Реляционная модель
данных (дата, время, временной интервал). данных очень гибкая, поскольку любое
Достаточно активно развивается подход к представление данных с некоторой
расширению возможностей реляционных систем избыточностью можно свести к двухмерным
абстрактными типами данных таблицам.
(соответствующими возможностями обладают, 20Целостность сущности и ссылок Наконец,
например, системы семейства в целостной части реляционной модели
Ingres/Postgres). В нашем примере мы имеем данных фиксируются два базовых требования
дело с данными трех типов: строки целостности, которые должны поддерживаться
символов, целые числа и в любой реляционной СУБД : требования
"деньги". целостности сущностей и целостности по
5Понятие домена более специфично для ссылкам. Первое требование – целостности
баз данных, хотя и имеет некоторые сущностей. Объекту или сущности реального
аналогии с подтипами в некоторых языках мира в реляционных БД соответствуют
программирования. В самом общем виде домен кортежи отношений. Конкретно требование
определяется заданием некоторого базового состоит в том, что любой кортеж любого
типа данных, к которому относятся элементы отношения отличим от любого другого
домена, и произвольного логического кортежа этого отношения, т.е. другими
выражения, применяемого к элементу типа словами, любое отношение должно обладать
данных. Если вычисление этого логического первичным ключом. Как мы видели в
выражения дает результат предыдущем разделе, это требование
"истина", то элемент данных автоматически удовлетворяется, если в
является элементом домена. Наиболее системе не нарушаются базовые свойства
правильной интуитивной трактовкой понятия отношений.
домена является понимание домена как 21Второе требование - целостности по
допустимого потенциального множества ссылкам, является несколько более сложным.
значений данного типа. Например, домен Очевидно, что при соблюдении
"Имена" в нашем примере нормализованности отношений сложные
определен на базовом типе строк символов, сущности реального мира представляются в
но в число его значений могут входить реляционной БД в виде нескольких кортежей
только те строки, которые могут изображать нескольких отношений. Например,
имя (в частности, такие строки не могут представим, что нам требуется представить
начинаться с мягкого знака). Следует в реляционной базе данных сущность ОТДЕЛ с
отметить также семантическую нагрузку атрибутами ОТД_НОМЕР (номер отдела),
понятия домена: данные считаются ОТД_КОЛ (количество сотрудников) и
сравнимыми только в том случае, когда они ОТД_СОТР (набор сотрудников отдела). Для
относятся к одному домену. Например, каждого сотрудника нужно хранить
значения доменов "Номера СОТР_НОМЕР (номер сотрудника), СОТР_ИМЯ
пропусков" и "Номера групп" (имя сотрудника) и СОТР_ЗАРП (заработная
относятся к типу целых чисел, но не плата сотрудника). Как мы вскоре увидим,
являются сравнимыми. Заметим, что в при правильном проектировании
большинстве реляционных СУБД понятие соответствующей БД в ней появятся два
домена не используется, хотя в Oracle V.7 отношения: ОТДЕЛЫ ( ОТД_НОМЕР, ОТД_КОЛ )
оно уже поддерживается. (первичный ключ - ОТД_НОМЕР) и СОТРУДНИКИ
6Атрибут - это свойство, ( СОТР_НОМЕР, СОТР_ИМЯ, СОТР_ЗАРП,
характеризующее объект. В структуре СОТР_ОТД_НОМ ) (первичный ключ -
таблицы каждый атрибут именуется и ему СОТР_НОМЕР).
соответствует заголовок некоторого столбца 22Как видно, атрибут СОТР_ОТД_НОМ
таблицы. Количество атрибутов называется появляется в отношении СОТРУДНИКИ не
степенью отношения. Схема отношения - это потому, что номер отдела является
именованное множество пар {имя атрибута, собственным свойством сотрудника, а лишь
имя домена (или типа, если понятие домена для того, чтобы иметь возможность
не поддерживается)}. Степень или восстановить при необходимости полную
"арность" схемы отношения - сущность ОТДЕЛ (произведя выборку по всем
мощность этого множества. Если все совпадающим значениям атрибута). Значение
атрибуты одного отношения определены на атрибута СОТР_ОТД_НОМ в любом кортеже
разных доменах, осмысленно использовать отношения СОТРУДНИКИ должно
для именования атрибутов имена соответствовать значению атрибута ОТД_НОМ
соответствующих доменов (не забывая, в некотором кортеже отношения ОТДЕЛЫ.
конечно, о том, что это является всего Атрибут такого рода называется внешним
лишь удобным способом именования и не ключом, поскольку его значения однозначно
устраняет различия между понятиями домена характеризуют сущности, представленные
и атрибута). Схема БД (в структурном кортежами некоторого другого отношения
смысле) - это набор именованных схем (т.е. задают значения их первичного
отношений. ключа). Говорят, что отношение, в котором
7 определен внешний ключ, ссылается на
8Кортеж, соответствующий данной схеме соответствующее отношение, в котором такой
отношения, - это множество пар {имя же атрибут является первичным ключом.
атрибута, значение}, которое содержит одно Требование целостности по ссылкам, или
вхождение каждого имени атрибута, требование внешнего ключа состоит в том,
принадлежащего схеме отношения. что для каждого значения внешнего ключа,
"Значение" является допустимым появляющегося в ссылающемся отношении, в
значением домена данного атрибута (или отношении, на которое ведет ссылка, должен
типа данных, если понятие домена не найтись кортеж с таким же значением
поддерживается). Тем самым, степень или первичного ключа, либо значение внешнего
"арность" кортежа, т.е. число ключа должно быть неопределенным (т.е. ни
элементов в нем, совпадает с на что не указывать). Для нашего примера
"арностью" соответствующей схемы это означает, что если для сотрудника
отношения. Попросту говоря, кортеж - это указан номер отдела, то этот отдел должен
набор именованных значений заданного типа. существовать.
Отношение - это множество кортежей, 23Ограничения целостности сущности и по
соответствующих одной схеме отношения. ссылкам должны поддерживаться СУБД. Для
Иногда, чтобы не путаться, говорят соблюдения целостности сущности достаточно
"отношение-схема" и гарантировать отсутствие в любом отношении
"отношение-экземпляр", иногда кортежей с одним и тем же значением
схему отношения называют заголовком первичного ключа. С целостностью по
отношения, а отношение как набор кортежей ссылкам дела обстоят несколько более
- телом отношения. На самом деле, понятие сложно. Понятно, что при обновлении
схемы отношения ближе всего к понятию ссылающегося отношения (вставке новых
структурного типа данных в языках кортежей или модификации значения внешнего
программирования. Было бы вполне логично ключа в существующих кортежах) достаточно
разрешать отдельно определять схему следить за тем, чтобы не появлялись
отношения, а затем одно или несколько некорректные значения внешнего ключа. Но
отношений с данной схемой. как быть при удалении кортежа из
9Однако в реляционных базах данных это отношения, на которое ведет ссылка? Здесь
не принято. Имя схемы отношения в таких существуют три подхода, каждый из которых
базах данных всегда совпадает с именем поддерживает целостность по ссылкам.
соответствующего отношения-экземпляра. В 24Первый подход заключается в том, что
классических реляционных базах данных запрещается производить удаление кортежа,
после определения схемы базы данных на который существуют ссылки (т.е. сначала
изменяются только отношения-экземпляры. В нужно либо удалить ссылающиеся кортежи,
них могут появляться новые и удаляться или либо соответствующим образом изменить
модифицироваться существующие кортежи. значения их внешнего ключа). При втором
Однако во многих реализациях допускается и подходе при удалении кортежа, на который
изменение схемы базы данных: определение имеются ссылки, во всех ссылающихся
новых и изменение существующих схем кортежах значение внешнего ключа
отношения. Это принято называть эволюцией автоматически становится неопределенным.
схемы базы данных. Обычным житейским Наконец, третий подход (каскадное
представлением отношения является таблица, удаление) состоит в том, что при удалении
заголовком которой является схема кортежа из отношения, на которое ведет
отношения, а строками - кортежи ссылка, из ссылающегося отношения
отношения-экземпляра; в этом случае имена автоматически удаляются все ссылающиеся
атрибутов именуют столбцы этой таблицы. кортежи. В развитых реляционных СУБД
Поэтому иногда говорят "столбец обычно можно выбрать способ поддержания
таблицы", имея в виду "атрибут целостности по ссылкам для каждой
отношения". Когда мы перейдем к отдельной ситуации определения внешнего
рассмотрению практических вопросов ключа. Конечно, для принятия такого
организации реляционных баз данных и решения необходимо анализировать
средств управления, мы будем учитывать эту требования конкретной прикладной области.
житейскую терминологию. Этой терминологии 25Кроме ссылочной целостности, можно
придерживаются в большинстве коммерческих сформулировать еще три ограничителя
реляционных СУБД. целостности для реляционной БД: •
10Реляционная база данных - это набор ограничители домена (domain constraints),
отношений, имена которых совпадают с запрещающие ввод значений трибутов, не
именами схем отношений в схеме БД. Как принадлежащих домену. К ним можно отнести
видно, основные структурные понятия также все ограничители значений (тип,
реляционной модели данных (если не считать формат, задание списка и диапазона
понятия домена) имеют очень простую значении); • ограничители ключей (key
интуитивную интерпретацию, хотя в теории constraints), обеспечивающие уникальность
реляционных БД все они определяются значений потенциальных ключей
абсолютно формально и точно. (обеспечивается применением уникальных
Фундаментальные свойства отношений: индексов); • ограничители записи (entity
-Отсутствие кортежей-дубликатов constraints), запрещающие NULL значения
-Отсутствие упорядоченности кортежей для первичных ключей, так как в противном
-Отсутствие упорядоченности атрибутов случае будет нарушено требование
-Атомарность значений атрибутов. идентифицируемости записи.
11Отсутствие кортежей-дубликатов То 26Отношение между объектами определяет
свойство, что отношения не содержат тип связи между таблицами. Поддерживаются
кортежей-дубликатов, следует из связи четырех типов: «один к одному»,
определения отношения как множества «один ко многим», «многие к одному» и
кортежей. В классической теории множеств «многие ко многим». Рассмотрим подробнее
по определению каждое множество состоит из типы связей в применении к реляционной
различных элементов. Из этого свойства модели данных. «Один к одному». Связь
вытекает наличие у каждого отношения так «один к одному» означает, кто каждой
называемого первичного ключа - набора записи из первой таблицы соответствует
атрибутов, значения которых однозначно одна и только одна запись из другой
определяют кортеж отношения. Для каждого таблицы. Рассмотрим таблицы, содержащие
отношения по крайней мере полный набор его персональные и служебные сведения о
атрибутов обладает этим свойством. Однако работниках некоторой фирмы. Между
при формальном определении первичного таблицами «Персональные сведения» и
ключа требуется обеспечение его «Служебные сведения» существует связь
"минимальности", т.е. в набор «один к одному», поскольку для одного
атрибутов первичного ключа не должны человека, работающего в определенной
входить такие атрибуты, которые можно фирме, может существовать только одна
отбросить без ущерба для основного запись о служебном положении. Табельные
свойства - однозначно определять кортеж. номера «Код_пс» и «Код_сс» служат для
Понятие первичного ключа является однозначной идентификации записей. Эти же
исключительно важным в связи с понятием поля и приняты в качестве первичных
целостности баз данных. Забегая вперед, ключей. Связь между этими таблицами
заметим, что во многих практических поддерживаются при помощи совпадающих
реализациях РСУБД допускается нарушение значений полей. Легко убедиться, что между
свойства уникальности кортежей для двумя ключевыми полями может существовать
промежуточных отношений, порождаемых только связь «один к одному», поскольку
неявно при выполнении запросов. Такие любые дублирования одного и того же
отношения являются не множествами, а табельного номера исключены с обеих
мультимножествами, что в ряде случаев сторон.
позволяет добиться определенных 27Служебные сведения. Персональные
преимуществ, но иногда приводит к сведения. 7. Код ее. Место работы.
серьезным проблемам. Должность. Разряд. Код пс. Паспорт.
12Отсутствие упорядоченности кортежей Фамилия. Имя. 1. Бухгалтерия. Бухгалтер.
Свойство отсутствия упорядоченности 3. 1. Ав 2358955. Сидоров. Сергей. 2. Цех
кортежей отношения также является № 2. Токарь. 2. Вв 2456886. Петров. Петр.
следствием определения 3. Лаборатория. Начальник отдела. 3. Ма
отношения-экземпляра как множества 8654212. Иванов. Иван.
кортежей. Отсутствие требования к 28«Один ко многим» и «многие к одному».
поддержанию порядка на множестве кортежей Связь «один ко многим» означает, что
отношения дает дополнительную гибкость каждой записи из первой таблицы может
СУБД при хранении баз данных во внешней соответствовать одна либо много записей из
памяти и при выполнении запросов к базе другой таблицы. Связи «один ко многим» и
данных. Это не противоречит тому, что при «многие к одному» являются обратимыми,
формулировании запроса к БД, например, на поэтому подробнее остановимся на связи
языке SQL можно потребовать сортировки «один ко многим». Рассмотрим таблицы,
результирующей таблицы в соответствии со содержащие сведения о клиентах некоторой
значениями некоторых столбцов. Такой фирмы и сделанных ими заказах.
результат, вообще говоря, не отношение, а Предполагается что один и тот же клиент
некоторый упорядоченный список кортежей. может сделать несколько заказов. Для
13Отсутствие упорядоченности атрибутов установления связи необходимо в таблицу
Атрибуты отношений не упорядочены, «Заказы» ввести поле «Код_клиента»,
поскольку по определению схема отношения которое будет являться для данной таблицы
есть множество пар {имя атрибута, имя внешним ключом. Связь между таблицами
домена}. Для ссылки на значение атрибута в будет осуществляться на основании значений
кортеже отношения всегда используется имя полей «Клиенты. Код_клиента» и «Заказы.
атрибута. Это свойство теоретически Код_клиента». Причем подчеркнем, что связь
позволяет, например, модифицировать схемы устанавливается на основе значений
существующих отношений не только путем совпадающих полей, а не их наименований.
добавления новых атрибутов, но и путем Таким образом, если связь устанавливается
удаления существующих атрибутов. Однако в между ключевым полем одной таблицы и
большинстве существующих систем такая неключевым полем второй таблицы, то это
возможность не допускается, и хотя будет связь типа «один ко многим».
упорядоченность набора атрибутов отношения 29
явно не требуется, часто в качестве 30«Многие ко многим». Связь «многие ко
неявного порядка атрибутов используется их многим» возникает между двумя таблицами в
порядок в линейной форме определения схемы тех случаях, когда каждой записи из первой
отношения. таблицы может соответствовать одна либо
14Атомарность значений атрибутов много записей из второй таблицы и,
Значения всех атрибутов являются наоборот, одной записи из второй таблицы
атомарными. Это следует из определения может соответствовать одна либо много
домена как потенциального множества записей из первой таблицы. Типичным
значений простого типа данных, т.е. среди примером является связь между клиентами
значений домена не могут содержаться некой фирмы и покупаемыми ими товарами.
множества значений (отношения). Принято Каждый товар может быть куплен несколькими
говорить, что в реляционных базах данных клиентами и, наоборот, один клиент может
допускаются только нормализованные купить несколько товаров. Такая связь
отношения или отношения, представленные в может быть реализована с помощью
первой нормальной форме. Ненормализованное дополнительной таблицы, содержащей
отношение ОТДЕЛЫ. ключевые поля обеих таблиц, участвующих в
15Заметим, что отношение СОТРУДНИКИ связи (являющимися для нее внешними
является нормализованным вариантом ключами).
отношения ОТДЕЛЫ: Нормализованные 31
отношения составляют основу классического 32Связь «многие ко многим» также
реляционного подхода к организации баз автоматически возникает между таблицами,
данных. Они обладают некоторыми связанными посредством неключевых полей.
ограничениями (не любую информацию удобно Пусть первая таблица содержит информацию о
представлять в виде плоских таблиц), но том, на каких станках могут работать
существенно упрощают манипулирование рабочие некоторой бригады. Вторая таблица
данными. Сотр_номер. Сотр_имя. Сотр_зарп. содержит сведения о том, кто из бригады
Сотр_отд_номер. 2934. Иванов. 112,000. ремонтников какие станки обслуживает.
310. 2935. Петров. 144,000. 310. 2936. Такой вид связи «многие ко многим»
Сидоров. 92,000. 313. 2937. Федоров. характеризуется как слабый вид связи или
110,000. 310. 2938. Иванова. 112,000. 315. даже как ее отсутствие, поскольку никакого
16Рассмотрим, например, два идентичных контроля за целостностью данных в этом
оператора занесения кортежа: Зачислить случае не осуществляется.
сотрудника Кузнецова (пропуск номер 3000, 33Информация, размещенная в связанных
зарплата 115,000) в отдел номер 320 и таблицах, может быть легко объединена с
Зачислить сотрудника Кузнецова (пропуск помощью естественного соединения (по
номер 3000, зарплата 115,000) в отдел значениям внешних ключей). Кроме
номер 310. Если информация о сотрудниках вышеупомянутых связей, в реляционной
представлена в виде отношения СОТРУДНИКИ, модели возможны также рекурсивные связи.
оба оператора будут выполняться одинаково Предположим, мы должны хранить информацию
(вставить кортеж в отношение СОТРУДНИКИ). о сотрудниках некоторой компании с
Если же работать с ненормализованным указанием отношений подчиненности между
отношением ОТДЕЛЫ, то первый оператор отдельными сотрудниками. Поскольку один
выразится в занесение кортежа, а второй - экземпляр объекта «Сотрудники» ссылается
в добавление информации о Кузнецове в на другой экземпляр того же объекта,
множественное значение атрибута ОТДЕЛ который в свою очередь может ссылаться на
кортежа с первичным ключом 310. Отношение третий экземпляр, то связь будет унарной и
ОТДЕЛЫ. Отношение СОТРУДНИКИ. 2934. рекурсивной. Данная связь легко
Иванов. 112,000. 310. 2935. Петров. реализуется путем введения внешнего ключа,
144,000. 310. 2936. Сидоров. 92,000. 313. ссылающегося на первичный ключ той же
2937. Федоров. 110,000. 310. 2938. таблицы.
Реляционная модель данных. Связи в РБД.ppt
http://900igr.net/kartinka/informatika/reljatsionnaja-model-dannykh.-svjazi-v-rbd-230893.html
cсылка на страницу

Реляционная модель данных. Связи в РБД

другие презентации на тему «Реляционная модель данных. Связи в РБД»

«Типы баз данных» - Площадь. Ключевое поле (ключ таблицы). Структура школы: Столица. Поиск данных трудоемкий из-за необходимости последовательно проходить несколько иерархических уровней. Любое поле должно иметь уникальное имя. Страна. Самая простая структура. Определения. Выбрать одну из предложенных ниже БД. Сетевые БД.

«Информация и данные» - Информационные системы и базы данных. Тема урока: Объекты базы данных. Сохраните базу данных в файле 10КЛАСС(МАЛЬЧИКИ). Для формального определения таблицы используется понятие отношения (relation - отношение). Пример реляционной таблицы. Информация в БД должна быть: непротиворечивой; неизбыточной; целостной.

«Базы данных 9 класс» - Таблица в режиме конструктора. 1 этап Создание таблиц Создание таблицы «Адреса» с помощью мастера: Главное Меню Сервис Схема данных. Итоги и выводы 5 этапа. Что значит создать структуру БД? Назовите типы БД, кратко охарактеризуйте Что значит реляционная БД? Теоретический зачет. Какого типа могут быть поля в БД?

«Статистические данные на графиках» - Какие телепередачи вы смотрите? Провести и оформить результаты социологического опроса в 8-9 классах по оценке изучаемых предметов. Сколько детей в вашей семье? Какие телевизионные передачи нравятся вашим маме и папе? Ваш рост. Работа в группах. Способы представления данных: По данным «размер обуви» найдите среднее арифметическое и моду.

«Статистические данные» - Цели работы: Апрель. Тема опроса: «Какой у вас оператор мобильной связи?». Октябрь. Любимый учебный день недели. Было опрошено 90 человек. Провести сбор и обработку статистических данных среди учащихся. Группа занималась изучением истории возникновения статистики. Изучить историю возникновения статистики.

«Создание базы данных» - В результате появится окно отчета и вид отчета можно изменять в режиме Конструктора. Этапы создания БД «Мир компьютерных систем». Чтобы создать запрос с параметром выполняем команду Запрос, Параметры. В появившемся диалоговом окне вводим значение параметра и тип данных. Создание отчета с помощью мастера.

Модель

18 презентаций о модели
Урок

Информатика

130 тем
Картинки
900igr.net > Презентации по информатике > Модель > Реляционная модель данных. Связи в РБД