набор возможных значений мужской женский для атрибута пол является

Начало работы с Microsoft Access

Рис. 1. Запуск MS Access 2007 через главное меню

Создание новой базы данных

2. Для создания новой базы данных необходимо нажать кнопку Microsoft Office и в раскрывающемся меню выбрать пункт «Создать». Справа в меню «Новая база данных» выберите свой каталог и введите имя базы данных (например, My Database), нажмите кнопку создать (рис. 2).

Рис. 2. Создание новой базы данных

Создание структуры базы данных

3. После того как вы создали новую базу данных, программа автоматически создает новую таблицу. Перейдите в режим конструктора таблиц: Вкладка Главная/Кнопка Режим/Пункт Конструктор(рис. 4) или в правом нижнем углу нажмите кнопку перехода в режим Конструктора (рис. 3). Вам будет предложено сохранить Таблицу 1. Укажите имя сохраняемой таблицы, например «Таблица 1»

Рис. 4. Переход в режим конструктора

После сохранения таблицы перед вами откроется окно проектирования структуры таблицы (рис. 5.). В верхней части окна находится создаваемый или модифицируемый макет таблицы, который представляет собой список

полей с указанием имени поля, типа данных и описания (необязательный параметр). В столбце “Имя поля” набирается произвольное имя поля, а в следующем столбце (“Тип данных”) указывается тип данных для этого поля. Тип данных можно выбрать из раскрывающегося списка.

Рис. 5. Окно проектирования структуры таблицы

В нижней части окна задаются индивидуальные свойства для каждого поля. Наборы свойств могут различаться, их состав определяется указанным типом данных поля. При необходимости вы можете изменять значения свойств (в рамках допустимого для выбранного типа данных).

Задайте структуру основной таблицы проектируемой нами базы данных. Задайте имена полей и типы данных согласно приведенной ниже таблице:

Создание столбца подстановок с фиксированным набором значений

4. Поле «Пол» сделаем таким, чтобы при заполнении таблицы можно было выбирать из двух возможных значений (мужской/женский). Для того чтобы создать такой подстановочный столбец есть 2 способа.

Способ № 1: создание подстановочного поля при помощи «Мастера подстановок»

Для этого при выборе типа данных для поля «Пол» выберем пункт «Мастер подстановок» (рис. 6).

Рис. 6. Мастер подстановок

Перед вами откроется диалоговое окно, где вам будет предложен ряд вопросов о параметрах настраиваемого подстановочного поля (рис. 7).

Рис. 7. Диалоговое окно мастера подстановок

Укажите следующие параметры (на каждом шаге нажимайте кнопку “Далее”):

o Будет введен фиксированный набор значений. Введите два возможных значения (рис. 8).

Рис. 8. Создание подстановки. Ввод подстановочных значений.

o Оставить подпись “Пол” для подстановочного столбца

o После нажатия кнопки “Готово” вам будет выдано предупреждение о необходимости сохранить таблицу. Согласитесь с этим.

Итак, поле с выбором вариантов создано. Обратите внимание, что этот выбор вы сможете осуществлять при заполнении созданной таблицы в «режиме таблицы», сейчас же вы работаете в «режиме конструктора» таблиц. Однако, изменения произошли в свойствах самого поля. Отметим, что можно не пользоваться «Мастером подстановок», создавать варианты можно непосредственно изменением свойств поля (Способ № 2).

ЧТО ТАКОЕ УВЕРЕННОЕ ПОВЕДЕНИЕ В МЕЖЛИЧНОСТНЫХ ОТНОШЕНИЯХ? Исторически существует три основных модели различий, существующих между.

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем.

Система охраняемых территорий в США Изучение особо охраняемых природных территорий(ООПТ) США представляет особый интерес по многим причинам.

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры.

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте:

Источник

Принципы организации баз данных

Современные базы данных

Реляционные системы

Реляционные системы далеко не сразу получили широкое распространение. В то время как основные теоретические результаты в этой области были получены еще в 70-х годах и тогда же появились первые прототипы реляционных СУБД, долгое время считалось невозможным добиться эффективной реализации таких систем. Однако постепенное накопление методов и алгоритмов организации реляционных баз данных и управления ими привели к тому, что уже в середине 80-х годов реляционные системы практически вытеснили с мирового рынка ранние СУБД.

12 правил Кодда

Кодд предложил применение реляционной алгебры в СУРБД, для расчленения данных в связанные наборы. Он организовал свою систему БД вокруг концепции, основанной на наборах данных.

В реляционной модели данные разбиваются на наборы, которые составляют табличную структуру. Эта структура таблиц состоит из индивидуальных элементов данных, называемых полями. Одиночный набор или группа полей известна как запись.

С точки зрения теории реляционных БД, основные принципы реляционной модели на концептуальном уровне можно сформулировать следующим образом:

Атрибуты сущности бывают:

Существует несколько типов связей между двумя сущностями : это связи ” один к одному “, ” один ко многим ” и ” многие ко многим “.

Каждая связь в реляционной модели характеризуется именем, обязательностью, типом и степенью. Различают факультативные и обязательные связи. Если сущность одного типа оказывается по необходимости связанной с сущностью другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной.

Проектирование схемы БД должно решать задачи минимизации дублирования данных, упрощения и ускорения процедур их обработки и обновления. При неправильно спроектированной схеме БД могут возникнуть аномалии модификации данных. Для решения подобных проблем проводится нормализация отношений

При работе с реляционной моделью для создания отношений приемлемого качества достаточно выполнения требований первой нормальной формы.

Вторая нормальная форма (2НФ) применяется к отношениям с составными ключами (состоящими из двух и более атрибутов ) и связана с понятиями функциональной зависимости.

Отношение находится во 2НФ, если оно приведено к 1НФ и каждый неключевой атрибут функционально полно зависит от составного первичного ключа.

Отношение находится в 3НФ, если оно находится во 2НФ и не имеет атрибутов, не входящих в первичный ключ и находящихся в транзитивной зависимости от первичного ключа.

Моделирование структуры базы данных при помощи алгоритма нормализации имеет серьезные недостатки:

Реляционная БД на физическом уровне состоит из таблиц, между которыми могут существовать связи по ключевым значениям. Одновременно с таблицами и информацией о связях в реляционной базе данных могут присутствовать “хранимые процедуры” и, в частности, “триггеры”, обеспечивающие соблюдение условий ссылочной целостности базы.

Источник

В каком типе переменной хранить (м\ж) пол?

На уровне БД можно хранить маленькие числа, типа byte, smallint или еще что-то типа этого.

Лучше перечислений для подобной задачи еще ничего не придумали 🙂 Хранение бесполезных точных данных, типа возраста, не имеет смысла, если эти эти данные понадобятся только для одноразового определения является человек ребенком и в какую возрастную группу он попадает (портянка условий) и для прочих разделений.

Если границ развития проекта никаких нет, то да, будет лучше все разделить, точнее скорее строить вертикально. Но количество подобных проектов-монстров в меньшинстве и это другой уровень, другие ресурсы. Обычно все просто. Десяток вариаций «полов» и никаких bool 🙂 Если СУБД позволяет, можно автоматизировать распределение хранения данных по разным признакам. Все должно быть просто и быстро.

Строки тоже иногда используются. Это в принципе неплохо, если база небольшая и работать приходится с сырыми данными. Для небольших проектов в целом без разницы как хранить данные, переделать будет проще.

Да, это не пол, это тип или класс пассажира. Просто тебе пол не нужен и как бы ты его узнаёшь иногда только.

abcd0x00: почему же, будет обычное условие 🙂 . WHERE pass_type = FEMALE С детьми возникнут проблемы, если изначально их не разделять по гендерному признаку.

Люди и билеты, как правило, в разных таблицах. Смешивать их нет смысла, это совсем разные структуры.

Но даже если каким-то образом все это окажется в одной таблице, выборка будет аналогичной.

Если типов людей немного и использовать маски, то все совсем просто:

Но запросы будут ресурсоемкими, особенно если данных много. Лучше так не делать или не использовать как есть.

Для небольших баз такой вариант может быть удобным, если типов людей будет не больше 10-15 (2 10 ) и данных немного (с несколькими гигабайтам проблем точно не должно возникнуть, даже на слабом железе).

Возможные ситуации с полами. Например, если изначально были М, Ж и пол не указан. Может потребоваться расширить этот список, сделать несколько вариантов “пол не указан”. Если использовать bool, то придется добавлять дополнительное поле, которое будет содержать информацию, почему пол не указан, или переделывать в int. А в перечисления достаточно добавить нужные элементы в список и все: пол не указан, потому что гладиолус; луна находилось в неправильном месте; пользователь пьян; пользователь не дошел до выбора пола; facebook не вернул информацию о поле пользователя; пользователь отказался отвечать на вопрос и т.п. Бредовый список, но как минимум два варианта “пол не указан” в реальных условиях может быть: не выбран и null.

У тебя просто в примере с билетами пол не используется вообще, только тип пассажира. Просто там пол неважен, поэтому дети и взрослые считаются как бы одного пола.

Источник

Набор возможных значений мужской женский для атрибута пол является

Структурная часть описывает, какие объекты рассматриваются реляционной моделью. Постулируется, что единственной структурой данных, используемой в реляционной модели, являются нормализованные n-арные отношения.

Целостная часть описывает ограничения специального вида, которые должны выполняться для любых отношений в любых реляционных базах данных. Это целостность сущностей и целостность внешних ключей.

В данной главе рассматривается структурная часть реляционной модели.

Типы данных

Любые данные, используемые в программировании, имеют свои типы данных.

Важно! Реляционная модель требует, чтобы типы используемых данных были простыми.

Простые типы данных

Структурированные типы данных

С математической точки зрения массив представляет собой функцию с конечной областью определения. Например, рассмотрим конечное множество натуральных чисел

называемое множеством индексов. Отображение

из множества во множество вещественных чисел задает одномерный вещественный массив. Значение этой функции для некоторого значения индекса называется элементом массива, соответствующим . Аналогично можно задавать многомерные массивы.

Запись (или структура) представляет собой кортеж из некоторого декартового произведения множеств. Действительно, запись представляет собой именованный упорядоченный набор элементов , каждый из которых принадлежит типу . Таким образом, запись есть элемент множества . Объявляя новые типы записей на основе уже имеющихся типов, пользователь может конструировать сколь угодно сложные типы данных.

Общим для структурированных типов данных является то, что они имеют внутреннюю структуру, используемую на том же уровне абстракции, что и сами типы данных.

Работая же с простыми типами данных, например с числовыми, мы манипулируем ими как неделимыми целыми объектами. Чтобы “увидеть”, что числовой тип данных на самом деле сложен (является набором битов), нужно перейти на более низкий уровень абстракции. На уровне программного кода это будет выглядеть как ассемблерные вставки в код на языке высокого уровня или использование специальных побитных операций.

Ссылочные типы данных

Ссылочный тип данных (указатели) предназначен для обеспечения возможности указания на другие данные. Указатели характерны для языков процедурного типа, в которых есть понятие области памяти для хранения данных. Ссылочный тип данных предназначен для обработки сложных изменяющихся структур, например деревьев, графов, рекурсивных структур.

Типы данных, используемые в реляционной модели

Собственно, для реляционной модели данных тип используемых данных не важен. Требование, чтобы тип данных был простым, нужно понимать так, что в реляционных операциях не должна учитываться внутренняя структура данных. Конечно, должны быть описаны действия, которые можно производить с данными как с единым целым, например, данные числового типа можно складывать, для строк возможна операция конкатенации и т.д.

Именно так в некоторых пост-реляционных СУБД реализована работа со сколь угодно сложными типами данных, создаваемых пользователями.

Домены

В реляционной модели данных с понятием тип данных тесно связано понятие домена, которое можно считать уточнением типа данных.

Например, домен , имеющий смысл “возраст сотрудника” можно описать как следующее подмножество множества натуральных чисел:

Если тип данных можно считать множеством всех возможных значений данного типа, то домен напоминает подмножество в этом множестве.

Отличие домена от понятия подмножества состоит именно в том, что домен отражает семантику, определенную предметной областью. Может быть несколько доменов, совпадающих как подмножества, но несущие различный смысл. Например, домены “Вес детали” и “Имеющееся количество” можно одинаково описать как множество неотрицательных целых чисел, но смысл этих доменов будет различным, и это будут различные домены.

Основное значение доменов состоит в том, что домены ограничивают сравнения. Некорректно, с логической точки зрения, сравнивать значения из различных доменов, даже если они имеют одинаковый тип. В этом проявляется смысловое ограничение доменов. Синтаксически правильный запрос “выдать список всех деталей, у которых вес детали больше имеющегося количества” не соответствует смыслу понятий “количество” и “вес”.

Замечание. Понятие домена помогает правильно моделировать предметную область. При работе с реальной системой в принципе возможна ситуация когда требуется ответить на запрос, приведенный выше. Система даст ответ, но, вероятно, он будет бессмысленным.

Замечание. Не все домены обладают логическим условием, ограничивающим возможные значения домена. В таком случае множество возможных значений домена совпадает с множеством возможных значений типа данных.

Отношения, атрибуты, кортежи отношения

Определения и примеры

Фундаментальным понятием реляционной модели данных является понятие отношения. В определении понятия отношения будем следовать книге К. Дейта [11].

Имена атрибутов должны быть уникальны в пределах отношения. Часто имена атрибутов отношения совпадают с именами соответствующих доменов.

Определение 2. Отношение , определенное на множестве доменов (не обязательно различных), содержит две части: заголовок и тело.

Заголовок отношения содержит фиксированное количество атрибутов отношения:

Тело отношения содержит множество кортежей отношения. Каждый кортеж отношения представляет собой множество пар вида :

таких что значение атрибута принадлежит домену

Отношение обычно записывается в виде:

Число атрибутов в отношении называют степенью (или -арностью) отношения.

Мощность множества кортежей отношения называют мощностью отношения.

Возвращаясь к математическому понятию отношения, введенному в предыдущей главе, можно сделать следующие выводы:

Вывод 1. Заголовок отношения описывает декартово произведение доменов, на котором задано отношение. Заголовок статичен, он не меняется во время работы с базой данных. Если в отношении изменены, добавлены или удалены атрибуты, то в результате получим уже другое отношение (пусть даже с прежним именем).

Пример 1. Рассмотрим отношение “Сотрудники” заданное на доменах “Номер_сотрудника”, “Фамилия”, “Зарплата”, “Номер_отдела”. Т.к. все домены различны, то имена атрибутов отношения удобно назвать так же, как и соответствующие домены. Заголовок отношения имеет вид:

Сотрудники (Номер_сотрудника, Фамилия, Зарплата, Номер_отдела)

Пусть в данный момент отношение содержит три кортежа:

такое отношение естественным образом представляется в виде таблицы:

Таблица 1 Отношение “Сотрудники”

Определение 3. Реляционной базой данных называется набор отношений.

Определение 4. Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.

Хотя любое отношение можно изобразить в виде таблицы, нужно четко понимать, что отношения не являются таблицами. Это близкие, но не совпадающие понятия. Различия между отношениями и таблицами будут рассмотрены ниже.

Термины, которыми оперирует реляционная модель данных, имеют соответствующие “табличные” синонимы:

Свойства отношений

Замечание. Из свойств отношения следует, что не каждая таблица может задавать отношение. Для того, чтобы некоторая таблица задавала отношение, необходимо, чтобы таблица имела простую структуру (содержала бы только строки и столбцы, причем, в каждой строке было бы одинаковое количество полей), в таблице не должно быть одинаковых строк, любой столбец таблицы должен содержать данные только одного типа, все используемые типы данных должны быть простыми.

Все такие таблицы есть различные изображения одного и того же отношения.

Первая нормальная форма

Труднее всего дать определение вещей, которые всем понятны. Если давать не строгое, описательное определение, то всегда остается возможность неправильной его трактовки. Если дать строгое формальное определение, то оно, как правило, или тривиально, или слишком громоздко. Именно такая ситуация с определением отношения в Первой Нормальной Форме (1НФ). Совсем не говорить об этом нельзя, т.к. на основе 1НФ строятся более высокие нормальные формы, которые рассматриваются далее в гл. 6 и 7. Дать определение 1НФ сложно ввиду его тривиальности. Поэтому, дадим просто несколько объяснений.

Объяснение 1. Говорят, что отношение находится в 1НФ, если оно удовлетворяет определению 2.

Опять же, определение 2 опирается на понятие домена, а домены определены на простых типах данных.

Требование, что отношения должны содержать только данные простых типов, объясняет, почему отношения иногда называют плоскими таблицами (plain table). Действительно, таблицы, задающие отношения двумерны. Одно измерение задается списком столбцов, второе измерение задается списком строк. Пара координат (Номер строки, Номер столбца) однозначно идентифицирует ячейку таблицы и содержащееся в ней значение. Если же допустить, что в ячейке таблицы могут содержаться данные сложных типов (массивы, структуры, другие таблицы), то такая таблица будет уже не плоской. Например, если в ячейке таблицы содержится массив, то для обращения к элементу массива нужно знать три параметра (Номер строки, Номер столбца, номер элемента в массиве).

Таким образом появляется третье объяснение Первой Нормальной Формы:

Объяснение 3. Отношение находится в 1НФ, если оно является плоской таблицей.

Мы сознательно ограничиваемся рассмотрением только классической реляционной теории, в которой все отношения имеют только атомарные атрибуты и заведомо находятся в 1НФ.

Выводы

В классической реляционной модели используются только простые (атомарные) типы данных. Простые типы данных не обладают внутренней структурой.

Реляционной базой данных называется набор отношений.

Схемой реляционной базы данных называется набор заголовков отношений, входящих в базу данных.

Отношение находится в Первой Нормальной Форме (1НФ), если оно содержит только скалярные (атомарные) значения.

Источник